Erlang's syntax is not a problem. It can actually help editors like Emacs to indent the code more intelligently. Eg if you're in a clause of a case expression and you pressed Return without pressing comma first, the editor can infer that this is the end of the expression and indent the next line accordingly (to line up with the `case` above).
More generally speaking, if you're not willing to overlook minor issues of syntax in order to get to use tonnes of awesome stuff that it gives you access to... well, in my eyes you're more of a fashion-conscious fanboy than a pragmatic engineer.
If you have trouble remembering what comes when, here's how it works: comma is "and", semicolon is "or", and full stop is "end of definition". These are Prolog's legacy.
Throwing out single assignment and introducing workarounds for pattern matching to still work is a bad idea. So is introducing loops. There are very good reasons for why Erlang is the way it is. The language was not designed by a committee; most of the design decisions have been driven by user requirements. Single assignment is one of such decisions -- it wasn't made because Joe Armstrong was a fan of functional programming, it was made because it made the programs easier to read and debug, enabled hot code reloading, and made the GC simpler. And loops? Loops are close to worthless when you can have higher-order functions like map, filter and fold. I've never missed loops in a year of writing Erlang; come to think of it, I rarely use loops in the Ruby code I write anymore.
LFE is a project with much more potential. It stays close to Erlang semantically, while adding features that Erlang does not have, like real macros, and that's where the real added value is.
I disagree. I think it's an interesting experiment for a number of reasons:
- Sure, syntax doesn't matter that much. But it does, some, and something like Ruby is more convenient than Erlang for me and my tastes. Syntax does matter for something like html templates - Ruby beats Erlang for that hands down.
- The objects are an interesting touch. Not sure how they'll work out in the grand scheme of things, but it's an interesting idea. Erlang could use a few higher level constructs like that.
- Single assignment? There are certainly some good reasons why Erlang is what it is, but perhaps this language might make it easier to do other things with Erlang as well. For instance I would never use it for sysadmin type tasks as it stands now (Erlang STILL can't read from the proc filesystem with read_file, as of whatever ships with Hardy Heron). Maybe they'll even be able to retain some of the Erlang strengths that lay underneath and make it easier for The Masses to use.
> The objects are an interesting touch. Not sure how they'll work out in the grand scheme of things, but it's an interesting idea.
Erlang already has objects. They are just called processes.
Trying to bolt on a class system on top is just going against the grain.
> Single assignment? There are certainly some good reasons why Erlang is what it is, but perhaps this language might make it easier to do other things with Erlang as well. For instance I would never use it for sysadmin type tasks as it stands now
You would not use C or Java for sysadmin tasks either. You would not use Ruby to write a 3D game engine. Erlang was not designed to be a general-purpose language, much less a scripting one. Right tool for the right job...
The key point is that yes, some things are better than others, but each language is a toolbox that is potentially capable of solving a wide variety of problems. If you can broaden the range of tasks your toolbox handles without sacrificing anything important, that's a big win.
Also:
> Erlang already has objects. They are just called processes. Trying to bolt on a class system on top is just going against the grain.
Did you read about the language? The objects are processes, so rather than bolting on something that doesn't work, it's providing an easier, more familiar way to access something that often requires a fair amount of boilerplate in Erlang itself.
Erlang's syntax is not really a problem for me either. There are part of the semantics I dislike, but the syntax is not hurting me that much.
Erlang's primary problem is that it currently can't cope with the things people try to throw at it. I've seen people opt for better string handling, but string handling isn't the force of the language. It is almost domain specific as a language.
Personally, I don't think Erlang is the answer to the "multi-core-problem" either. There has to be a nicer way than threads-on-steroids ;)
I disagree. Reia is not misguided at all. It's not trying to improve Erlang but rather expose Erlang features to those who don't quite grock Erlang's idioms. Programming languages evolve because someone, perhaps a fashion-conscious fanboy even, took a little from this language and some of that language and mixed them together. You may not agree with the result but it may suit others just fine.
Not without a pretty weird lisp VM or something. Or maybe separating different threads into processes and doing the communication hidden inside the macro? Hum, I dunno. Might be worth looking into, but it seems either very hard or impossible... granted, I don't have as much experience with macros as other people on this site might have, so maybe someone else will correct me in my assessment.
I'm a fool. If I'd bothered to look it up first, I would have remembered that the actor model was integral to the invention of Scheme. See Sussman & Steele, Scheme: An Interpreter for Extended Lambda Calculus (AI Memo 349), 1975 (the first link at http://library.readscheme.org/page1.html). From the acknowledgements:
This work developed out of an initial attempt to understand the actorness of actors. Steele thought he understood it, but couldn't explain it; Sussman suggested the experimental approach of actually building an "ACTORS interpreter". This interpreter attempted to intermix the use of actors and LISP lambda expressions in a clean manner. When it was completed we discovered that the "actors" and the lambda expressions were identical in implementation.
I don't know why people still do this... you'd think it'd be obvious while they were making the language's main page. "Oh, this is a new language, maybe I should show people what it looks like."
In my opinion, the very first thing on any language's main page should be a hello world. The very second thing should be links to other simple examples.
Too many projects waste valuable front page space with minutiae before they even tell you what the hell the project is or why you should care. Programming project sites are usually more focused on people with commit privileges than they are on recruiting new users. Which is probably a big reason why so many projects never gain any momentum beyond the founding members.
One of my personal pet peeves: Why do so many open-source projects make you search everywhere (or even download code) in order to find out what freaking language they use for the project? With most programmers only knowing/using a few languages, it seems that this would be a prominent bit of information to impart on the front page, yeah?
I shouldn't have to download code to learn that the project is written in Intercal or C#, ferchrissakes!
"This project is written in XXXXX" is more helpful to me than knowing the last few esoteric bugs that were fixed.
I cringe every time I see the most valuable real estate on a programming project site used to show the revision history.
That bugged me too. For my own language, I put the link in the second paragraph here: http://www.hecl.org because, as I wrote "I personally can't stand web pages for new programming languages without a quick link to some examples."
If I had a nickel every time my girlfriend saw me laughing or giggling at "computer stuff" and then rolled her eyes, I'd be making money in a very weird way.
This is a bit of a misconception about how memory works. Erlang's strength of processes memory encapsulation and share nothing semantics are not compromised by alloying multiple assignment. In fact you can very easily model Multiple assignment with Single Assignment, and hand off the managing of that to the compiler.
Erlang's syntax is not a problem. It can actually help editors like Emacs to indent the code more intelligently. Eg if you're in a clause of a case expression and you pressed Return without pressing comma first, the editor can infer that this is the end of the expression and indent the next line accordingly (to line up with the `case` above).
More generally speaking, if you're not willing to overlook minor issues of syntax in order to get to use tonnes of awesome stuff that it gives you access to... well, in my eyes you're more of a fashion-conscious fanboy than a pragmatic engineer.
If you have trouble remembering what comes when, here's how it works: comma is "and", semicolon is "or", and full stop is "end of definition". These are Prolog's legacy.
Throwing out single assignment and introducing workarounds for pattern matching to still work is a bad idea. So is introducing loops. There are very good reasons for why Erlang is the way it is. The language was not designed by a committee; most of the design decisions have been driven by user requirements. Single assignment is one of such decisions -- it wasn't made because Joe Armstrong was a fan of functional programming, it was made because it made the programs easier to read and debug, enabled hot code reloading, and made the GC simpler. And loops? Loops are close to worthless when you can have higher-order functions like map, filter and fold. I've never missed loops in a year of writing Erlang; come to think of it, I rarely use loops in the Ruby code I write anymore.
LFE is a project with much more potential. It stays close to Erlang semantically, while adding features that Erlang does not have, like real macros, and that's where the real added value is.