Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Greg M
Is this you? Claim Profile »
1 year ago
in Why Make Erlang a Functional Language? on Humanist → Blog
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.
1 reply
1 year ago
in Network Programming in Erlang | 20bits on 20bits
"so-called modern languages like Java, Ruby, or Python"
What? Who so-called them that? None of those were even modern when they were designed, let alone now.
What? Who so-called them that? None of those were even modern when they were designed, let alone now.
1 reply
Nick Gerakines
I think he meant to say "so-called popular languages like Java, Ruby or Python"
1 year ago
in The Factor Attraction on Phil Dawes' Stuff
There's a lot to be said for languages that make it hard to write bad code. Oh the painful, wasted hours I've spent wading through code in languages that make it easy. I like this effect in languages with bondage-and-discipline type systems in particular - it's neat when the penalty for writing bad code is having to document it rigorously enough to justify it to the type system.
1 reply
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.