Erlang 16B Released(erlang.org)
erlang.org
Erlang 16B Released
http://www.erlang.org/news/43
5 comments
The last few days I have been digging into the functional world, because I can't ignore it anymore. Lots of developers I respect say it will make you a better programmer, and you can even use it for building real things (like websites), not just calculate a fibonacci in fewer lines. I'm so lost, I thought there was only 2 or 3 languages, but there are a lot. I figured I should just read some code and pick based on my feelings, but most of it is unreadable for me right now. Some use the java VM, others are native. Some people say you should use their language, some others say you should use them all.
Does anyone have some advice?
Does anyone have some advice?
If the goal is to learn to think functionally, you should concentrate your attention on one or a couple of the big old ones and avoid the Java hybrids until you're more comfortable.
Choosing which one is a matter of personal preference. Erlang is the best choice if you're interested in concurrency and distributed programming. It's also in a sweet spot where variables are bound once, which forces you to change the way you think. I consider this more important than purity for learning.
Haskell is probably the biggest paradigm shift. I use it a lot and love it. It really does change the way you think, but it is also the steepest learning curve.
Of all the Lisps, Scheme is the simplest and tends to be used functionally more often than Common Lisp. There is an incredible wealth of resources for people learning Scheme, but especially The Little Schemer and Structure and Interpretation of Computer Programs (SICP). I have never made much progress in my copy of SICP, but I got a lot out of the Little Schemer. I said to avoid JVM languages but Clojure is the most modern Lisp, and incorporates a lot of modern functional programming idioms, so it can sometimes have a Haskellish flavor, and it doesn't make circumventing FP all that easy. It's probably the best Lisp of today.
Standard ML and OCaml are both good if it looks to you like Haskell goes too far but in the right direction. OCaml is considered more pragmatic; it's also more widely available and benefits from being a single-implementation language. Standard ML is arguably a more beautiful language, but it suffers from low library availability. Both will encourage functional-style programming, but both provide a fair number of escape hatches. For example, they're not pure and they both have "refs" that let you circumvent variables-as-bindings. But they encourage the style.
I tried many times with Lisp and eventually concluded it just wasn't for me, and Haskell is a better fit. I personally recommend looking at Erlang, Clojure and Haskell, and just throwing yourself into whichever one of them looks "cool" to you. If the language feels unpleasant to you, there's no point in trying to force yourself to go further, but if it seems fun to you, you'll make progress without as much effort.
Choosing which one is a matter of personal preference. Erlang is the best choice if you're interested in concurrency and distributed programming. It's also in a sweet spot where variables are bound once, which forces you to change the way you think. I consider this more important than purity for learning.
Haskell is probably the biggest paradigm shift. I use it a lot and love it. It really does change the way you think, but it is also the steepest learning curve.
Of all the Lisps, Scheme is the simplest and tends to be used functionally more often than Common Lisp. There is an incredible wealth of resources for people learning Scheme, but especially The Little Schemer and Structure and Interpretation of Computer Programs (SICP). I have never made much progress in my copy of SICP, but I got a lot out of the Little Schemer. I said to avoid JVM languages but Clojure is the most modern Lisp, and incorporates a lot of modern functional programming idioms, so it can sometimes have a Haskellish flavor, and it doesn't make circumventing FP all that easy. It's probably the best Lisp of today.
Standard ML and OCaml are both good if it looks to you like Haskell goes too far but in the right direction. OCaml is considered more pragmatic; it's also more widely available and benefits from being a single-implementation language. Standard ML is arguably a more beautiful language, but it suffers from low library availability. Both will encourage functional-style programming, but both provide a fair number of escape hatches. For example, they're not pure and they both have "refs" that let you circumvent variables-as-bindings. But they encourage the style.
I tried many times with Lisp and eventually concluded it just wasn't for me, and Haskell is a better fit. I personally recommend looking at Erlang, Clojure and Haskell, and just throwing yourself into whichever one of them looks "cool" to you. If the language feels unpleasant to you, there's no point in trying to force yourself to go further, but if it seems fun to you, you'll make progress without as much effort.
One thing I'd add is that Haskell has by far the best tutorial I've ever encountered for any programming language in the form of Learn You A Haskell For Great Good:
http://learnyouahaskell.com/
That alone is a good enough reason to try out the language, in my opinion.
That alone is a good enough reason to try out the language, in my opinion.
Have you tried (and if so, do you like) F# ? http://fsharp.org/
I have a positive opinion of it but I haven't used it myself. I would imagine it deserves the same caveat as JVM hybrids do: having an easy escape hatch may ease the learning curve, but it can also extend the time it takes to become proficient.
This is a great overview, thanks for posting!
I can't recommend http://learnyouahaskell.com/chapters enough. It was my first book coming from imperative to functional. It blew my mind. Plus, if you're looking to learn specifically functional programming, you don't get more functional than Haskell. I'd also consider Racket to see what Lisps can do (I stay away from Clojure just because it's in Java-land... but that might be a lame excuse).
Also, if you decide to go with erlang, I would recommend http://learnyousomeerlang.com/content. It is written by the same guy, two great books.
It's not written by the same guy. Fred Hébert for the Erlang one, Miran Lipovaca for the Haskell one.
Miran Lipovača wrote the haskell book. Frederic Trottier-Hebert wrote the erlang book.
I have a question about this - is he going to write more chapters? I skimmed ahead and it looks like it ends abruptly, no conclusion etc. Not sure if that's actually intended to be the end.
I don't know actually. You can ask him, he posts his address on the front page: bonus at learnyouahaskell dot com
I'm a big Erlang fan. Its not "pure" functional. That's by design and although the syntax may seem foreign at first, its easy to learn and was designed to be easy to teach "telecom engineers" who weren't traditionally trained CompSci folk. Erlang has several decent WebApp Frameworks. I like ChicagoBoss.org as an easy start.
Erlang is more than a functional lang. It has concepts of concurrency and "let-it-fail" which helped to change my view on how to write server apps.
Erlang is more than a functional lang. It has concepts of concurrency and "let-it-fail" which helped to change my view on how to write server apps.
I wouldn't stress too much over what language you pick, you're going to learn some cool stuff regardless. Erlang, clojure and haskell are the languages that spring to my mind when I think of functional programming. Just skim a few tutorials, see if anything appeals to you, and go for it.
I'm roughly in the same boat. Part of it is that different communities have different definitions of purely functional.
Check me out, I'm about to say a bunch of things as if they're fact, in the hopes that someone will correct me where I'm wrong!
So, a few decades ago two groups of people came to the determination that anything calculable can be expressed through a Turing machine or through lambda calculus.
The Turing machine was sorta step-by-step and nuts-and-bolts and inspired the imperative branch of programming languages.
Lambda calculus is more denotive and inspired functional programming.
Now this part is confusing. Because if you ask "What language should I learn to explore lambda calculus?" people will tend to answer Lisp variants. Whereas if you ask "What language should I learn to learn functional programming?" people will tend to answer Haskell.
I understand the differences between Haskell and Lisp - Haskell is more restrictive and pure, while Lisp is incredibly supple with its code-is-data-is-code approach - but I thought functional programming came from lambda calculus. In other words, I don't understand what lambda calculus is that functional programming isn't or vice versa.
Anyway, what's generally seen as the most "purely functional" language is Haskell. Opinions vary on how pragmatic a language it is to learn (as judged by job openings and active projects), but it's widely seen as the language to learn if you want to learn and "get" functional programming concepts most efficiently. In other words, learn some Haskell, and it makes other functional languages easier to learn.
My basic choice (as an imperative programmer that knows java, perl, php) was whether to learn some kinda java-esque functional language, or Haskell, or a lisp variant (including java-esque lisp like Clojure). I'm choosing to learn Haskell, and then move over to Scala, since I hear and suspect that is a better way to learn Scala than to go directly to Scala, and since I'm interested in enhancing my existing body of knowledge rather than switching career paths entirely.
BTW, there's a third big family of programming language, logical programming languages (Prolog, etc). I thought I saw that Erlang is influenced by some concepts from that. So at least in my head, it has seemed like Erlang is the language I'd want to learn if I really wanted to blow my mind with a mixture of functional, concurrency, and logical-programming concepts.
Check me out, I'm about to say a bunch of things as if they're fact, in the hopes that someone will correct me where I'm wrong!
So, a few decades ago two groups of people came to the determination that anything calculable can be expressed through a Turing machine or through lambda calculus.
The Turing machine was sorta step-by-step and nuts-and-bolts and inspired the imperative branch of programming languages.
Lambda calculus is more denotive and inspired functional programming.
Now this part is confusing. Because if you ask "What language should I learn to explore lambda calculus?" people will tend to answer Lisp variants. Whereas if you ask "What language should I learn to learn functional programming?" people will tend to answer Haskell.
I understand the differences between Haskell and Lisp - Haskell is more restrictive and pure, while Lisp is incredibly supple with its code-is-data-is-code approach - but I thought functional programming came from lambda calculus. In other words, I don't understand what lambda calculus is that functional programming isn't or vice versa.
Anyway, what's generally seen as the most "purely functional" language is Haskell. Opinions vary on how pragmatic a language it is to learn (as judged by job openings and active projects), but it's widely seen as the language to learn if you want to learn and "get" functional programming concepts most efficiently. In other words, learn some Haskell, and it makes other functional languages easier to learn.
My basic choice (as an imperative programmer that knows java, perl, php) was whether to learn some kinda java-esque functional language, or Haskell, or a lisp variant (including java-esque lisp like Clojure). I'm choosing to learn Haskell, and then move over to Scala, since I hear and suspect that is a better way to learn Scala than to go directly to Scala, and since I'm interested in enhancing my existing body of knowledge rather than switching career paths entirely.
BTW, there's a third big family of programming language, logical programming languages (Prolog, etc). I thought I saw that Erlang is influenced by some concepts from that. So at least in my head, it has seemed like Erlang is the language I'd want to learn if I really wanted to blow my mind with a mixture of functional, concurrency, and logical-programming concepts.
> I don't understand what lambda calculus is that functional programming isn't or vice versa.
It's a bit like wondering what part of procedural programming is using a turing machine and which part isn't. :) The theory is theory and the practice is practice; in the end, what you're using is pretty far from it but it retains some of the flavor.
The flavor of lambda calculus is one of substitution and reduction. Expressions are evaluated, values replaced, variables bound. Even something like Scheme is pretty far from it, but it is close enough that if you want to study one the other will help.
The basic lambda calculus you hear about is usually the original untyped lambda calculus. The typed lambda calculus isn't much more worse, but bears a stronger resemblance to ML and so forth.
I have not found the absence of a background in lambda calculus to be much of an impediment to learning and applying functional programming. Presence of the word "calculus" tends to make us think something is grand and mystifying. In this particular case my impression is that it is an interesting theoretical diversion and that's about all one needs to know.
> I thought I saw that Erlang is influenced by some concepts from that
Well... Erlang was originally implemented in Prolog. And the syntax borrows from Prolog in many places. However, Erlang is absolutely not a logic programming language because there is no unification happening within it. It is really cool in its own right though.
The world of logic programming continues to be dominated by Prolog, which is an amazing, somewhat practical and beautiful language, but also warty old hog at the same time. Mercury gets brought up from time to time, and it should be amazing, but lacking a repl it leaves me cold. Apart from these two there are a handful of multiparadigm languages that have some constraint handling, such as Oz or one of the embedded Prologs for Lisp (Allegro has a good one), and then there's things like CLIPS or Jess or JBoss Drools, but for dedicated logic languages it's still essentially just Prolog.
I'm a huge fan of Prolog, by the way! I don't think it helps much with learning functional programming but it definitely will blow your mind, and probably more than FP would too. If you wind up trying it out and getting stuck, drop me a line or ask a question on SO. I frequently leave huge answers there and the community is very friendly.
It's a bit like wondering what part of procedural programming is using a turing machine and which part isn't. :) The theory is theory and the practice is practice; in the end, what you're using is pretty far from it but it retains some of the flavor.
The flavor of lambda calculus is one of substitution and reduction. Expressions are evaluated, values replaced, variables bound. Even something like Scheme is pretty far from it, but it is close enough that if you want to study one the other will help.
The basic lambda calculus you hear about is usually the original untyped lambda calculus. The typed lambda calculus isn't much more worse, but bears a stronger resemblance to ML and so forth.
I have not found the absence of a background in lambda calculus to be much of an impediment to learning and applying functional programming. Presence of the word "calculus" tends to make us think something is grand and mystifying. In this particular case my impression is that it is an interesting theoretical diversion and that's about all one needs to know.
> I thought I saw that Erlang is influenced by some concepts from that
Well... Erlang was originally implemented in Prolog. And the syntax borrows from Prolog in many places. However, Erlang is absolutely not a logic programming language because there is no unification happening within it. It is really cool in its own right though.
The world of logic programming continues to be dominated by Prolog, which is an amazing, somewhat practical and beautiful language, but also warty old hog at the same time. Mercury gets brought up from time to time, and it should be amazing, but lacking a repl it leaves me cold. Apart from these two there are a handful of multiparadigm languages that have some constraint handling, such as Oz or one of the embedded Prologs for Lisp (Allegro has a good one), and then there's things like CLIPS or Jess or JBoss Drools, but for dedicated logic languages it's still essentially just Prolog.
I'm a huge fan of Prolog, by the way! I don't think it helps much with learning functional programming but it definitely will blow your mind, and probably more than FP would too. If you wind up trying it out and getting stuck, drop me a line or ask a question on SO. I frequently leave huge answers there and the community is very friendly.
This sounds great. I've had a side curiosity in the subject (logic programming) for a while (mostly just limited to experimentation in Drools so far) so I'll keep your username in mind. Thanks!
No problem. :)
If you want to learn functional programming, concurrent programming and fault tolerant system design at the same time then you should pick Erlang :)
Look at more than one functional language. People are different. I think it had more to do with me than Erlang that it was the first (functional) language that gave me an "aha!" moment about functional programming.
I had the same problem a few months ago and I went with Haskell because it has pythonic syntax(signifcant whitespace) and it's very pure, i.e. forcing you to program functionally. I think in production being able to go back to iterative programming can certainly be helpful, but while learning it's more a way to not learn functional programming.
well, my 2 cents here, would be suggest an alternate route: go with sicp (do the exercises !) for learning functional programming. once you have gone through that, erlang is just a syntax away, which after a week or so is just fine...
i am a fan of "how to design programs" [http://htdp.org/]
if you are already an experienced programmer, bits of it may seem trivial, but avoid the temptation to skim; following along all the way through will genuinely introduce you to the functional way of thinking.
if you are already an experienced programmer, bits of it may seem trivial, but avoid the temptation to skim; following along all the way through will genuinely introduce you to the functional way of thinking.
Erlang was the first functional language I learned. It took me a couple weeks of pain but then once I got it, I started to love it. The "unreadable" becomes poetry. (And truthfully, the support for concurrency in erlang is why I chose it in the first place, I didn't care that it was functional, and since then I've not heard any suggestions of other languages that would make me want to switch, with one exception: elixir)
You might consider, if the syntax is just too painful, looking at elixir. Elixir is effectively erlang but with a more ruby-like syntax. I think elixir exists for other reasons, but the syntax being more readily accessible to ruby developers is a nice side effect.
http://elixir-lang.org
Not sure if elixir is the best way to learn functional programming, as I knew elrang before learning it, but it is a nice language, it is not a "hipster" language, and it has great support especially given how relatively new it is.
You might consider, if the syntax is just too painful, looking at elixir. Elixir is effectively erlang but with a more ruby-like syntax. I think elixir exists for other reasons, but the syntax being more readily accessible to ruby developers is a nice side effect.
http://elixir-lang.org
Not sure if elixir is the best way to learn functional programming, as I knew elrang before learning it, but it is a nice language, it is not a "hipster" language, and it has great support especially given how relatively new it is.
Not to put elixir down, but if someone wants to understand Erlang, I recommend just suck it up and learn the syntax. Its so so easy to read once you get the hang of it. The learning curve is nothing like Haskell. Getting comfortable with Erlang syntax takes only a few days of coding. Just reading it as an approach to get comfortable may put you off. Diving in and writing some code will take the edge off.
http://learnyousomeerlang.com/content
is a pretty good place to start.
I also recommend the book, "Erlang and OTP in Action." Don't fall into the trap of trying to reinvent the things OTP provides.
is a pretty good place to start.
I also recommend the book, "Erlang and OTP in Action." Don't fall into the trap of trying to reinvent the things OTP provides.
Thanks for the link. Maybe I try Erlang after all...
But a question: It says it's using Erlang 13B. Do you recommend using a newer version, or trying to compile/finding an old binary version of 13B? (I mean, is Erlang 16 compatible with 13, or they tend to break things?)
(I'm sure I'll find this out eventually when I start the tutorial, but it's always good to know this kind of things beforehand)
But a question: It says it's using Erlang 13B. Do you recommend using a newer version, or trying to compile/finding an old binary version of 13B? (I mean, is Erlang 16 compatible with 13, or they tend to break things?)
(I'm sure I'll find this out eventually when I start the tutorial, but it's always good to know this kind of things beforehand)
I hypothesize that for a ruby programmer, learning elixir would allow them to learn the way erlang works, and then the transition from elixir syntax to erlang syntax would be very easy.
The thing is, elixir is really just erlang with some extra features (which are really compelling to me) and some syntax changes that make it much more readable to non-erlangers. (or at least, I believe it would.)
But secretly, you're learning erlang. And afterwards the transition between the two will be seamless (Because they're really the same language.)
The thing is, elixir is really just erlang with some extra features (which are really compelling to me) and some syntax changes that make it much more readable to non-erlangers. (or at least, I believe it would.)
But secretly, you're learning erlang. And afterwards the transition between the two will be seamless (Because they're really the same language.)
Elixir is a fantastic language and it's a lot of fun to code with, but you need to know at least the basics of erlang to use it well, because although it has an excellent standard library, it's not as comprehensive as erlang's.
I would definitely recommend anyone that wants to try Elixir, to at least try learn some erlang first. The learn you some erlang book is pretty fantastic.
I would definitely recommend anyone that wants to try Elixir, to at least try learn some erlang first. The learn you some erlang book is pretty fantastic.
Joe Armstrong: I came up with Erlang, because it didn't exist http://news.ycombinator.com/item?id=5247531
I love Erlang. As someone said it is a complete platform. It is like a programming language, middleware, system monitoring software, database all rolled into one. Plus it was originally designed to create telephone switches. Bulletproof reliability was the primary concern.
FWIW, In Erlang Land, the "A" release (eg: 16A) is the "beta" and the "B" release is the "finished" release.
So 16B is the complete, ready for production version of 16.
Next release will be 17A, or 16B2 if there are bug patches required.
Also, it may seem weird that a "programming language" is having an update each year. (how many times a decade is C++ updated?) But this is because erlang is really a complete platform. The language is just part of it, but OTP, the platform is a hidden gem that gives erlangers super powers.
This also means, each year, your code gets better as the platform itself gets better.
So 16B is the complete, ready for production version of 16.
Next release will be 17A, or 16B2 if there are bug patches required.
Also, it may seem weird that a "programming language" is having an update each year. (how many times a decade is C++ updated?) But this is because erlang is really a complete platform. The language is just part of it, but OTP, the platform is a hidden gem that gives erlangers super powers.
This also means, each year, your code gets better as the platform itself gets better.
https://www.erlang-solutions.com/downloads/download-erlang-o...
(Courtesy of Erlang Solutions).
Readme of all the changes:
http://erlang.org/download/otp_src_R16B.readme