Bill de hÓra writes...
Both JRuby and Jython have experienced stop start development.And then goes into several interesting directions. (BTW, the original Erlang book is good, but not essential for adopting Erlang. Instead start with Erlang in Real Time which is online and more in-depth. Everything else you need is on the erlang site, including the mail lists.)
Anyway my thought is that running multiple languages on the JVM or CLR is beneficial simply because there are no *really* good inter-language communication mechanisms. Being in the same OS process is useful but certainly there are times when that is undesirable for security and reliability reasons.
Given the oncoming multi-core low end systems, the oncoming many-core high end systems, and the realization that "SOA" in its best possible interpretation is just "reality" for tomorrow's programmers (cf. "Notes on Postmodern Programming") we need to get over this "use my OS/VM/language" / "no, use *my* OS/VM/language" parade asap.
Erlang may never be popular regardless of the books available or not. (Then again with ejabberd, Erlang *may*... er, forget it. Jabber will more likely be the inter-language communication mechanism I claim we're missing.) But just as Lisp got data right, and Smalltalk got objects right, Erlang got processes right.
Sooner or later your language and runtime will too. And the sooner the better because I cannot count on anyone porting my language to your runtime, and I sure don't have any incentive to do so myself.
Meanwhile rather than try to program all of the latest Ruby or Python in the JVM or in the CLR, I am wondering whether we need to expose Java and C# libraries via their own processes connected to a simple communication mechanism with a simple, reflection-based interpreter on the receiving end.
Hey, JVM, just sit there and do what I tell you. I don't need that to be more than the current implementation of Jython or (the upcoming 1.0 release of) IronPython. Or take your pick, maybe Javascript is the lingua franca via Rhino and... er, dotnet does have a Javascript interpreter, right?
If I ship my application to you as a, say, a VMWare player and image running the OS of my choice, pared down to what my application needs, plus a few OS processes running on that image, each implemented in the language of choice for that process, plus some inter-communication between them, and all of them going out to the real world as desired, then... would I be happy with that kind of Gordian Knot post-modernism?
5 comments:
There's jpype for the JVM (embedding a Java VM in Python), or Python for .NET (I guess embedding CPython in the CLR?) -- are they what you describe? Or RAA (CPython embedded in Ruby)... or many other similar projects.
For whatever reason those projects don't seem that popular, but I'm not sure if it's actually because of any real reason, or just because of some irrational desire for intimate runtime mingling. Well, perhaps a rational desire for intimate runtime mingling.
In a way, there's a 2*N**2 problem of connecting N languages to each other directionally. Maybe some super-thin uber-container... but is that the CLR? Probably not, but maybe it would be.
There's jpype for the JVM..
Nice. I did not know about that. The Python.Net assemblies for dotnet and CPython seemed like a lot more than what I was looking for, but I guess not really. Not that I know what I am looking for precisely other than an easy way to use data and programs across OS processes and languages rather than requiring the JVM and CLR to have faithful implementations of every good language on the planet.
...some irrational desire for intimate runtime mingling...
Yes, that is the desire I am trying to get away from.
In a way, there's a 2*N**2 problem of connecting N languages to each other directionally. Maybe some super-thin uber-container... but is that the CLR? Probably not, but maybe it would be.
Yes, again. I am thinking there is some acceptable canonical language as the glue. I think Python would be fine, or something even smaller. (Yes, Python is pretty small.) In any case, the goal is not to program much in this super-thin uber-container's "language" other than enough glue to get to the libraries of code stashed away in their respective runtimes.
I played for a while with just such a "canonical language", namely Parrot. I came away with the conclusion that there were just too many non-obvious differences to sweep under the rug.
Example: is 0 true or false (hint: check out Ruby)? What should String.find return if there is no needle in the haystack?
I still remember the furor that erupted when Microsoft deemed that arrays start at index zero in VB.Net.
Of course, we have the same problem with wire protocols.
"canonical language"
Yes... I think one will just have to choose something they can grok that's available on the platform they wish to use.
I think the key for me is that I don't have to get worked up that CPython is ahead of Jython, and JRuby is well... it has more problems. So even though I am working with Ruby right now, and I want to use some Java stuff, I just recently looked at JRuby and decided to get into the JVM via Jython.
Post-modern.
Oh, and I was shocked that Watir gets a lot of buzz but that it is for IE on Windows only. So better to use PyFIT, because RubyFIT appears to be stagnant as well. Or try Selenium, but I want to do more than Web testing so why bother with just a web tester anyway.
Post-modern.
I don't think there is a O(N**2) problem. What's needed is something like ODBC-- a thin "driver manager" library, accompanied by an SPI that needs to be implemented by each VM. That reduces the effort to O(N).
There's no need to take a position on whether 0 is true and other such issues.
Look, this doesn't have to be so hard. Get functions, strings, and integers working and the rest will come. Just stand firm and refuse to solve the problems that turn it into a rat's nest (like distributed GC across multiple VMs).
I am strongly in favor of you and Ian solving this problem within the next few weeks. It would be valuable, and with the right approach, not too difficult.
Post a Comment