FYI, Simon Marlow is incredibly big in the Haskell community and is the leading expert in Multi core parallelism via STMs in Haskell. Some of the work he has done for the GHC compiler is frankly fantastic.
This is incredibly big news in the Haskell world. The FP community is starting to break boundaries with the industry in the last 5 years with Clojure (and Scala's functional support).
Currently, FB seems to use haskell only for basic lexing and parsing[1]. It would be tremendous to see them using it at FB scale. I think there's going to be gain for both parties - For FB, the publicity and hacker outreach, and Haskell - industrial reliability.
There's this perception that Scala is less FP than a language like Clojure and I don't understand why, when in my (albeit limited) experience, I found the contrary to be true. This impression that's perpetuated is IMHO only folklore coming from people that only played around with these languages superficially.
Scala feels more like a functional programming language to me because:
(-) Code written in Scala tends to be more FP. One of the popular Scala frameworks, Play 2.0, is using Iteratees for dealing with responses and I/O in general, a concept used in Haskell, being pure awesomeness if you want to do Comet/Websockets. Play itself feels more reactive than Node.js, even though Node.js was built from the ground up for this. Also monadic types are used everywhere, from the standard collections to the Maybe monad (Option) to Futures/Promises. In Clojure you rarely see this, because Clojure is so dynamic that working with complicated container types is unfeasible.
(-) the Scala collections library provides more variants of immutable data-structures optimized for different things and those immutable data-structures in Scala are doing the right thing - first they play well with each other (e.g. mapping over a Map produces another Map if the function returns a tuple, but produces a Seq in case it returns a single element and there are many more examples where Scala simply knows what you mean).
Many times you pick concrete implementations like Vectors because of the provided invariants (e.g. indexing in O(1) or efficient adding/removing of elements on the right) and changing those invariants is IMHO bad design. Doing operations on a Vector like adding elements shouldn't produce a list, even if that list is lazy or whatever other reason. In Scala you know what operations are going to behave lazily because such invariants are encoded in the type. Adding/removing/transforming elements from a lazy Stream or view or other kind of lazy collection is still going to produce a lazy collection. And this is extremely useful in languages where laziness is not the default.
From the perspective of its rich collection of immutable collections, Scala is more functional than popular ML languages in general, except maybe Haskell. In Ocaml idiomatic code includes the usage of mutable collections, while in Scala the mutable versions are second-class citizens - and before you say that Clojure doesn't have mutable collections, think again - arrays are part of standard code and working with Java collections is quite comfortable and given as example in Clojure books.
(-) STM and atoms are great. I use STM in Scala a lot lately. However stuff like atoms and STM are still mutable state and come with many of the same gotchas as plain vars and pretending like this is otherwise is dangerous. Precisely for this reason it's useful to be able to implement your own atoms and your own STM mechanism that is more suitable to the problem at hand, that better encapsulates state and so on and because of the reality we live in, the internals of such components can get messy, while still keeping referential transparency for the outside world or other kinds of invariants - STM in Scala is a library (and quite nice in fact since it forces you to use Refs inside transactions with compile-time checks); Erlang-style Actors are a library too; Futures/Promises are a library too. All of them created with Scala.
(-) Scala is OOP while Clojure pretends like it isn't. I'm using "pretends", as multi-methods were introduced in CLOS, an OOP extension to Common Lisp, which made no effort to hide the fact that multi-methods are still all about OOP.
But just because OOP is very efficient (and has been used) to hide mutable state, that doesn't make OOP any less orthogonal to functional programming. Maybe tying up data with functions operating on that data leads to bad design, but besides the fact that type-classes are also part of idiomatic Scala and used everywhere, OOP is actually a quite nice and comfortable ad-hoc mechanism for polymorphism, being quite orthogonal to FP. Clojure is only able to have multi-methods and protocols because it is dynamic, but as far as FP is concerned this has drawbacks. Also in regards to multi-methods, I've seen code in the wild that dispatches on some global state instead of their arguments, since you can dispatch on anything and I'm really talking about mutable state.
IMHO I can't find evidence that Clojure is more FP than Scala. I'm more experienced with Scala than Clojure, so maybe this is why. But IMHO, Scala is more potent if you want to explore concepts of functional programming, being in my opinion the second choice after Haskell.
And I do think that this perception only has legs because Scala has a Java-like "while" loop and doesn't hide the fact that "vars" are really vars.
> The FP community is starting to break boundaries with the industry in the last 5 years with Clojure (and Scala's functional support).
There is very little evidence of that. Do a search for Scala, Clojure or Haskell on the main indicator web sites (job boards, StackOverflow, TIOBE, indeed.com, etc...) and you'll find they are as insignificant today as they were five years ago compared to the mainstream languages.
> This is incredibly big news in the Haskell world.
I'm puzzled why you think this is good news for Haskell. The lead developer and architect of GHC and authority in parallel Haskell is announcing that he's taking a position that won't allow him to spend much time working on GHC, and he might even stop using Haskell completely.
It's great news for Simon but terrible news for Haskell.
Pedant calling - Erlang is a functional programming language that has been doing very nicely thank you in a lot of big companies (Amazon, Facebook amongst others) for a good while now.
Wow, talk about a shock. I hope that this is good news for functional programming and the programming language community, rather than just good news for Facebook.
Well the strong type system ensures that no collisions are possible. GHC is quite the software gem. I love haskell more and more. Everything that is so simple to write, has no right of being so fast.
i'm assuming this guy has done real world work before? the idea of a compiler/language lead programmer effectively having lived in academia is terrifying on many levels.
best of luck to him at any rate. haskell and ghc are a cool language and compiler combo, one i have enjoyed for recreational programming time and time again.
"The idea of a compiler/language lead programmer effectively having lived in academia is terrifying on many levels."
The apparent cluelessness level of this statement is so high, I am unable to decide if this is just ignorance or very sophisticated trolling.
If the compiler dev working in a university or a research lab while developing the compiler is "terrifying", you should avoid C, C++, and Python, not to mention smalltalk, Pascal, Prolog, Common Lisp, Scheme, SML and OCaml ....
The real world is crappy, and we're depending on these academic types to free us from the drollness of it, because we don't all have time to invent an STM. If I wanted to write CRUD apps all day and say that's real-world, I suppose I could, but I would rather enjoy enlightenment.
Function invocation overhead, you say? Why would I want that?
How about Garbage Collection? It'll never work.
It's their responsibility to create foundational research, and it's ours to filter through it and prove the good bits with fire.
'Practical' is a red-herring, I think. We have no way to predict the future, but we all care about progress.
[+] [-] smenyp|13 years ago|reply
This is incredibly big news in the Haskell world. The FP community is starting to break boundaries with the industry in the last 5 years with Clojure (and Scala's functional support).
Currently, FB seems to use haskell only for basic lexing and parsing[1]. It would be tremendous to see them using it at FB scale. I think there's going to be gain for both parties - For FB, the publicity and hacker outreach, and Haskell - industrial reliability.
[1]: http://www.haskell.org/haskellwiki/Haskell_in_industry
[+] [-] bad_user|13 years ago|reply
There's this perception that Scala is less FP than a language like Clojure and I don't understand why, when in my (albeit limited) experience, I found the contrary to be true. This impression that's perpetuated is IMHO only folklore coming from people that only played around with these languages superficially.
Scala feels more like a functional programming language to me because:
(-) Code written in Scala tends to be more FP. One of the popular Scala frameworks, Play 2.0, is using Iteratees for dealing with responses and I/O in general, a concept used in Haskell, being pure awesomeness if you want to do Comet/Websockets. Play itself feels more reactive than Node.js, even though Node.js was built from the ground up for this. Also monadic types are used everywhere, from the standard collections to the Maybe monad (Option) to Futures/Promises. In Clojure you rarely see this, because Clojure is so dynamic that working with complicated container types is unfeasible.
(-) the Scala collections library provides more variants of immutable data-structures optimized for different things and those immutable data-structures in Scala are doing the right thing - first they play well with each other (e.g. mapping over a Map produces another Map if the function returns a tuple, but produces a Seq in case it returns a single element and there are many more examples where Scala simply knows what you mean).
Many times you pick concrete implementations like Vectors because of the provided invariants (e.g. indexing in O(1) or efficient adding/removing of elements on the right) and changing those invariants is IMHO bad design. Doing operations on a Vector like adding elements shouldn't produce a list, even if that list is lazy or whatever other reason. In Scala you know what operations are going to behave lazily because such invariants are encoded in the type. Adding/removing/transforming elements from a lazy Stream or view or other kind of lazy collection is still going to produce a lazy collection. And this is extremely useful in languages where laziness is not the default.
From the perspective of its rich collection of immutable collections, Scala is more functional than popular ML languages in general, except maybe Haskell. In Ocaml idiomatic code includes the usage of mutable collections, while in Scala the mutable versions are second-class citizens - and before you say that Clojure doesn't have mutable collections, think again - arrays are part of standard code and working with Java collections is quite comfortable and given as example in Clojure books.
(-) STM and atoms are great. I use STM in Scala a lot lately. However stuff like atoms and STM are still mutable state and come with many of the same gotchas as plain vars and pretending like this is otherwise is dangerous. Precisely for this reason it's useful to be able to implement your own atoms and your own STM mechanism that is more suitable to the problem at hand, that better encapsulates state and so on and because of the reality we live in, the internals of such components can get messy, while still keeping referential transparency for the outside world or other kinds of invariants - STM in Scala is a library (and quite nice in fact since it forces you to use Refs inside transactions with compile-time checks); Erlang-style Actors are a library too; Futures/Promises are a library too. All of them created with Scala.
(-) Scala is OOP while Clojure pretends like it isn't. I'm using "pretends", as multi-methods were introduced in CLOS, an OOP extension to Common Lisp, which made no effort to hide the fact that multi-methods are still all about OOP.
But just because OOP is very efficient (and has been used) to hide mutable state, that doesn't make OOP any less orthogonal to functional programming. Maybe tying up data with functions operating on that data leads to bad design, but besides the fact that type-classes are also part of idiomatic Scala and used everywhere, OOP is actually a quite nice and comfortable ad-hoc mechanism for polymorphism, being quite orthogonal to FP. Clojure is only able to have multi-methods and protocols because it is dynamic, but as far as FP is concerned this has drawbacks. Also in regards to multi-methods, I've seen code in the wild that dispatches on some global state instead of their arguments, since you can dispatch on anything and I'm really talking about mutable state.
IMHO I can't find evidence that Clojure is more FP than Scala. I'm more experienced with Scala than Clojure, so maybe this is why. But IMHO, Scala is more potent if you want to explore concepts of functional programming, being in my opinion the second choice after Haskell.
And I do think that this perception only has legs because Scala has a Java-like "while" loop and doesn't hide the fact that "vars" are really vars.
[+] [-] eta_carinae|13 years ago|reply
There is very little evidence of that. Do a search for Scala, Clojure or Haskell on the main indicator web sites (job boards, StackOverflow, TIOBE, indeed.com, etc...) and you'll find they are as insignificant today as they were five years ago compared to the mainstream languages.
[+] [-] eta_carinae|13 years ago|reply
I'm puzzled why you think this is good news for Haskell. The lead developer and architect of GHC and authority in parallel Haskell is announcing that he's taking a position that won't allow him to spend much time working on GHC, and he might even stop using Haskell completely.
It's great news for Simon but terrible news for Haskell.
[+] [-] wink|13 years ago|reply
It seemed to have been deprecated in favor of [2] when the original author of lex-pass left Facebook.
Sorry if any of this information is a little off/incomplete, I think it's been 2 years when I oversaw a BSc paper revolving around extending lex-pass.
[1]: https://github.com/facebook/lex-pass [2]: https://github.com/facebook/pfff
[+] [-] gordonguthrie|13 years ago|reply
[+] [-] creatio|13 years ago|reply
[+] [-] djhworld|13 years ago|reply
Simon might just be looking for a new challenge, with Haskell as his side hobby.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] dbaupp|13 years ago|reply
[+] [-] bbotond|13 years ago|reply
[+] [-] Yoric|13 years ago|reply
[+] [-] mej10|13 years ago|reply
[+] [-] davidw|13 years ago|reply
[+] [-] NullSet|13 years ago|reply
[+] [-] pionar|13 years ago|reply
[+] [-] chriseidhof|13 years ago|reply
[+] [-] jlouis|13 years ago|reply
[+] [-] mattquiros|13 years ago|reply
[+] [-] Narretz|13 years ago|reply
[+] [-] dochtman|13 years ago|reply
http://lmgtfy.com/?q=ghc
[+] [-] venomsnake|13 years ago|reply
[+] [-] sanxiyn|13 years ago|reply
[+] [-] jheriko|13 years ago|reply
best of luck to him at any rate. haskell and ghc are a cool language and compiler combo, one i have enjoyed for recreational programming time and time again.
[+] [-] plinkplonk|13 years ago|reply
The apparent cluelessness level of this statement is so high, I am unable to decide if this is just ignorance or very sophisticated trolling.
If the compiler dev working in a university or a research lab while developing the compiler is "terrifying", you should avoid C, C++, and Python, not to mention smalltalk, Pascal, Prolog, Common Lisp, Scheme, SML and OCaml ....
There is always PHP. Turing Completeness FTW.
[+] [-] gtrak|13 years ago|reply
Function invocation overhead, you say? Why would I want that?
How about Garbage Collection? It'll never work.
It's their responsibility to create foundational research, and it's ours to filter through it and prove the good bits with fire.
'Practical' is a red-herring, I think. We have no way to predict the future, but we all care about progress.
[+] [-] freyrs3|13 years ago|reply
Yes, very much. He's one of the leading voices in the parallel Haskell world and a very accomplished programmer:
* http://hackage.haskell.org/package/stm
* http://hackage.haskell.org/package/async
* http://hackage.haskell.org/package/happy
[+] [-] gclaramunt|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]