This post originated from an RSS feed registered with Java Buzz
by Wilfred Springer.
Original Post: Mystery Programming Language Hiding in Plain Sight
Feed Title: Distributed Reflections of the Third Kind
Feed URL: http://blog.flotsam.nl/feeds/posts/default/-/Java
Feed Description: Anything coming to my mind having to do with Java
It probably will not strike you as a surprise that there is a lot to do these days on the next programming language. Java - wildly popular as it may be - does have some limitations and there are some things that you just cannot shoehorn into into the language without violating its conceptual integrity.
From all of these pretenders to the Java throne, we at Xebia probably like Scala most, for various reasons. We like the fact that it marries two programming paradigms (functional and OO), that it can be extended, and that there is type safety without paying a huge toll. But there are obviously alternatives such as Erlang, Clojure and LUA (and Fortress, perhaps, some day?).
But hold on, there is more… There is something out there, and you may not be aware of it. Before I reveal its name, I will refer to it as programming language Rarebit.
Rarebit has immutable state only. In that sense, it's more like Erlang than like Scala. In terms of Scala, everyting in Rarebit is a val. (As a consequence, programming recursive structures is not uncommon in Rarebit.)
Rarebit has pattern matching, just like Erlang and Scala. In fact, it takes pattern matching to a whole new level, since your entire program is basically driven by pattern matching. (Pattern matching driven is the new 'driven'?)
Like Scala, XML is a first class citizen in Rarebit. There is a difference though. In Scala, if you want to address a particular node in your document, you use an XPath-alike expression. In Rarebit, it is really one-hundred-percent XPath.
Like Scala and Clojure, Rarebit lives on the Java VM. Normally, it is interpreted, but it is also possible to compile Rarebit downto plain old bytecode.
Unlike Scala and Clojure, Rarebit does not allow you to call native Java libraries just like that. You can however get that by using extensions that I will discuss later on. However, out of the box, it doesn't support it. That's a bless and a curse, but I am hanging towards the bless. Because of this 'limitation' Rarebit really is guaranteed to be side-effect free. And that's not all, because:
Unlike Scala and Clojure, Rarebit does not require the VM. There are other versions that run directly on the host operating system. In that sense, Rarebit is more similar to Ruby and Python: they all come in a C-version and in a J-version.
Unlike LUA and Ruby, the entire language is specified, submitted to a standardization organization, and officially endorsed.
Unfortunately unlike Scala and Ruby, Rarebit is extremely stable.
Rarebit is dynamically typed, just like Clojure and Erlang, although a later version (largely backwards compatible) allows you to work in a more strongly typed manner, more like Scala.
Rarebit does allow you to pass around function pointers, and it does support something that - with a bit of imagination - you could consider support for closures. (Just like Scala.)
Rarebit is extensible. That is, it allows you to add more language constructs to the language, although it's questionable if you can really talk about it in that way, since:
In Rarebit, your code is just data, just like in Clojure. So you can manipulate programs using programs easily.
Rarebit does however allow you to introduce new 'syntax' that will also allow you to call out to libraries outside of the set of functions supported by Rarebit itself. Note however that - if you use these features - you can introduce side-effects, which is clearly not necessarily a desirable feature.
Unlike Scala and Clojure, Rarebit has very decent IDE support. (I guess it won't be long until Scala support in IntelliJ becomes up to par.)
Hopefully you are getting curious by now. Because here comes the big surprise: Rarebit not only is capable of running on the Java VM; it has already been part of the Java language runtime since ages, hiding in plain sight. It was there all along, when other programming languages demanded an SPI for plugging themselves into the JRE, it was there during the debate on getting invokedynamic in the VM. In fact, if I remember correctly, then it was already there in Java 1.4, but it was certainly already present and available for the VM around that time.
Sounds pretty good huh? I bet you want to get your hands on that programming language. So here goes nothing: