[OSM-dev] Re: osmeditor2 to Java, and a common Java OSM client library

[Ben Gimpert]

Hi Nick,

Tom's email has me wondering if this is moot, but hey.  Answers to your
questions are mostly speculative -- what isn't! -- but since I do have
industry experience developing enterprise applications in both Java *and
Ruby*, I'll give it a shot:

On Thu, 25 May 06 @04:36pm, Nick Hill wrote:
> Ben Gimpert wrote:
> >>This discussion has got me thinking about converting osmeditor2 to
> >>Java. I originally chose C++ as I had the following concerns about
> >>Java:
> 
> Hello Ben.
> 
> You are suggesting the client side be written in Ruby. I have no basic 
> problem with a client app written in Ruby.
> 
> I don't see the relative slowness of Ruby improving; Ruby's design does 
> not tend to make shortcuts for computational efficiency. I generalise 
> the lack of such shortcuts and the general ruby design philosophy as 
> being the reason why ruby is perhaps both the cleanest and slowest 
> language.

You're absolutely correct -- the *relative* performance of Ruby will
never improve.  But the same could be said about writing assembly and C.
C will always be relatively slower than assembly, because of the design
of the two languages. The important point is that *we don't care*!
Assembly is only rarely used because it is so difficult to read and
write, compared to higher level languages like C (2GL's).  And with
contemporary computers, the performance difference is not enough to
justify "assembly's" development hassle.

If there's one almost-absolute I try to stand by, it's to develop with
the platform providing:  a) the highest level of abstraction, and b) the
largest set of libraries.  (In that order.)  I'm just too busy to give a
shit about absolute performance.  (Note, I did not say "algorithm
performance.")

> However, the computational cost on the client side would be
> externalised to a large extent from the OSM project so for me isn't
> such a great issue.

Good point.  "Your machine has CPU to spare." Love, SETI.

> Would your suggestion to use Ruby require a complete re-write of the 
> client side?

Not really.  I'm suggesting Nick use Ruby only because *he's* talking
about doing a greenfield (clean slate) rewrite.  I do not suggest Imi
(for example) rewrite the lovely JOSM as ROSM.  Though I'd be happy if
he did... ;)

> Could we deploy a Ruby implementation conveniently as an applet in web 
> browsers with reasonable performance like we can for Java?

If we're going with the heavy client model, then the answer is "no."
Nothing compares to the convenience of Flash and Java applets.  If we're
talking about a thin client (AJAX-y), Ruby's perfect.

Anyone want to write a Ruby -> JVM bytecode compiler, so we can slap AWT
Ruby apps into web pages?  (Kidding...?)

> Could we make statically linked binary distributions of such a ruby 
> client side for various platforms (point and click to run), along with 
> adequate performance to work on moderate (say 500Mhz/256M) platforms 
> like we will be able to for free java?

Free Java's performance is a joke.  I genuinely wish this were not the
case -- because I love what the GNU CLASSPATH people are doing -- but
the native output of gcj doesn't hold a candle to Sun's JIT-ed JVM
bytecode.  (If you don't believe me, try a natively compiled Eclipse...
It's almost funny.)

This has a lot to do with gcj lacking the Java-specific optimizations
upon the *very* Java-specific machine language of the JVM bytecode.
Hopefully gcj will eventually tweak its output to JIT-level performance,
but for now I find your "...like we will be able to for free java?"
assumption shaky.

Oh, and why do we want statically linked binaries anyway?  Ruby's
interpreter works on the AST so it doesn't really get you more than code
obfuscation, which is stupid for Free software anyway.  Or maybe we want
the convenience of not requiring a hundred supporting downloads --
library JAR's or interpreters / VM's.  Well, just bundle the Free Ruby
installer including its big default API.  People are accustomed to huge
heavy client downloads.  Damn near every cool Ruby library (GUI toolkit)
is Free, so bundling those won't be hard either.

Including a Windows shortcut to launch a Ruby interpreter is easy --
"C:\ROSM\ruby C:\ROSM\rosm.rb".

> Do you have any (rough) estimates on the relative amount of
> programming work necessary to achieve these goals from the current
> point with Ruby versus Java?

Ha!  Now this is where I get (more) evangelist...  The productivity
increase of writing Ruby over Java is hugely significant.  Granted, I
can only rely upon anecdotal evidence -- but I do have a lot of it,
since again, we use Ruby at my day job.

I wouldn't think to bring him into this, but I know Steve has had the
"Ruby epiphany" when porting the server away from Java.  Proper 4GL's
offer an increase in developer productivity of the same relative level
as moving from C++ (or even C) to Java.

I don't quite know what you mean by "from the current point," but I'll
assume this means from Nick's impulse to rewrite his editor from
scratch.  If so, I definitely think chosing your language matters.  Let
me know if I should send out links to Paul Graham and Martin Fowler
articles on how the choice of language improves not only productivity --
but also the ease with which hard problems can be solved.

Here's a classic example:  Write a bit of code "foo" that takes a number
n and returns a structure that -- given an argument i -- returns n
incremented by i.  Just *try* to do that in less than 15,000 lines of
Java!

Oh, it's two lines in Ruby: "def foo (n)\n lambda {|i| n += i } end"

> These are all genuine questions.

There *are* language features at a higher level than Ruby provides,
which I hope to someday use prolificly, but the library support hasn't
kept up.  I'm more a "high level" zealot than a Ruby zealot.

I predict in the year 2015 the next hip language will provide aspects,
orthogonal persistence, a memory address space transparently shared
across a cluster of machines, automatic side effect -> functional
translation for transparent SMP'ing, signed web-of-trust based data
access, and the *beginning* of support for real trusted computing via
provably correct programs.  I can dream, can't I?

I really believe our lives would be better if people coded in better
languages.  We'd stop being paid to "solve" the same problems
over-and-over again, and we could concentrate on solving *new* problems.

		Whew,
		Ben