[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT without the JIT?
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Thu, 23 Jun 2011 17:29:51 +0200
On 23/06/2011 12.41, Francesco Abbate wrote:
Another approach in the mid between them is the Java approach that
have both a static strong type system and a VM with JIT code
generation. In my point of view this is the *wrong* solution because
it takes the worst of each world. The typing system and the rigid
class based system with explicit exceptions declaration make the code
very verbose and cumbersome to write taking away a lot of the
programmer's time. From the other side you don't even have a static
optimization but only a JIT code generation that, while effective,
does eat a lot of resources in term of memory and execution time.
The only reason why it was and it is so successful is that managers
likes it because you can have a lot of contracts explicitly declared
to use modular programming techniques an it is really *safe* in the
sense that it cannot crash at any moment just because you forgot to
check a null pointer or something like that
I was a Java programmer, some years ago, and indeed *it is* verbose, but
in a very linear way (sometimes too much!).
If you educate yourself accurately and study the language definition,
you'll see that many of its features are aimed at avoiding shooting
yourself in the foot!
You must be really a sloppy programmer (or a terribly lazy one) to write
non-working code in Java. Of course, the prerequisite is the word
"study": conventions, compiler, APIs, SDK tools, etc, etc., etc.
They are not terribly difficult stuff, but there are *TONS* of them (if
you don't know what I'm talking about, try to unpack the Sun SDK docs
zipball and you'll see!!! - I last programmed in Java some ~7 years ago
and I used Java 6.0 - If the trend is the same, now you could probably
spend 10 years of your life just reading all that stuff and doing
nothing else, but breathing!!!! ;-)
I used dozens of packages and libraries written by other people and the
integration with the systems I worked on were smooth most of the times.
Even the most awful feature (generics) is carefully designed. BTW I say
"awful" because Java programmers waited for 4~5 years (or more? don't
remember) for generics to be introduced into the language, since they
were expecting something like C++ templates (but with Java ease of use)
and the possibility to do duck typing and improve code reuse.
IMO the result it was almost a monstruosity: an extremely complicated
way to overspecify types statically just to avoid some runtime casting.
No duck-typing at all. And the language specification (2nd edition -
which was hard stuff anyway, but somewhat linear and clear) became a
nightmare (3rd ed.) in every part that touched generics!!!
But still, it was (and I suppose it remains), a very robust platform,
especially for web development (even for things different from fancy
webpages. I mean, secure services for home banking, just to name one).
It was *not* just marketing hype. Remember that when Java was hyped -
besides having a similar C-like syntax) "stole" its name to ride the
wave of its popularity!
Moreover, mastering a good IDE as eclipse skyrockets the productivity of
any programmer. I had a colleague researcher of mine (not primarily a
programmer, but with several years of Java programming experience) who
did not want to switch from her emacs+manual compilation workflow. Java
was a pain for any small refactoring cycle (she was waaaaay less lazy
than myself and I didn't succeed in convincing her in doing the switch! :-)
So yes, Java is not good either for RAD nor for people needing an
elegant language. It needs dedication to learning the tools. It is
terrible when it comes to sheer performance (compared to other
solutions). And it is not friendly with foreign languages (I tried many
times to learn Java Native Interface, the Java's way to interact with C,
and always gave up in despair - I always found a better, although
slower, alternative in pure Java.
I don't like it too much, but it is not crap, as you seem to hint.
Java is ugly as a first time language because for the classic Hello
World example it requires lots of boilerplate. The learning curve is not
steep at all, but it requires lots of time to understand the usefulness
of all that verbosity.
And you really understand it when you see that a single programmer can
produce a fully tested 30kLOC package with tens of classes, organized in
different abstraction layers, which can run with no errors for weeks as
part of a complex web app running on a server.
If you just write small applications, or your need is sheer speed, or
superoptimized code for numerical stuff, Java is either overkill,
bloated or sluggish. But if reliability, robustness, i18n support and
web support is paramount for you, then Java is really good.
Yes, it is frustrating to write thousands of times the same boilerplate
for, say, an anonymous inner class, especially if you know Lua can do
better with closures and upvalues. But most of those problems are solved
with a good IDE.
(just a small parenthesis
about this latter point, this advantage is often overestimated because
if it true that Java cannot crash it is true that you can have
unhandled exceptions or exceptions that are inappropriately handled
resulting in non-functional behaviours).
The advantage is not primarily that Java doesn't crash with a segfault,
but that it has a linear and pervasive exception mechanism which is
enforced at various levels. I don't think it is overestimated. Error
handling and management *IS HARD*. The time and resources you want to
spend on this task depends on what kind of safety requirements your
system has. If you are writing a graphical app then a simple message box
notifying the user that, say, the system is low on memory, may be
enough. If you want a system to be fault-tolerant or even
fault-resistant, well, Java is your friend (I heard that Ada is better
in this respect, since it is used for avionics and military stuff, but I
don't have the expertise to comment on that).
As for people not handling an exception: a bug is a bug. It is not
Java's fault that a programmer introduced a bug in error management.
If you catch an exception and then fail to handle it, then it is your
fault. Java doesn't make intrinsically more difficult to handle errors
than other widely known languages.
And if a programmer is not expert enough to design his error management
strategy in advance, well the guilty is him or the boss that has put him
to work on something he was not able to handle. No free beer in error
Sloppy programmers will always exist. Once a colleague of mine,
debugging and adapting to our needs some ASP pages "borrowed" from
another department of the research institution were we worked, showed me
an .asp file whose first line (IIRC) read:
On error goto 0
That line meant (as she explained to me, since I didn't know anything
about ASP): "if you detect an error everywhere in the page, just ignore
So Java is both boring to write with a lot of boiler-plate
declarations and so on and the execution environment is largely
suboptimal with a lot of resources required, the omnipresent GC.
Yes, I agree, it is boring and boilerplate litter the code, and it is
not very readable (on the other hand it is fairly linear, it is
difficult not to get the meaning of a snippet if the programmer was
careful in commenting the code and choosing the identifier according to
the best practices). As for resources: it is somewhat avid, but this is
the price for the safety net you play on.
I hope my email was not boring even if it is certainly OT, I've taken
the opportunity of this thread to share some reflections about
optimized code generation and programming languages.
Nope. Food for thought :-)
P.S.: as I said above, I haven't touched a line of Java for almost 6
year, so don't flame me if I said something really wrong about what's
Java is today. I described the situation I knew at that time.
Of course a current Java programmer is welcome to correct me! :-)