lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 23/06/2011 12.41, Francesco Abbate wrote:

2011/6/23 HyperHacker<hyperhacker@gmail.com>:

[snip]


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 - with some reason - Javascript (which has nothing to do with Java, 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 handling!
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 it"!!!!! 



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 :-)

Cheers!
-- Lorenzo
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! :-)