Reia Programming Language: Python/Rubyesque scripting language on the Erlang VM
wiki.reia-lang.org
wiki.reia-lang.org
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.
- 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.
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...
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.
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 ;)
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.
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/core
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.
My wife was curious about what I was laughing so hard at, but realized it was "computer stuff".
goodbye ant turds
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.