4 ms·

Reia is interesting, but ultimately misguided. Erlang's syntax is not a problem. It can actually help editors like Emacs to indent the code more intelligently.

by hassy 18y ago

Reia is interesting, but ultimately misguided. 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.

davidw 18y ago
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.
- hassy 18y ago
  > 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...
  - davidw 18y ago
    "Programming languages are not like hand tools": http://journal.dedasys.com/articles/2007/12/12/programming-languages-are-not-like-hand-tools http://journal.dedasys.com/articles/2007/12/12/programming-l... 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.
utx00 18y ago
Is going the other way possible? That is, could erlang's strengths be expressed through macros in lisp?
- PieSquared 18y ago
  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.
  - utx00 18y ago
    thanks.
  - celoyd 18y ago
    Actually, given call/cc (http://www.madore.org/~david/computers/callcc.html http://www.madore.org/~david/computers/callcc.html), it's not a big deal. I think Termite (http://lambda-the-ultimate.org/node/841 http://lambda-the-ultimate.org/node/841) is implemented in Gambit with call/cc.
    - celoyd 18y ago
      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 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.
jlouis 18y ago
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 ;)
snorkel 18y ago
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.

by hassy 18y ago

davidw 18y ago

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.

hassy 18y ago
> 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...
- davidw 18y ago
  "Programming languages are not like hand tools": http://journal.dedasys.com/articles/2007/12/12/programming-languages-are-not-like-hand-tools http://journal.dedasys.com/articles/2007/12/12/programming-l... 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.

utx00 18y ago

Is going the other way possible? That is, could erlang's strengths be expressed through macros in lisp?

PieSquared 18y ago
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.
- utx00 18y ago
  thanks.
- celoyd 18y ago
  Actually, given call/cc (http://www.madore.org/~david/computers/callcc.html http://www.madore.org/~david/computers/callcc.html), it's not a big deal. I think Termite (http://lambda-the-ultimate.org/node/841 http://lambda-the-ultimate.org/node/841) is implemented in Gambit with call/cc.
  - celoyd 18y ago
    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 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.

jlouis 18y ago

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 ;)

snorkel 18y ago

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.