Complexity and starting over on the JVM (why interoperability?)

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Thu Feb 7 00:07:51 UTC 2008


Igor Stasenko wrote:
> Interesting, this subject showing up couple times before my eyes recently.
> What is so precious in being able to interact with java?

I think there are several issues, now that Java is finally "free" as in
freedom (or mostly there anyway).

* Leveraging libraries (typically in Java, but also for other JVM languages).
  "JVM Languages"
  http://www.robert-tolksdorf.de/vmlanguages.html
  "Searching projects gives 15591 results -- for Java"
http://sourceforge.net/search/?type_of_search=soft&type_of_search=soft&words=java

* Leveraging the JVM itself, which is continually improving (hotspot dynamic
code compilation, maybe eventually support for multiple cores). The Squeak
VM is simpler and so less likely to break than the JVM, but the JVM
undoubtedly  has much more testing, especially in mission-critical situations.

* Writing your own *cross-platform* fast code in a statically typed JVM
language (Java, Scala, others) which is close to the speed of C, but without
most of the #ifdef and memory management and multi-platform testing
headaches of C.

* Being able to leverage all those Java developers out there who learned
Java (often in school) so they can play a part in free software projects
which are much more dynamic and Squeak-ish -- so, say, they write the 3D
library,
  http://jcrpg.blogspot.com/2007/09/what-is-jcrpg.html
and you write the Squeak-ish application that uses it (perhaps the AI? Or
level-creator tools?).

* Being able to do paid consulting which has to be done on the JVM and
working with Java libraries, where you could possibly bring in Jython or
another JVM language (even a Smalltalk) through the front door in a small
innocent-looking JAR (arguing productivity, and that it's basically
Java/JVM-ish, and it is anyway just a small part of a whole easily replaced
in Java if ultimately necessary, etc.), when you could not possibly float
the entire Squeak Smalltalk balloon over a corporate IT fortress' walls
without that independent balloon being seen as a threat and shot down by
flaming arrows. :-)

There are probably more reasons I have not thought of. There are downsides
of course too, because the whole internal dispatching system gets more
complex compared to Squeak, debugging may get harder sometimes in mixed
systems, and you may hit brick walls sooner (instead of Squeak all the way
down you hit a JAR), etc.

The issue of easily supporting both commercial use and free use is probably
the biggest reason why I use Jython over Squeak. :-) A JVM language lets me
potentially live more easily in both worlds -- paid consulting and free
software. Squeak pretty much forces me to choose to develop on a free
software skillset. Even when I am not doing paid consulting, that issue
still is always in the background when I learn new tools. The two
possibilities build on each other in a synergistic way. As much as I believe
the future will entail mostly a gift economy based on abundance for all,
  http://www.whywork.org/rethinking/whywork/abolition.html
including StarTrek-like self-replicating 3D printers powered by dynamic
languages like Squeak interpreting free 3D designs, :-)
  http://www.reprap.org/
  http://fabathome.org/
  http://www.ennex.com/~fabbers/
that future seems still at least ten years off for most people (my family
included. :-)  Until then, earning ration units (dollars, euros, whatever)
for exchange is important, and JVM-based technologies seem more likely to do
that for most programmers than Squeak IMHO, as neat as Squeak is on its own
terms.

Until that Star Trek future of abundance for all arrives, we have to worry
about mundane things like getting decent software tools into the enterprise
and approved by often indifferent and conservative management. Here is how
it is claimed such managers usually think:
  "Revenge of the Nerds"
  http://www.paulgraham.com/icad.html
"As long as [your manager] considers all languages equivalent, all he has to
do is choose the one that seems to have the most momentum, and since that is
more a question of fashion than technology, even he can probably get the
right answer. But if languages vary, he suddenly has to solve two
simultaneous equations, trying to find an optimal balance between two things
he knows nothing about: the relative suitability of the twenty or so leading
languages for the problem he needs to solve, and the odds of finding
programmers, libraries, etc. for each. If that's what's on the other side of
the door, it is no surprise that the pointy-haired boss doesn't want to open
it."

Maybe Squeak is the best tool sometimes, but at least Smalltalk on the JVM,
like Jython, would be in the middle somewhere there between Squeak and Java,
and in the middle is where a lot of developer live -- a little flexibility
to make their own choices, a little understanding by the boss, a little free
time, and a few projects where no one will argue the language matters much
as long as it smells like Java. :-)

Java and the JVM are already in the enterprise. Add-ons to Java have an
easier time getting through the corporate wall, since corporations are used
to buying or making libraries (and that is all, say, Jython is, a Java
library, when you think about it). Few of us are lucky enough to be among
the few dozens (hundreds?) of people employed using the Squeak VM or working
at similar forward thinking organizations who to a high degree emphasize
productivity over conformity. But hundreds of thousands of people already
make their livings doing stuff on top of the JVM, and a lot of those Java
shops are finally hungry for something better than Java which they can
switch to incrementally, whether Scala or JRuby or Qj4J or Javascript or
Jython. This is true even if they forget that Smalltalkers told them ten
years ago that Java was an inferior language to Smalltalk, and that the JVM
(then) was slow and buggy, and the fact that Java would not be half of what
it is today if it were not built on Smalltalk-derived technologies (like
Swing and Hotspot compiling). The problem is that Squeak (or a derivative)
isn't on that short list of great JVM languages today, and even Dan's
Squeak-on-the-JVM probably won't be enough if it is not oriented around
interoperating (including supporting both funky Morphic GUIs and
straight-forward Swing ones). It may already be too late to get on that
list, but one can hope. :-)
  http://stuffthathappens.com/blog/2008/01/02/scala-will-do/

While Smalltalk on the JVM will likely never have the easy acceptance of,
say, Jython (since Jython looks a lot like Java, being C-like), a
Smalltalk/JVM would likely still find easier acceptance in enterprise
projects than a stand-alone Squeak system where Java is already one of two
major standards (the other being dotnet, which isn't "free" IMHO even if
mono exists, given the threat of software patents or "embrace-and-extend").

Also, to the the extent a Squeak/JVM leverages Java libraries like Swing or
statistics libraries or whatever else, that is all time when programmers are
learning other skills commercially valuable (learning to use those libraries
well) -- making it easier to explain and justify that time to others
(whether managers or spouses. :-)

Still, commercial issues aren't the only reasons for Smalltalk on the JVM. I
did list others at the start which are also important to me (libraries,
multi-processing VM with extensive QA etc., fast portable code, and more
potential collaborators on free software). But commercial reasons have
played a strong consideration in past choices of language for me (for good
or bad) and I suspect they also play a big role for many others.

--Paul Fernhout



More information about the Squeak-dev mailing list