Slashdot Mirror
Phillip Greenspun: Java == SUV
lateralus writes "In his blog, Philip Greenspun re tells of his epiphany that Java is the SUV of programming languages. An interesting point brought forth in his typical extreme style."
← Back to Stories (view on slashdot.org)
A voice of reason. It is refreshing to see a diffrent viewpoint in this time of Java craze. In my own experience (and I work for a web development house) you can cut down time of development by factor 5-10 using a weakly typed scripting language such as PHP.
Paul Graham (of Bayesian filtering and Lisp fame) wrote an excellent article called Java's Cover.
It is about why he thinks Java is bad technology -- despite never having used the language. Very interesting read.
Thomas
...must be the Humvee.
True story: I was working for a startup in 1992 that needed to get a product to market in record time with minimal resources. The product was not a piece of software, but a simple Windows utility was needed to control it.
The utility was not very large and manipulated only very small amounts of data, but it needed to be easy to use, reliable, and look and feel like a good "commercial-quality" Windows application. The total number of hoped-for installations was to be in the low two digits.
I chose VB as the development system, which at that time was almost brand-new, to implement the software. I got it done in time--about nine months. It was a beautiful candidate for rapid application development. During the development, we added many features and change the UI many times in response to user testing and management requests.
It worked well. I am not aware of any problems with it, with respect to performance or UI, other than a rather slow startup time (about 30 seconds on the hardware of the day--which was an 80386SX running at, IIRC, 33 MHz).
I left the company, the company was bought by a new set of VC's, they hired a new software developer (who was absolutely first-rate).
The VC's insisted that the software be rewritten in C++.
There's no real punchline, because after two years of work the new developer succeeded in converting the program, and adding some new features (relating to minor changes in hardware capabilities). Neither I, nor the programmer, nor anyone at the company was aware of any real gains from the recoding, other than the ego satisfaction of knowing that they were using a "professional" programming language.
In my next few job searches, the hiring manager looking at the part of the resume where I described this work experience skipped over the "successfully completed on time" part and focussed on the "Visual Basic" part. It seemed as if the appearance of VB on a resume practically erased all my experience with other languages.
Of course, PERL and friends, being associated with the academic and UNIX communities, don't have quite the same aroma to them.
Nevertheless, I was very struck with the amount of damage to one's career that one can do by doing topnotch work, but using the "wrong" programming language in which to do it.
I think you miss the point. Before you go back and re-read the article put aside your obvious bias. The problem he was mentioning was that Java is not the right language for every situation. He was stating that you need to understand what you need to perform the job and use the right system. In cases of web-side solutions he is saying perhaps Java is over-kill.
I've written software in C that has been ported with little effort from one hardware platform to another with less effort than I have seen of many Java applications. I might suggest C is the language of choice for programmers.
OK, I guess I need a programming lesson then. For a database driven application, how do you propose not to have hardcoded SQL statements? Have the SQL statements looked up in the database or something? And how would you do that without hardcoding statements?
I am genuinely interested by the way...
I would use an automatic SQL statement generator. Why? Because: :)
1) It would prevent people from decompiling my code and just "seeing" exactly how the database is set up. Yes, you could still figure it out, but it would be less obvious.
2) More importantly, as things change, the queries could easily change with the system without having to go through and change every single instance in hard-coded strings.
There are easy and hard ways to make an automatic SQL generator: the easy way, as it most always does, would yield a larger, more obfuscated generator, while spending more time in design should yield a more optimized and quick generator. If you want source, hire me.
stuff |
Well, I worked at a project with no hardcoded SQL. It was a bitch. It happened because the client would NOT provide ODBC link to the DB. Therefore, we needed a middle server that got "request for X service with Y parameters", looked up in it's own service table what query that was, made it to the DB server, and returned the results in XML.
The biggest drawback is the fact that the queries are stored in varchar fields in a table. All the queries used by the system (a nationwide chain of gas station managers). So, when you where inserting or modifying a service, you where doing things like "insert into services values ... 'select blah from blah where blah=''... " and you had to start escaping characters like mad. And a missescaped quote would leave LIVE SQL in the SQL command... I saw a case where somebody had a bad escaped ", so the "where" clause was included into the string... he wiped out ALL the functions :o
While I think Phil exagerrates the cost of a Java solution over a scripting based solution, he does hit the nail on the head with Java's dearth of support for named bind-variables and flexible SQL support.
This is more cultural than technological. SQLJ has been available for years and handles bind variables in the same way that C does. But nobody uses it.
There's a tremendous distaste for SQL databases in the Java community. A major component of the Java community seems to have evolved out of the OO purist / Smalltalk view of things that view relational databases as an abomination to be avoided, or at least wrapped and hidden with an object-relational mapping layer. This is due to many varied reasons: dealing with objects alone is very empowering, and becoming an expert at SQL and relations is a discipline unto itself that many Java developers choose not to undertake.
If one DID actually try to learn the technology behind SQL and databases like Oracle, they'd discover a tremendously powerful engine for storing and retrieving data, that doesn't necessarily require elaborate model-view-controller architectures for good maintainability.
Simple web applications can be written with packages of stored procedures and a minimal data binding framework to JSP pages in a snap. In fact, this seems to be the approach ASP.NET and ADO.NET has been taking. Apple's WebObjects took this approach too, though with an object/relational mapper underneath (and "Fetch Specifications" instead of , or in support of, stored procedures).
Struts was the first real stab at a good data binding framework for JSP and is wonderful, but generally wasn't dynamic enough until the introduction of the DynaBean.
In summary, I think Java can definitely achieve the productivity levels of PHP and Perl, but the default recommendations from Sun are not the approaches that lead to these levels of productivity. I would suggest that the learning curve in Java might be higher to achieve this productivity, but it certainly is possible.
But I also think that the Java-based techniques do tend to favour a certain level of modularity that PHP and Perl and traditional VB/ASP based approaches do not favour out of the box, thus leading to a very unmaintainable approach. I think the Java community over compensated with "too much" modularity, but there are signs this is calming down.
-Stu