Prolog is a "logical" programming model, not "functional". The erlang syntax has nothing to do with the fact that its functional.
Luke Hoersten
· 1 year ago
Your absolutely correct and actually that was the point I was trying to make. Though Erlang looks weird on the surface, it's actually much more fundamentally different than people realize. It's almost like complaining that a 5,000 page book's cover is too hard to look at when there are 5,000 pages of content behind it. I never meant to imply that Prolog was a functional language. I was simply trying to get the "syntax issues" out of the way to get to the good stuff =)
Eric Florenzano
· 1 year ago
Also, I think that functional programming's inherent referential transparency makes it much harder to screw up in the highly concurrent types of programs that Erlang was designed for.
Luke Hoersten
· 1 year ago
Good point. That's similar to what I was trying to get at with the "type policy issue" discussion but you've hit it right on I think. To me, at least, it makes Erlang a much more natural language to program in because it's clear what "the Erlang way" of doing things is.
Alain O'Dea
· 1 year ago
This is a very good overview of the reasoning behind some of the more fundamental design choices in the Erlang VM. I found it very interesting and informative.
Why does Erlang copy data between functions and messages if it has immutable data? It seems like copying is only really required for isolation if data is mutable. I have read that it certain circumstances (large binaries or lists for example) that the arguments/messages use shared memory under the hood if the receiver is local.
Luke Hoersten
· 1 year ago
Erlang may or may not actually copy the data. The point is that if the user is unable to treat the data as mutable, the compiler or VM can know more about the data and optimize where possible. Think of it like copy-on-write except without the write, we don't ever need to copy. So to the user, the data is always "copied." Similar tricks are done with tail recursion etc.
Hynek (Pichi) Vychodil
· 2 months ago
Erlang always copy data because strict process isolation and soft-realtime GC.
Phil Harnish
· 1 year ago
Is this the library you mentioned in our conversation? I am pretty familiar with these modules--I even used a couple in my final project (pg stands out). Unfortunately there is nothing in here that I saw could be forced into a priority queue.
I seem to remember going through these modules with you to see if anything would work. It was so long ago so I may remember wrong :)
Luke Hoersten
· 1 year ago
There is no direct implementation of a priority queue in the Erlang stdlibs as far as I know but it has everything you need to build one. It's pretty reminiscent of C++'s stdlibs with sets, queues, trees, and dictionaries. Googling "erlang heap" turned up a heap sort which looks comparable to any imperative language. You wanted something pre-made though, correct?
Greg M
· 1 year ago
Nice article, the core point is very sound, but a couple of minor flaws: Firstly the syntax of Erlang comes largely from Prolog as you said, but Prolog is not a functional language (and one might argue that putting so much syntax from a logic-programming language into a functional language is a big part of what people are complaining about with Erlang syntax). And secondly I don't believe that too much work has gone into using the immutability properties of Erlang code as a basis for compile-time optimization, although in theory it's certainly possible. Unfortunately Erlang only has the nice properties of functional languages at the smallest scale, the explicit fine-grained concurrency makes it harder to reason about on a larger scale.
Luke Hoersten
· 1 year ago
I agree with you on both points. The first one I've addressed countless times already in response to other comments.
The second point, I believe, is partly why Erlang has been so popular in industry: it's a small and simple language. Simple fine-grained explicit concurrency works well and composes well enough with a very shallow learning curve. This was done by focusing on a smaller problem set and cutting some of the functional features available in academic languages. Implicit concurrency, for instance, is still very academic and doesn't have the pragmatic efficiencies that I tried to highlight in the conclusion of my post. There are already many fully-featured functional languages out there and you see how well they've done in industry. Point taken, though.
Most functional languages start with abstraction and cut away until the hardware level is reached. Imperative languages tend to start with hardware and add abstraction. Erlang is one of the few functional languages that took the lessons of the highly abstracted functional languages and made it machine aware. Hybrids are the key and are why languages like Python and Ruby are becoming so popular.
Banador
· 1 year ago
Your site has beautiful layout and it's readable. Thank's also for information!
Too bad Erlang sucks in the shootout. It gives some wrong signals about the language to newbies.
Luke Hoersten
· 1 year ago
Thanks for the comment. Unfortunately, I know what you mean. Programmers seem to be conditioned to look for a catch-all language and languages that fit a specific domain are easily cast aside for the wrong reasons.
Luke Hoersten
· 1 year ago
Tony Arcieri, creater of Reia, a Python-like scripting language built on the Erlang VM, has written a great article about single assignment variable myths. He definitely clears up a lot of things I had trouble explaining in my article. I don't have any argument against multiple assignment variables, only pointers which are pointers.
wow goud
· 1 year ago
Luke, I'm just curious, do you happen to live near Antwerp (Belgium) ?
The name 'Hoersten' was mentioned during one of my employer's recent gatherings and I was curious if it's you. You know, the world's a small place sometimes. :-)
Luke Hoersten
· 1 year ago
That is not me though my family is from Germany. If we've come as far as the US I imagine we've spread to Belgium as well.
EStau
· 4 weeks ago
nice
mattrepl
· 1 year ago
Functional programming doesn't require syntax as messy as Erlang's [1] and Prolog, from which Erlang's looks were taken, is a logic programming language.
Also, Erlang's ugliness in referencing functions as arguments [2] is pretty annoying for a FP language. __
[1] See Haskell, ML family, or Clojure.
[2] "fun someFn/<arity>" instead of "someFn". A good example of coding for the compiler.
rvirding
· 1 year ago
I think that if you actually looked at Erlang you would see that the reason for this is very simple and obvious. In Erlang it is perfectly legal to have *different* functions with the same name but with different arities, so if you want to reference a function uniquely you need to specify the arity. Of course, in some limited situations this may not be necessary but in the general case it is.
This is usually demonstrated in the second version of factorial shown, the tail-recursive one.
Sorry for being so sarcastic here but this feature is so basic that to have missed it is really surprising.
daniel b. giffin
· 1 year ago
yeah, the syntax for referring to top-level functions is pretty absurd. i've only barely peeked at Erlang, but i'm fairly sure the reason for this particular eccentricity is that (on account of the language's roots in Prolog) lower-case symbols are "atoms" (while upper-case symbols are variable references).
so when they added closures to the language (see Armstrong's fascinating "History of Erlang"), these could naturally be assigned to (upper-case) variables and then referred to by same. but top-level functions, historically lower-cased and distinguishable from atoms only by the syntax of their use (function application versus argument-passing), had to have their names mangled (prefixed with "fun", etc.) in order to distinguish them when used as arguments.
(i don't know why the compiler is so lazy as to require that you specify the function arity.)
it seems the best solution would have been to leave Prolog behind and name functions in the same way as other variables, reserving a special naming convention for atoms. Common Lisp's ":foo" syntax is not bad, and would leave lower-case names for variables.
i'm also worried about the scope of Erlang's atoms -- instead of using them to distinguish record types, i would prefer abstract datatype constructors (ala ML or Haskell) that are assigned to variables and thus scoped like everything else so that software can be safely composable (are atoms universally scoped in Erlang?!) -- but maybe this is an important mechanism for making hot code-update feasible (i've used a similar mechanism to ease schema migration in persistent object databases).
Luke Hoersten
· 1 year ago
When I say that "Erlang’s syntax derives from the functional programming paradigm," I don't mean to imply that Prolog is a functional language. I'm trying to point out that the syntax was chosen to try and facilitate the functional paradigm. Whether that was achieved or not is not in the scope of this post. The real point of this post is on data immutability and is why syntax was only mentioned in the first few paragraphs. I was trying to show that someone who wanted to bash on Erlang certainly could find something more fundamental than the syntax which they didn't even create.
I in fact agree that Erlang has a sub-par syntax but again, that wasn't the point of this post.
chris
· 1 year ago
Please don't post again until you know what "begs the question" actually means.
Luke Hoersten
· 1 year ago
From Wikipedia: "In contemporary usage, 'begging the question' often refers to an argument where the premises are as questionable as the conclusion."
That's exactly the usage I intended. It's almost like complaining that a 5,000 page book's cover is too hard to look at when there are 5,000 pages of content behind it. The syntax (the premises) are just as questionable as the conclusion.
All Comments
Why does Erlang copy data between functions and messages if it has immutable data? It seems like copying is only really required for isolation if data is mutable. I have read that it certain circumstances (large binaries or lists for example) that the arguments/messages use shared memory under the hood if the receiver is local.
I seem to remember going through these modules with you to see if anything would work. It was so long ago so I may remember wrong :)
The second point, I believe, is partly why Erlang has been so popular in industry: it's a small and simple language. Simple fine-grained explicit concurrency works well and composes well enough with a very shallow learning curve. This was done by focusing on a smaller problem set and cutting some of the functional features available in academic languages. Implicit concurrency, for instance, is still very academic and doesn't have the pragmatic efficiencies that I tried to highlight in the conclusion of my post. There are already many fully-featured functional languages out there and you see how well they've done in industry. Point taken, though.
Most functional languages start with abstraction and cut away until the hardware level is reached. Imperative languages tend to start with hardware and add abstraction. Erlang is one of the few functional languages that took the lessons of the highly abstracted functional languages and made it machine aware. Hybrids are the key and are why languages like Python and Ruby are becoming so popular.
Too bad Erlang sucks in the shootout. It gives some wrong signals about the language to newbies.
The name 'Hoersten' was mentioned during one of my employer's recent gatherings and I was curious if it's you. You know, the world's a small place sometimes. :-)
Also, Erlang's ugliness in referencing functions as arguments [2] is pretty annoying for a FP language.
__
[1] See Haskell, ML family, or Clojure.
[2] "fun someFn/<arity>" instead of "someFn". A good example of coding for the compiler.
This is usually demonstrated in the second version of factorial shown, the tail-recursive one.
Sorry for being so sarcastic here but this feature is so basic that to have missed it is really surprising.
so when they added closures to the language (see Armstrong's fascinating "History of Erlang"), these could naturally be assigned to (upper-case) variables and then referred to by same. but top-level functions, historically lower-cased and distinguishable from atoms only by the syntax of their use (function application versus argument-passing), had to have their names mangled (prefixed with "fun", etc.) in order to distinguish them when used as arguments.
(i don't know why the compiler is so lazy as to require that you specify the function arity.)
it seems the best solution would have been to leave Prolog behind and name functions in the same way as other variables, reserving a special naming convention for atoms. Common Lisp's ":foo" syntax is not bad, and would leave lower-case names for variables.
i'm also worried about the scope of Erlang's atoms -- instead of using them to distinguish record types, i would prefer abstract datatype constructors (ala ML or Haskell) that are assigned to variables and thus scoped like everything else so that software can be safely composable (are atoms universally scoped in Erlang?!) -- but maybe this is an important mechanism for making hot code-update feasible (i've used a similar mechanism to ease schema migration in persistent object databases).
I in fact agree that Erlang has a sub-par syntax but again, that wasn't the point of this post.
"In contemporary usage, 'begging the question' often refers to an argument where the premises are as questionable as the conclusion."
That's exactly the usage I intended. It's almost like complaining that a 5,000 page book's cover is too hard to look at when there are 5,000 pages of content behind it. The syntax (the premises) are just as questionable as the conclusion.