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."
Ola Bini has no beard. The only proof you need that this language will fail?
the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax
In other words, this is just a reinvented Ruby targeted to the JVM. Without macros, what's the point? Why not just stick with Common Lisp and get all the power of Lisp, not just some of it, and still have a "small, regular syntax"? You can even use ABCL if you want to target the JVM.
I haven't used Self, but going by my experience with Javascript, prototype-based languages suck compared to conventional class/metaclass based ones. The problem is that parents of types must be *instances* of their parent types, and there isn't always a suitable kind of instance to use as a prototype. Either you end up coding around the prototype system and emulating conventional constructors, or you end up specifying special uninitialized states for base classes.
Prototype languages make it easy to use the GoF prototype design pattern, true, but I find myself thinking "hrm, I need a new type" far more often than "Hrm, I need a prototype system for object initialization."
Also, Python and CLOS style metaclasses give you all the flexibility of a prototype system.
I'm all ears for any advantages the latter might have.
People think that s-expressions are a poor syntax. These people are wrong.
Seriously, if you give yourself the change to wrap your head around it, s-expressions are both elegant and powerful. Representing your code as a data structure is what makes lisp lisp. Take that away, and you might as well just use ML.
New languages are announced every week or so in different places... it doesn't change the fact that the language that most big projects rely on now is one of the old guard. C is, despite it's incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.
Another pocket language with idiosyncratic design choices that seem just right to the understimulated nerd looking for fame.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
The idea of these new languages (Python, Java, Ruby, and presumably ioke) is to abstract very common functions to increase the speed of development.
Every layer of abstraction increases the "power" of the language from a development point of view, allowing developers to do far more than they could with a single line of code, trading off flexibility, and performance.
The idea of a new language is to deliver as much "quick access" functionality as possible (saving the developer having to implement their own low level functionality such as string classes, array handling and perhaps memory management) while compromising as little as possible on flexibility and performance.
If ioke delivers a best-yet mix of these trade offs, then it stands a chance to become the Next Big Thing. Personally, I think that Python is the state of the art when it comes to highly functional development languages that still deliver good performance and flexibility. It's not quite fast enough to write an operating system in (although there was an effort called Unununium which tried but never took off), however it is vastly superior, both in overall design and performance, to other languages that provide a similar level of abstraction such as PHP.
I hate printers.
In my opinion, those are the three projects that one has to look into for cool (if you're a PL geek) stuff that is nonetheless bordering on mainstream: Clojure, Scala, and F#. Last two in particular, as Scala seems to be the "future of Java" to many advanced Java programmers who got tired of language limitations, and F# is being made a first-class supported language for the next .NET and Visual Studio release.
Meanwhile, yet another my-own-programming-language-of-the-day is getting old. There are announcements of those pretty much every week on LtU. It may be interesting if it really explores some new dark corner in language design (particularly experiments with more powerful typing systems). But "combining the best of X is Y" is not it, sorry.
Not one single soul in the world who was ever going to make a language, is now not going to, because of that rant.
the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax
So, it's Lisp then?
Seriously... in terms of small regular syntaxes you don't get smaller and more regular than Lisp:
(source).
Next smallest and most regular syntax for a useful language is probably smalltalk, but that's too long to post here. It's worth noting that smalltalk (particularly its first-class statement blocks) was a heavy influence on ruby. Smalltalk also gets close to hitting the 'nice' requirement, which IMO Lisp is a long way from.
[Python]'s not quite fast enough to write an operating system in (although there was an effort called Unununium which tried but never took off)
Unununium's kernel was, I believe, written in C. The user interface, userspace applications and drivers would have all been written in Python.
Unununium didn't take off because its developers had no clue about OS design. They apparently spent most of their time boasting about how their operating system didn't have a kernel (it did; its kernel was a slightly modified Python interpreter[1]) and how it was such an innovative design (when all it did was replicate some of the achievements of traditional language-based systems that were popular in the academic research community in the 70s and early 80s, cf. Smalltalk-80, which although now generally considered just as a language was originally considered by its developers and users as an operating system, or the earlier CMU Hydra system which was built around similar principles), and not enough time actually writing the damned thing.
[1]: The issue seems to be one of understanding what a kernel is. The unununium developers seemed to believe the defining factor of a kernel is that it provides inter-process protection by allocating different memory spaces to the different processes. Under this view, many modern OSs don't have kernels, including Singularity and JX. Also, some older ones, including 16-bit Windows and Amiga.
Yes, people often don't see the point of things they've never tried, or of features that are missing from their current favourite language.
In the old days some people had a terribly complicated device called a "stove" which they used to prepare all kinds of different food. There was no standardization at all. Everybody used different ingredients and different ways to prepare the food. It was horrible. But then came the golden age of standardization. MacDonalds and Starbucks rule!
Is that another way of saying real programmers code assembly? Because taken out of context and to its logical conclusion, your argument would seem to imply that.
Language constructs can be good, and can be bad; if your language is too full of them, it becomes write-only, but if it's too lacking, you end up with Java and you need to use design patterns to do everything (people using more functional languages laugh at the pattern hype in OO world, because most design patterns are really just ways of working around the limitations of Java and still getting your work done).
We already have a programming language with a simple syntax and the strengths of Lisp and Ruby. It's called Lisp.
Badass Resumes
As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems.
You are confusing reputation with reality.
LISP was the first language that required garbage collection, and that radical idea was fought tooth-and-nail by the rest of academia and industry. But the garbage collection technology developed was fast and reliable (I knew many of the people intimately involved in making the GC for Scheme at MIT). There was certainly an overhead that was paid for running a GC, but the smart folks at various academic and research institutions figured out how to minimize that overhead, and, moreover, spread it out pretty evenly so that your mission-critical system didn't suddenly go autistic for 30 seconds while it went through a sweep.
Fast forward to today. You do realize that Perl has a built-in garbage collection system, right? And that Perl runs thousands upon thousands of web sites, some of which are quite large and commercially successful? That there are thousands of people using it every day?
So, my conclusion: having or not having a garbage collector is not a relevant issue. Lisp just does not, "face real problems in garbage collection and system resource management," nor did it "traditionally [face] such problems." You are parroting an old and stale bit of propaganda.
If these issues were so crippling, as you imply, then how would it be possible to write an entire operating system in LISP? Perhaps you never saw any of the machines like that, but they were legion. There were at least three reasonably successful companies started on that very idea.
But your final paragraph above ("But I've also cleaned up ...") complains about something that has absolutely nothing to do with LISP, but with poor programming. I've taught LISP at MIT, and find that people who have learned LISP from the classic text Structure and Interpretation of Computer Programs (notice the title does not say anything about LISP or Scheme) are far better programmers than those who have not. The people who have not been taught LISP make more of the egregious errors you suggest, because the standard way of learning LISP, in the classroom with SICP, beats the idea of proper use of abstraction into the students.
In other words, and politely, most of your post is bunk.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
C is likely to remain strong until we just have more CPU power than [...]
We already do (have more than C can handle[1]): dual and quad core processors.
There is as of now no really good parallel (or multi-threaded) language. Java and Erlang are perhaps the best, which essentially says where we stand right now.
Please do not talk about Posix thread libraries, they do tell enough about the memory model. Java was the first language to define one, but it is not 100% clear. C++ is just about to define one for itself[2].
Therefore for example D is not the next language.
[1] Not that you said or even implied that.
[2] http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/
Lisp did fairly well in the areas where the problems it solved particularly well were common; C and friends did well where the things it dealt with well were the main challenges. when C was conquering the world, the latter were more common than the former. Increasingly, the problems Lisp deals with well have become relevant to more software, but C-based languages are pretty entrenched (both in systems and in programmer's minds), so instead of Lisp seeing a resurgence, you see C-like languages with more and more Lisp-like features bolted on. (The same is true with "Smalltalk" in place of "Lisp", too.)