onsdag, januari 23, 2008

Polyglot, not panglot or omniglot

It's interesting. One of the common reactions I've heard to my recent writings about polyglot programming is something I really don't understand. Actually, I've heard the same objection to other persons writing about polyglot.

The objection is that just because I propose polyglot programming - using several different programming languages for different purposes in the same system - I can use whichever language
and as such should not try to find better languages or say that certain languages are bad.

But that's really a confounding of the issue. Just because I can use any language in the dynamic layer doesn't mean I should. In fact, just because polyglot programming as a strategy means you will use more than one language, it is even more important to be careful and use the best languages available for the task. Which is why I'm working to improve JRuby, why I'm evaluating Scala as a replacement for Java, why I'm working on a language based on Io. It's all about using the best languages. I may be a polyglot, but I'm definitely not a panglot or omniglot.

4 kommentarer:

Giles Bowkett sa...

It's panglot. Polyglot is pure Greek; panglot is pure Greek. Omniglot would be a hybrid of Latin and Greek, like "television." When TV was first invented, a disgruntled scholar said "The word is half Latin and half Greek. No good will ever come of it."

Raphaël Valyi sa...

Giles,

did you rather mean pure Geek?

But seriously, I think the polyglot concept is just good. The problem is that the industry is really hard to accept the idea. A large part of the IT industry tends to deny any competence of the coder except from coding inside one marketed language. That's because they prefer to see and sell developer skills as a fluid resource of swappable people. If you are better than that, you just have to run on your own and then it doesn't even matter you justify what you are doing, like being polyglot. It's really tough to find something in-between in the real life unfortunately.

Ari the Brown sa...

I'm curious - what do you think about splitting code up into multiple executables, and running all of those simultaneously while they communicate through sockets? This is what Qmail does. When I first heard about this, I thought it was just plain dumb. But then, I realized that this would allow multiple VMs to run, as well as have them be on multiple cores if need be.

I'm looking to try this out soon. Maybe for a test case, you could have a thread be contained in a separate file, and you use system() or fork { exec } to run it under a new VM. It's true, this may take up a whole bunch of unneeded space, but it will certainly be an interesting thing to try!

You might've just asked yourself "wtf is this kid talking about! Finish your hw" "NO". If all the key parts are stored in separate files and are run under different VMs and communicate through sockets, then you really can write a program and many different languages very easily. For instance, have a game network side be in erlang, and the backend be in some other language.

I don't know how the industry manages to code projects in many different languages, but that would certainly be how I would do it.

Diego sa...

Ola, I completely agree with you. I recently joined a java project that need to be refreshed and revitalized. Even to make it more pleasurable to work with, I come from dynamic languages like ruby, perl, python, etc..

I have been talking to them so much about a concept that has been in my head since jruby was announced. The funny thing is that I call it "polyglot java", sounds familiar?

Exactly like you said in your post: use the best language for the task.
My take is scala for thread safe code, maybe java when it comes to performance and jruby for expressing logic and business rules in plain english.

I even tried to pull a prank on my coworkers and make them believe that O'Reilly approved my proposal for a book on the topic.
Here is my fake oreilly book cover:polyglot java

I haven't been reading your blog recently so I didn't know you felt similarly. Maybe I should update that image and add your name to the authors list :D


p.s.
If smalltalk was to be ported to the jvm I would probably use smalltalk instead of jruby.