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)
Google does
Didn't even attempt to find out who Greenspun is, huh? Check out his resume. He is a Ph.D. in Comp Sci and teaches Comp Sci courses in MIT. Do you happen to teach Comp Sci at MIT?
I've got to agree with this. Reading Greenspun's blog I was left pondering how to start responding to something so completely wrong.
The article implies a lack of understanding of the JSP paradigm. Sure, binding variables to a relational database is tough. So if you insist on doing that, use JSP tags. But that's not the point of Java -- you should be access instance methods from a JSP page, and those instances can access any data source they choose.
VB and ASP are intended for developing front-ends to primarily relational data, so they make it pretty easy to accomplish. The fact that they make it easy doesn't mean that you can use the same design and technique to deliver a scalable, maintainable web site. All the current theory says take the pain up front and put in a decent template system, and never put code in your page.
"People who are serious about getting the job done on time and under budget" will get the requirements first, and not making sweeping bullshit generalisations. There is a huge problem in the industry at the moment with IS departments trying to coalesce the functionality of dozens of specific-purpose VB applications into one enterprise system. The size of the project, requirement for scalability, expected lifetime and regularity of changes, systems integration issues, cost, stability, customer technology preference and other technical and non-technical issues will all influence the choice of a development environment.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
You will typically
I tend to agree with his problems with JDBC being quite cumbersome to use. This is why one will typically use data access Java beans which encapsulate data access. Also there are several object-relational mapping frameworks (e.g. CastorJDO) which will even isolate you from SQL and database details completely.
I would even tend to agree with him on terms of how quickly one can hack some web application. One will be faster with a scripting language like PHP, but when it comes to extending/maintaining a JSP type 2/3 application will win.
Portability? Oracle ships with three different JVMs because they are all incompatible with each other. That's all you need to know about Java portability.
-- Ed Avis ed@membled.com
The "problem", if there is one, with Tcl is that it is not fashionable. Instead, lots of people just use it to get their jobs done quickly without lots of chest thumping, willy waving, and enterprise enabling.
http://www.welton.it/davidw/
OK, it's just a joke, but I'm interested in countering one point that some people still believe.
It's cross-platform feature has been tainted by the agenda of the forces that dominate the respective operating system
I am currently employed on a project with roughly one megaLOC of Java. It has a Swing GUI, EJB middle tier, and Oracle at the back. It currently runs on Windows, several flavors of Linux, and Solaris, without recompile. I do the production builds on a Linux machine and we distribute them to roughly 2000 Windows and a few dozen Linux workstations. Likewise I do the production middle tier on Linux and deploy to Solaris, and the development and testing versions of the middle tier go to Windows, Linux, and Solaris.
Would it fit on a wristwatch? No, it's too big. Would it run on BeOS or Mac? You betcha.
Stop-Prism.org: Opt Out of Surveillance
AMD also uses GNU Common Lisp and ACL2 internally, though they can't reveal any specifics - this is of course the problem with a language that's suited well for the research and development part of the product phase. Who wants to give away what they're doing just to advertise that they're using Lisp?
Of course, if you wanted pretty pictures and "yet another database web interface", try the Stargreen site. But you won't find a lot of people using Lisp on those, for the simple reason that most of that work is cut and paste from a previous project.
OK, I guess I need a programming lesson then. For a database driven application, how do you propose not to have hardcoded SQL statements?
Well you could,
- Use Java Entity Beans with Container Managed Persistance.
- Use JDO
- Use TopLink
All of the O/R mapping tools automatically generate the SQL queries for you based on your Database Schema. No SQL necessary, hardcoded or otherwise.
I develop regularly in C/C++ (Unix and Windows), Java (J2EE), and PHP, and can't really agree with the author's contentions. J2EE is much superior to PHP for serious web applications -- the students mentioned in the article would have been much happier using WebLogic or jBoss instead of than Oracle.
Of the three, C/C++ is obviously not well suited for developing web-based applications.
PHP is quick and easy, but it suffers from a lack of vision -- it was never designed, and the authors don't really seem to know what they want to do or where they want to go with it (don't even get me started on how it's supposed to be "Object-oriented" now...). IMO, it's much easier to make a mistake in PHP, and code is much less maintainable than equivalent JSP pages -- just try switching from MySQL to Oracle, and you'll see what I mean. I shudder whenever I hear the words PHP and enterprise in the same sentence.
Agreed.
Well...no. C is used for system development (i.e. hardware banging). Java cannot be used in that environment without direct support of the libraries and the JVM (or by JNI calls to libraries written in C/C++).
Well...no. C can be used anywhere that Java can be. On the server side, most servers (including web and proxy servers) are written in C. There's nothing stopping people from writing "app servers" in C...in fact there may even be a few of those too.
On the client side, "applets" are not a valid use of Java. Applets was a marketing ploy that grew wildly out of hand. Besides, there are ActiveX controls written in C/C++ that perform the same basic functionality of applets.
One thing that Java has over C/C++ is its cross-platform capabilities. With C, if you want cross-platform you have to work to code it that way. With Java, if you want to break cross-platform, you have to work to code it that way (use non-standard libs, use JNI, etc...)
Yes and no. Perl is slower to start up than a C/C++ native application of similar functionality. Java too is very slow to start up (usually *much* slower than Perl for very small scripts).
However, long running apps written in Perl and Java both perform very well when compared to similar C/C++. By long-running, I mean "long enough that the startup time becomes a wash". I've written web crawlers in Perl and Java that run for weeks at a time. Comparing their performance to existing crawlers written in C/C++, the performances are equivalent (though the Java and Perl bots suck up more memory).
Development time for those bots was significantly less in Java and Perl than for equivalent C-based bots. (BTW: the Perl bots were written back before LWP was stable/available)
Well...no. VB is stuck on one platform (well, two if you consider MS-Java...though VB.NET is NOT VB).
Yes it is true that you can easily decompile .class files to get back almost the exact source code (without comments). However it is also true that there are code obfuscators that do a really good job of making it damn near impossible for someone to figure out how the code works. Imagine if you overloaded your methods and classes as much as possible such that 70% of your class names were 'A'. i.e.
setName(String) becomes a(String)
setAge(int) becomes a(int)
getName() becomes a() and
getAge() becomes b()
It makes it darn tough to figure out what the code does. And you don't have to write the code in this obfuscated manner, you write it using good code practices and the run the obfuscator on the compiled .class files. The output of that obfuscator is a set of obfuscated code and a mapping file so if you get debug messages like:
NullPointerException in A.c(int) line 147
then your mapping file will tell you that "A" was actually your class name "Client" and c(int) is actually "stZipCode(int)". Now you can still debug a customer's error without giving away anything about the code structure to the customer.
However, the place where Java has been excelling (and where I've made my living for the past 5 of my 15 years in software) is in major web applications where the user doesn't have any access to your compiled code. The combination of Java servlets, talking to Enterprise Java Beans or to a database via JDBC and then outputing the html using Java Server Pages is now pretty much the default way of writing a huge data-centric web site. Pretty much all major banks do their on-line banking web sites this way (this is my area of expertise). This is the technology behind Amazon.com and (I believe) Barnes & Nobel.com as well. If you use Quicken or MS Money to do your bill payments and check your financial statements you're either connecting to CheckFree (Java Based) or to an EEI server (Java based) to transfer all that financial info.
So is Java fat, bloated and wastefull? Well, how fast is your on-line banking? How fast is Amazon? How fast does your Quicken software work? You'll wait far more because of lag in your web connection than with any kind of slowness with Java.
So what we have here is some academic geek with a web site on the Harvard Law server telling those of us who actually pay our mortgages writing Java software that we don't know what we're doing. Well, that's fine. When I'm done paying off my house 15 years early (as well as all my car, student loan and credit card payments) and I'm retired debt free at age 50 I'll try not to be too upset that Phil Greenspan's angry little blog said I did it by using the wrong tool.