Reia: Friendly, Ruby-style syntax on the Erlang VM
github.com
github.com
I have got to start writing Ruby again now (to use the OLE libraries which I ain't going to reimplement). Ruby looks like line noise now.
The key thing about switching to Erlang is that it is not a programming language choice. Erlang/OTP is an Application System that runs on one or more computers. We stick with Operating Systems (including super-ugly ones like the Unices) because of the benefits of knowing that your unwritten software can write to disk, speak to a network, use a GUI etc. Once you have started writing to an Application System where your unwritten software knows how to fail over to a new machine, you ain't going back.
The syntax could be nicer? Who cares? Love the one your with is my experience - oh and I really do heart the mighty Erlang.
You're not alone here.
I gave erlang more than one shot and really, really wanted to like it. It promises to simplify and robustify some of the most thorny distributed programming problems that I'm dealing with nearly every day, in ruby and python.
But, just like you, I couldn't get over the syntax. It's ugly. It's error-prone. It's ugly.
And that's a dealbreaker. The most powerful VM doesn't help when you have to work uphill against arcane syntax all day long. Nobody wants to do that. That's why ruby is so popular, despite the trainwreck that is MRI.
For instance, there is tool support. As with any language that isn't very widely used there aren't that many tools for the language. It makes it more difficult to get up and going in a short manner. This is especially true if you're on Windows since many Erlang projects don't work on Windows (even though the VM itself has Windows support).
Beyond that, Erlang uses a model of programming and concurrency that isn't commonly used elsewhere. While you can get many of the features of Erlang in other systems, you are generally making an intentional effort to do so. Things like messaging passing, processes and hot code swapping are at the core of the language and getting used to things like this can be a bit overwhelming.
On top of that many of the Erlang projects I've worked with have extremely sparse documentation. There are many cool projects out there like Mochiweb, Nitrogen, etc. but getting up and going with them can at times be an exercise in frustration.
I think these things combine to make a barrier to entry that is much larger than people's syntax preferences.
Reia has completely new semantics and run in interpreted mode over BEAM (Erlang VM).
I personally think, that if programmer can't adapt to new syntax, it will be much harder to her/him to adapt to new semantics.
Erlang's syntax is ugly comparing to modern languages like Ruby. The simple things are hard to do in Erlang and simple in Ruby, but complex thing are easy in Erlang and impossible in Ruby.
Erlang is pragmatic choice for today. Maybe in 5-10 years Erjang,Scala,Go,Rust or some other new language will be a better choice, but until then use Erlang/OTP.
It's slower than Erlang, not because it's executed in a different manner than Erlang, but because it supplies a separate late binding mechanism for dispatching methods to their receivers.
Edit: This is referring to its current state only- I reserve the right to change my mind in the future (:
If you're working on a language project, fuck it up, and don't do a rewrite, you get PHP.
That said, your other criticisms are valid: much of Erlang's functionality doesn't have first class Reia support (but is still directly callable through the presently undocumented Erlang interfacing syntax)
Many of Ruby's great features aren't available in Reia yet either. I'm shooting for a subset of Ruby's metaprogramming features which aren't incompatible with Erlang-style code loading.
I hope you'll continue to watch the project.
Semantics are much more interesting to talk about, but it seems we never do talk about them. We rarely have holy-wars over the semantic differences between (for example) c and lisp, or lisp and Erlang.
There are certain problems that are easier to solve when expressed as many concurrent processes. In this same way, there are certain problems that are easier to solve when expressed as self modifying code or a tower of objects, or low level bit bashing.
At a certain level, different syntaxes do absolutely nothing for me. No matter what I'm doing with code, I am manipulating a syntax tree. I'm never thinking about the syntax on the page as the 'code,' what is on the page is just a representation of the 'code' that is in my head and being run by the computer. And the semantics of that 'code' is what influences how I use the language.
Syntax on the page is almost a deception. Kind of an illusion that influences you into thinking about the code in a certain abstract way (a spatial 'on the page' arrangement of different parts), when really, the code was already abstract to begin with (runtime execution 'arrangement' of the different parts).
erlang's syntax is not some arcane afterthought, it may look strange or even "ugly" to people not familiar with it, but it has been very well thought out and purposeful, every time there is a choice between a beautiful construct that can add confusion, or a less elegant solution that is crystal clear, erlang chooses less elegant every time.
I have been doing javascript since I started programming and still get confused by its object model + prototypal inheritance, the same is true for pretty much every language, python, ruby, c++ etc going back to erlang is a refreshing break.
Erlang is based originally on Prolog, a logic programming
language that was briefly hot in the 80's. Surely you've
seen other languages based on Prolog, right? No? Why not?
Because Prolog sucks ass for building entire
applications. But that hasn't deterred Erlang from
stealing it's dynamite syntax.
Tea time!
However programming languages live and die by the size of their community. Erlang has, by choice of an over-brewed and bitter syntax, drawn itself into a niche much smaller than it deserves. The only chance to escape would be to adapt a more popular taste.
Otherwise it will eventually be obsoleted by a language "as powerful as erlang, but minus the arcane syntax".
Erlang's semantics are so very different from most other languages that having an arcane Prolog-derived syntax is just insult to injury.
In addition to all the conceptual, semantic leaps that Erlang asks you to make, you also have to learn a syntax which is very different from the Algol/C-based languages most people are used to.
I buy the argument that maybe, if you get used to it, Erlang's syntax can be beautiful. But it's still very much a barrier to people who have never used the Prolog language "family" (which as noted earlier includes... Prolog and Erlang).
In my personal experience having used Erlang for some 3 years now, I still find its syntax ugly and obtrusive.
Erlang syntax is a bit different, and there are even (IMHO) internal inconsistencies, but I didn't find it any more of a roadblock than e.g. python's indentation conventions. Each person is different I guess.
Since this can be transformed to tail-recursion, you should be able to implement it on the Erlang VM without too much trouble. Getting a convenient syntax and doing the transformation would be the hardest part.
http://groups.google.com/group/erlang-programming/browse_frm...
------------
(Oct 09) http://groups.google.com/group/erlang-programming/browse_frm...
Some erlang processes run for literally years - and exist over multiple releases of the software. Reasoning about how something did or did not get into the process dictionary is for the birds.
Non-mutability is not some crazy quick left there as an afterthought - it is at the core of Erlang - it is how you build reliable systems in the presence of errors.
But if you're cheating on purity, there better be a darn good reason.
I used to agree with you but now I don't. I was particularly moved by some of what Joe Armstrong, Erlang's creator, had to say in the book "Coders at Work". He noted that after attending several functional language conferences, immutable state was much more a common quality of truly functional languages than other things people typically associate like static typing or lazy evaluation.
Reia is an immutable state language, and I think it's primarily a functional language, but one with a lot of features that make it less painful to use than languages like Erlang or Haskell.
In a language like Erlang, immutable state allows you the potential to send zero copy messages between actors. This can be hugely beneficial for exchanging state in a shared nothing system like Erlang.
That said, the Erlang VM doesn't work this way. There have been experiments like the shared and hybrid heaps to enable this, but they've largely been failures, not because they're conceptually flawed, but because the garbage collection in Erlang is relatively simplistic. Erlang processes are independently garbage collected so they never needed to deal with concurrent garbage collection or a shared heap before.
Erjang (Erlang on the JVM) uses Java's shared heap and lets you use the wealth of pluggable garbage collectors available on the Java platform.
In a quick test of the "chameneos-redux" benchmark on Erlang BEAM vs. Erjang, a benchmark which generates lots of messages and can benefit immensely from sharing state, Erjang was about twice as fast as Erlang.
function fib(n) {
var a = 0, b = 1;
for (var i = 0; i < n; i++) {
var temp = a + b;
a = b; b = temp;
}
return 'fib(' + n + ') = ' + a;
}
But how do we implement this on the Erlang VM? It doesn't support any of this dangerous mucking around with the values of variables! As you rightly point out, there are good reasons for this. What we can do is convert this to, essentially, continuation-passing form. This looks awkward is JS, but it gives the same answer:
function fib_cps(n) {
function forloop(a, b, i, cont) {
if (i < n) {
return forloop(b, a + b, i + 1, cont);
} else {
return cont(a);
}
}
return forloop(0, 1, 0, function(result) {
return 'fib(' + n + ') = ' + result;
});
}
That's what I had in mind. Does it sound more reasonable?
I still haven't gotten around to it...
Well, that's one way of putting it. This is what a native Erlang implementation of fibonaci numbers looks like:
-module(fib).
-export([fib/1]).
fib(0) -> [{0,0} | []];
fib(1) -> [{1,1} | fib(0)];
fib(N) when is_iteger(N) andalso N > 0 -> fib1(2,N,fib(1)).
fib1(N,N,[{_K1,V1},{_K2,V2} | _T]=Acc) -> lists:reverse([{N,V1+V2} | Acc]);
fib1(I,N,[{_K1,V1},{_K2,V2} | _T]=Acc) -> fib1(I+1,N,[{I,V1+V2} | Acc]).
Erlang is a functional programming language and as such it does a lot of list processing. Where imperative or OO programmers use for loops functional programmers work on lists, a lot. Yes, it will seem strange at first, but that the nature of the beast.
It is worth understanding why it looks odd:
* it uses pattern matching (what's that?)
* the function fib/1 has 3 clauses and fib1/3 has 2 (WTF?)
* it contains list operations (eh?)
Unless you understand those three things you can't write Erlang. Syntatic sugar to hide them from you is not your friend here.
The function fib/1 has three clauses - if N is 0 or 1 it returns the starting elements of the fibonaci sequence. If it is an integer greater than that it calculates the sequence using the function fib1/3
The function fib1/3 has 2 clauses. The first is the terminal clause - when I have counted up from 2 to N return the sequence.
The second clause is the recursive clause, calculate the current fibonaci number, stick it on the end of the list of all the fibonaci numbers calculated so far, and call myself for the next value up.
Acc is a list
[{I,V1+V2} | Acc] is a new list
with the new value {I,V1+V2} at the head of it.
Going into the clause the accumulator list looks like this:
[{11,89}, {10,55}, {9,34}....]
[{_K1,V1},{_K2,V2} | T] = Acc
Pattern matching says 'if this pattern matches' stick the appropriate values from the righthand side into the as-yet unmatched 'variables' of the left hand side. Because V1 and V2 have not yet been given a value they aquire the values of 89 and 55 in this instance.
The terminal clause (ie the first clause of fib1/3) also uses pattern matching:
fib1(N,N,Acc) ->
The mistake you are making is thinking that Erlang doesn't have a for loop like Javascript or Ruby, when the real difference is that Erlang doesn't have an '=' operator like Javascript or Ruby. In Erlang '=' is a pattern matching operator. You can't set the value of an Erlang 'variable' to anything, but that doesn't matter because Erlang doesn't have variables.
Pattern matching as a core language feature has as a consequence an absence of variables, which has as a consequence the absence of for loops.
Throwing out the baby of pattern matching for the bathwater of for loops is to miss the point big style.
Learn to love lists, learn to write recursive functions, learn to pattern match - you can't do functional programming without them.
Look at your native Erlang implementation of fib again. Would you say that it's easier to understand than the version I posted which uses a for loop? It uses an accumulator and an auxiliary tail-recursive function; I know you get used to writing like that after a while, but I'd like another option.
Haskell demonstrates conclusively that this is possible. We don't have to choose between pattern matching or mutable variables; we can have both, cleanly, as long as there's a way of keeping the mutable variables isolated in a safe box where they can't affect the rest of the program. In Haskell, this is the State or ST monad. In my proposal, mutable variables would be function-local, and such code is transformed to use tail-recursion. (This is what Haskell's State and ST monads do behind the scenes. The same could be done by a compiler with Erlang as the back-end.)
85% of the cost of softare is in code maintenance. Suddenly spawning multiple idioms for the same thing is madness. This proposal would directly increase the cost of running my software house - just not ever a good idea.
Please rebar-ify!