In QCon London 2008, I had the opportunity to have an interview with one of my heros: Simon Peyton Jones. Simon has an enormous capacity of making the answer to almost any question precise and clear no matter how abstract the subject is. I Strongly recommend that you have a look at this interview if you are interested in programming languages in general. Following Simon’s talks and interviews requires almost no prior knowledge about functional programming or Haskell.
In this interview, computer scientist and researcher Simon Peyton Jones discusses properties of functional programming languages, and particularly Haskell, that have inspired some features in mainstream languages. He gives his opinion on the issues of syntax and language complexity and talks about some research work on subjects such as Data parallelism and transactional memory.
Bio
Honorary Professor of Computer Science at the University of Glasgow, Simon Peyton Jones currently works at Microsoft Research in Cambridge. He has led several research projects focused on the implementation and applications of functional programming languages. He has greatly contributed to the design of the Haskell language, and is the lead designer of the Glasgow Haskell Compiler.
Access this exclusive interview published at InfoQ.com
Mots clés Technorati :
simon peyton johnes,
haskell,
functional-programming,
C#,
F#,
immutability,
transactional memory,
data parallelism,
monads,
fp,
scala,
LinQ
Lately I’ve been writing some programs with Haskell (a pure functional programming language) and I noticed that I am not using GoF design patterns anymore, and that got me to a question: What are GoF design patterns? And why do we need them?
This actually reminds me of a good definition I read (I can’t recall where) of these design patterns: Resolutions to programming language limitations implemented using the programming language available syntax. When one learns a programming language, he learns to express what he wants to express using a very limited set of expressions of the language. The problem with this is that his imagination in this environment gets boxed! So what are GoF design patterns?
Most of GoF design patterns are inspired from Smaltalk, so what is so special about Smaltalk? Closures! It turns out that Java and C++ didn’t have closures and higher order functions. Some of the Design Patterns came to rescue and provide "alternatives" to these powerful constructs or workarounds to resolve these limitations. Such an approach requires a kind of object gymnastics and results in an explosion of classes!
I am now on a project where I use C# 3.5 features, and guess what? Suddenly I use much less strategies, much less templates. I write much less code yet being as or even more flexible. Powerful lambda expressions!
Update: DSLs also come from fp paradigm!
Having manipulated references for quite a while, in an imperative style of programming languages, we searched a lot for solutions for deploying our applications and make them run on several processors. We ve been trieng to extract some logic out of the non-logical machine friendly reference manipulation syntax, to be able to distribute it on deffirent processors. And here comes problems of synchronization of deffirent threads accesing the same reference, which is often a quite complex task.
But, what about going stateless? no synchrnization to do, and instead of telling the runtime how to do, we tell what to do, by passing fuctions that explain that. Well thats what Functional Programming is about!
Recently I crossed two interesting posts, the first is demonstrating an implementation of a paralleledList that uses several proccesors for tasks like filtering, implemented in F#, a quite promissing mixed paradigm language based on .net framework.
http://cs.hubfs.net/blogs/tomasp/archive/2007/03/25/fsharp_parallel_ops.aspx
For those of you not familiar with ML driven syntax, the second article is demonstrating PLinq in C# language which “still” looks like java.
http://community.bartdesmet.net/blogs/bart/archive/2007/04/04/introducing-plinq.aspx
Results are pretty interesting, demonstrating the effect of using more threads against limited-large number of records.
Have fun!
Erik Meijer, Creator, LINQÂ
(more…)
