5 ms·

Reia Programming Language: Python/Rubyesque scripting language on the Erlang VM

46 points by iamelgringo 18y ago

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.
davidw 18y ago
I wonder if "ant turd tokens" is the official, computer science term? Cracked me up, though... I find those annoying in Erlang. My wife was curious about what I was laughing so hard at, but realized it was "computer stuff".
- yan 18y ago
  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.
- agbell 18y ago
  I found that the 'ant turd tokens' were the most frustrating thing to learn/remember when I was playing around with erlang. goodbye ant turds
13ren 18y ago
Erlang with Python-syntax is a great idea. But couldn't see any sample programs (just one-line snippets) EDIT some of Reia is written in itself: http://github.com/tarcieri/reia/tree/master/src/reia/types http://github.com/tarcieri/reia/tree/master/src/reia/types http://github.com/tarcieri/reia/tree/master/src/reia/core http://github.com/tarcieri/reia/tree/master/src/reia/core
- spydez 18y ago
  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.
  - davidw 18y ago
    That bugged me too. For my own language, I put the link in the second paragraph here: http://www.hecl.org 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."
  - Shooter 18y ago
    Most programmers SUCK at marketing. 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.
quasimojo 18y ago
vying to be slower than groovy?
iamwil 18y ago
The concurrent portion of Reia isn't yet supported. They're still working on getting the sequential part 'rock solid'.
njharman 18y ago
Multiple assignment? I think that goes too far. I would like an Erlang with modern string handling and built in re but not if the cost is losing one of Erlang's strengths.
- aconbere 18y ago
  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.

46 points by iamelgringo 18y ago

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.

davidw 18y ago

I wonder if "ant turd tokens" is the official, computer science term? Cracked me up, though... I find those annoying in Erlang. My wife was curious about what I was laughing so hard at, but realized it was "computer stuff".

yan 18y ago
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.
agbell 18y ago
I found that the 'ant turd tokens' were the most frustrating thing to learn/remember when I was playing around with erlang. goodbye ant turds

13ren 18y ago

Erlang with Python-syntax is a great idea. But couldn't see any sample programs (just one-line snippets) EDIT some of Reia is written in itself: http://github.com/tarcieri/reia/tree/master/src/reia/types http://github.com/tarcieri/reia/tree/master/src/reia/types http://github.com/tarcieri/reia/tree/master/src/reia/core http://github.com/tarcieri/reia/tree/master/src/reia/core

spydez 18y ago
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.
- davidw 18y ago
  That bugged me too. For my own language, I put the link in the second paragraph here: http://www.hecl.org 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."
- Shooter 18y ago
  Most programmers SUCK at marketing. 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.

quasimojo 18y ago

vying to be slower than groovy?

iamwil 18y ago

The concurrent portion of Reia isn't yet supported. They're still working on getting the sequential part 'rock solid'.

njharman 18y ago

Multiple assignment? I think that goes too far. I would like an Erlang with modern string handling and built in re but not if the cost is losing one of Erlang's strengths.

aconbere 18y ago
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.