Wednesday, 22 August 2007

Scala's interoperability with Java is indeed a good thing.

OK. I have never written anything in Scala so this is rather general feeling, but the topic is general as well. Just today a, well... strange post got reditted. Someone by nick Pinderkent claims it's not good for Scala interoperate with java. I totally don't get his point. In much simplified version, it goes: java libraries don't have suitable functional interface, therefore, screw java.

So, how could one actually "look past Scala's java roots"?

Let's imagine Scala out of JVM. I'm not an expert on this, but I suspect, there's nothing that prevents us from compiling it into native assembly (well, except for lack of compiler:>). Such a Scala would do pretty much what C++ does now, but on slightly higher level and with bigger assemblies produced (garbage collection). It sounds nice, but the absolute lack of any low-level libraries makes it not worth the shot.

Creating new virtual machine is also not worth the effort, since from what we've seen over last years: it is a huge marketing task. Besides, it is better to have less VMs than more.

If you want to keep Scala running on JVM and just sweep the interoperability out. All what you get is a good language without any libs. That's a big no-no.
It's more than ten years now since industry began switching to virtual machines. One of advantages of that switch is the possibility of having not only different libraries but also different programming languages speak using common interface. For emerging languages, this is a huge opportunity. Let's not reject that! The argument for not using java libraries directly is perfectly fine: their interface sucks for Scheme developer, but the argument against writing wrappers around them appears to be a feeling rather, not a thought-through statement: "use of such adaptor code often leads to messy software". Eeee, no? It doesn't? Take a look at swing. It's a widget toolkit that was first implemented in java as a wrapper around awt (the older and miserable-looking GUI lib). With time it came into java's standard library and in jvm version 1.6 was completely rewritten in order to make it more effiicient. Isn't it the best way of implementing libraires for Scala?

Besides that, java interoperability is one of Scala's killer apps, and one of its defining features ("bringing functional programming to the java world"). What's the point of losing that?

1 comment:

Fuzzyman said...

'losing that', not 'loosing that'. :-)

Whilst I agree that it is unusual for languages to migrate from targetting a specific VM *to* a stand-alone language (at least as far as I know), the two 'dynamic-languages-of-the-moment' (Python and Ruby) both have reference implementations that operate without the assistance of a separate VM.

Both are actually reasonably long in the tooth as languages though, having started in the early nineties and had time to develop libraries of their own.

How does a language that starts life on the JVM (or the CLR) break out to become anything more than a 'Java scripting language'? I guess you could get to the point where *only* working on the JVM holds a language back? I'm not sure that what the world needs right now is *more* programming languages though. (Or more VMs as you point out.)

Oh - I posted your last example to the IronPython cookbook. I hope you don't mind. :-)