Slashdot Mirror
Ioke Tries To Combine the Best of Lisp and Ruby
synodinos writes "Ola Bini, a core JRuby developer and author of the book Practical JRuby on Rails Projects, has been developing a new language for the JVM called Ioke. This strongly typed, extremely dynamic, prototype-based, object-oriented language aims to give developers the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax."
The parentheses just disappear after you've coded Lisp for a while. Also, try paredit.el for Emacs. With that turned on, you don't edit text, but sexps. It's wonderful, once you get used to it.
As for Lisp itself, well, 20 years ago did for the first time many of the things that mainstream languages today are just beginning to obtain, like closures, arbitrary lexical scoping, highly dynamic data structures, and (in Scheme's case) call/cc. One thing gcc just implemented is per-function compiler optimization settings. Common Lisp has had a facility for that since the beginning of time.
One thing that still isn't matched by other languages, however, is Lisp's macro system. It's far more powerful than C macros. You can define new control structures, implement sub-languages, and construct any higher-language construct you want. And these features you build all look just like native language constructs.
And don't even get me started o CLOS, which is one of the very few object-oriented systems to provide a clean multimethod dispatch solution.
I haven't used Self, but going by my experience with Javascript, prototype-based languages suck compared to conventional class/metaclass based ones.
Generally true. Javascript was never intended for writing large programs. The object system is basically a hack on top of dictionaries. That's easy to implement, but doesn't scale well.
This is one of the classic things one can do wrong in language design, and which tend to have to be fixed in later versions, painfully. Some other classic boners are leaving out a "bool" type (C and Python), not providing generics in a statically typed object-oriented language (C++ and Java), and not designing in separate compilation (ISO Pascal).
Ioke is cute, but there's just no really good reason for such a strange syntax, and it's going to turn too many people off. Using whitespace as an operator (really!) is probably a bad idea. The ability to change the operator precedence dynamically may be "fun", but does not lead to readable or maintainable code. Experience with "read macros" in LISP indicates that rewriting code during input isn't good for readability either. On top of all this, Ioke allows regular expressions in code, like Perl. (It's not clear from the description if you can use regular expressions in the read macros to rewrite the regular expressions in the code. I think you can.) So Ioke brings together the least readable features from four different languages.
People who come up with "l33t" ideas like this need to be put on maintenance programming of code written by others for six months or so.
Dylan had a very powerful macro system.
http://www.opendylan.org/
with all the advantages of a late-bound language.
Patriotism is a virtue of the vicious
There is a lot of buzz around Scala and F#, and considering the limitations they lift from the more conventional mainstream languages it's understandable. But I think Clojure transcends both these languages and many other new on-top-of-another-platform languages because it doesn't just take the latest trendy language features and mix them with new syntactic sugar. It has a very well thought design that feels very right, elegant, and powerful.
I can't recommend enough the screencasts by Rich Hickey, the language designer and main implementer.
The 5th screencast, Clojure Concurrency, is most recommended by me for programming language aficionados. It's a long overview of the language and its philosophy regarding concurrency programming. After I saw that one, I was very excited about Clojure in a way that none of the latest languages made me feel.
I sometimes look at programming as a form of Compression. In this case it's decision/rule/logic compression.
:).
:).
:). We'd rather do stuff like:
...
You can express any program with an infinite list of "IF THEN"s, but that's not very useful (and way too much typing).
So that's where programming languages come in. Not all compression algorithms are great for all sorts of data and situations, similarly not all programming languages are good at all things. Of course there are some compression algorithms which are just plain crap
A language that's powerful for a certain field will have good defaults so that a programmer does not have to do as much work to compress the rules. Typical faxes will compress very well using the standard fax compression method.
While a lot of CS academics like languages that are powerful for the code you have to write (which is a good reason), do not be surprised when programmers in the real world pick languages that are powerful for the code they don't have to write (aka modules/libraries).
You can have a newfangled language which has better compression that other programming languages so that you only need 1000 lines to do X, but it still is not that attractive if you still have to write all 1000 lines yourself, in contrast to using a language which requires 2000 lines to do X, but you only have to write 500 of those lines yourself. Others have already written the other 1500 lines AND best of all have documented and are maintaining them
Marketing and positioning can be quite important in order to somehow convince enough people who like writing those 1500 lines to take up your new language.
You can't expect lazy crap programmers like me to write all that code
use LWP;
Or:
import pyrad.packet
from pyrad.client import Client
Another problem with some languages favoured by CS academicians is they require very very smart people, and there are far fewer very very smart people than smart people (and far fewer smart people than stupid people).
At a certain point conciseness (compression level) isn't as significant compared to the other overheads.
So the ultrageniuses might not be much faster than the "merely smart" in writing the modules that the stupid people are likely to want to use, even if they use your superconcise language.
And if there are 10x more "merely smart" than ultrageniuses, no wonder the stupid people pick the less powerful language - there might be 3-5x more libraries that they'd want to use.
The ultrageniuses would be doing ultragenius stuff, so the modules they write might not be so useful for stupid people like me.
And that's why some crappy languages are so popular (but I could be wrong since I'm stupid).
There's more out there in high-level land than the current crop of scripting languages.
It's funny you mention that Python isn't QUITE fast enough to write an operating system in. I'd say it's dead-slow to write an operating in. Some guys at OLPC thought it was a good idea to write a window-manager in Python. And that is already dead-slow. Python as of now is still an interpreted scripting language. And I wouldn't exactly set the bar as low as to take PHP as a classic example of a fast, well designed language. I'm sure even the most rabid PHP fanboi (if they even exist), will agree with me.
There are a good number of high-level languages which are a good bit more flexible at a much higher performance rate than Python. Take some of the functional languages like Haskell or ML, Lisps like CL or Scheme, or Forth or Smalltalk. Not that shootouts say everything, but just compare a few benchmarks at http://shootout.alioth.debian.org/
And why are they faster? Because they can be (byte-)compiled quite efficiently. Python however was never designed with compiling in mind. And as such, there still isn't a worthy full-fledged Python compiler for real-live use. And as I understand it, Python is very dynamic in a way that's gonna be quite hard to compile.
Now Python is an elegant scripting language that is easy to pick up, has a nice and big standard library and has it's niche, but people that dare to write ' is vastly superior, both in overall design and performance, to other languages that provide a similar level of abstraction', either blatantly choose to ignore decennia of computer science, or still have a lot of cool stuff to learn.
Seriously, why is everything in/about/emulating Ruby right now? From what I understand, this implementation isn't necessarily that much like Ruby, but given the summary it seems people would like to think/hope so.
Don't get me wrong, I like Ruby but I would never seek to emulate it. The language libraries are inconsistent and poor in many cases and there are other serious design issues. It's a cute little language great for shell scripting and quick one-offs, but I still cannot take it seriously after trying to prototype out various projects in it and seeing many weaknesses.
If you're not using some existing implementation/framework in Ruby such as Rails, why use it at all? Smalltalk and Lisp have done the same things are more much better since the beginning of time. Both languages are far cleaner, with Smalltalk having the better syntax IMO and Lisp having the advantage in power. If you could combine Smalltalk's dev environment and VM with Lisp's power, then we would have something worthy of actually looking at.