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)
Well, then I guess we better quit using it or else face huge gasoline deficits! I am sorry, but JAVA and SUV's are so totally different that the comparison is pointless. JAVA may be slightly slower than other languages, but it provides for rapid development and portability that are a developer's dream. JAVA is the developers' programming language.
stuff |
Let me also state that apparently, according to the article, JAVA is bad because i'd have to move a question mark in a query. Well... if you need a programming lesson, how about not hard-coding SQL strings? If I decompile your great JAVA/.NET /ActiveX component that I downloaded, can I get at all your hard-coded passwords, query strings, etc? If so, I don't think you can blame JAVA.
stuff |
Jeez, the server is slow already with only one comment. You'd think Harvard could afford a little better given the current tuition.
At any rate, from the article: "People who are serious about getting the job done on time and under budget will use tools such as Visual Basic (controlled all the machines that decoded the human genome)."
This is all fine and good, but the machines that "decoded" the human genome were performing a simple task really and did not require much in the way of alternative paths or any complex programming. For simple tasks or projects, yes VB is pretty handy. For other tasks, or requirements that may need a bit more complex programming, VB will not cut it.
Visit Jonesblog and say hello.
This guys is a troll. With all my respect, he doesn't bring any actual arguments with the exception of how difficult binding variables is. Should I also add that he's looking only in a matter of web based project's depending on a SQL-type DB????
Oh and last:
take twice as long, and be harder to maintain than a project done in a scripting language such as PHP or Perl..
Java has never been intended to substitute scripting languages. Of course a project done with PHP and/or Perl will go much faster!!! Both are able to execute almost eveyrthing you throw at them, but you may say exactly the same thing about C++ and PHP/Perl and it will be evenly unfair.
PS: And this said from a C++ zealot;oP
1. No sig. 2. ???? 3. Profit!!!
Bad programmers write bad programs regardless of the language.
If you'd said "I work for a web development house that used to produce everyting using J2EE, then we discovered PHP..." I'd be more interested in what you had to say about the merits of PHP over Java. Let me guess - you also can't undertand why anyone would use Oracle when MySQL is so easy and fast, yes?
It's all about horses for courses.
There is an "overhead" in Java, because it's not designed for quick-n-dirty deployment of something trivial. Getting the whole J2EE thing together to deliver a mail form is obviously going to take you 5 times longer in Java than it will in, say, perl or PHP.
But that's obvious, isn't it?
"And the meaning of words; when they cease to function; when will it start worrying you?"
If gas is CPU power. HP is RAM, etc. It's a pretty accurate discription. Java is an all-terrain vehicle of code (runs on multiple OS's well) which has lotts of flexibility, IE, towinr, storage, passanger space, etc.
:)
It's not a volvo XC, or auidi quatro. It couldn't possibly hang through a world cross rally with the subaru's and the big "P" dogs.
I'd call it something like an 4-runner with a stick shift. When you need it, it's there. But... wait a minute. Sun doesn't think linx is worth the disk space anymore... Why am I pushing Java? Perl! It's got to be PERL!
Thank linus for this cup of coffee...
-=fshalor
You mean like Kaffe?
The Java class library, the language standard, and even the bytecode itself has been pretty well documented in many sources across the web. There's nothing preventing you from making your own version should you wish to - it's just that most people have decided that one of the existing implementations are "good enough" for their uses, just like many people decided that Windows 98 was "good enough."
I personally still don't buy this "Java is an SUV" argument. A programming language is a tool, and a bad programmer can write horrible code in any language or environment. I've said this before on ./, but knowing which tool to use and why you're using it is the most important thing to realize when you're programming.
Apparently he's lamenting MIT students' inability to program in Java, and blaming the technology rather than the users. He also doesn't seem to be writing about Java at all, but rather JSP pages with "pages of" Java embedded which is horrible form, but typical of students in my experience. Ok enough trolling.
Yeah, but "how long will it take" and how expensive will it be when they figure out that the lack of application-level persistence and database pooling absolutely shred their scalability, and they have to convert to JSP/Servlets/JDBC to get decent scalability? "OMIGOD I GOT IT TO WORK ON MY DESKTOP IN HALF THE TIME OF JAVA IT IS SOO MUCH BETTER I'M GOING FOR SOME ICE CREAM BYE"
It's 10 PM. Do you know if you're un-American?
including the author of the blog. Java is great for what it is supposed to be used for. Yes, managed improperly its a great scapegoat for developers who have no clue whats going on. Managed properly (I say managed as in development code, concept usage, and production) it can be a valuable tool. Its quick to develop larger scale applications in, it provides a fairly uniform method of creating documentation, a framework so that others can understand whats going on, and (once again) when used properly is sufficiently fast for most all applications. The problem that comes about is the same problem with all new technology aimed at the business market... its not designed for a /single/ user. Its designed for a business, and what makes the most sense for that market. If I want to do something, yes, I'm going to do it in a scripting language. If someone else wants me to work on a team, share code, resources, and not be tied to a proprietary platform / application base, then yes, I'm going to write something in java. Thats the difference that everyone is missing, its not for me and you, its for a company. Swing and Awt suck, but the world doesnt revolve around gui applets. Java is great for server side applications that require stability (bug tracking is easy... its either there and you fix it, or its sun/ibm's fault and you wait or work around it). I wouldnt compare it to an suv, but maybe more of a bus: Its not /really/ small, it doesnt go /really/ fast, but if you have a lot of people that all need to get to the same place, and they need to get there as quickly / cheaply as possible, then it does the trick.
I'd have to agree, having expensive coding experience in both java and php, and having had to maintain both a JSP based HR program/portal (with NO comments, took me nearly 2 years to comment the entire thing, some people should be put down for the survival of the species me thinks), and a php portal that really stretched php to the max (can anybody say multiple persistent processes that can communicate with each other written in php), I'd have to say that java is good for:
Server cross platform apps
Server cross platform apps
Server cross platform apps
Its slow as fuck (all that crap about JIT optimization looks good on paper, but its CRAP), bloatware, and just generally unfriendly to use. Java is one of those, looks good on paper, but fails in implementation. One nice thing to say about it is that it is a very clean programming language, very nice to code in (I'm forgetting about the explicit exception handeling of course).
PHP on the other hand knows its job, and it does it exceptionally well, and if you don't like it you can always extend it.
Nuf said, php for web stuff, java for server apps.
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?
From the blog
"A project done in Java will cost 5 times as much, take twice as long, and be harder to maintain than a project done in a scripting language such as PHP or Perl. People who are serious about getting the job done on time and under budget will use tools such as Visual Basic (controlled all the machines that decoded the human genome). "
He suggests that Visual Basic is better than Java. I will refrain from comment, the quote speaks for itself.
Java is absolutely horrid for web applications when compared to php/perl. I recently had to compose a website in jsp and thought I'd rather shoot myself...the JVM went down constantly (it was shared, what did we expect?), the code was bloated and we had serious heap issues.
Now, I use Java on my prime contract (large contract for the SEC) and it's a blessing...interoperable over both our platforms (Solaris/NT), works great with the CORBA base we have, we can patch stuff in easily and bounce our processes to reload individual components, etc.
Java was never meant to be used as a scripting language...it got adapted as such because of the Java zealots. It was designed to be a high level, cross platform, portable language. Any other application of it is as silly as putting Linux on your toaster...sure you could do it, but it's not the most efficient solution.
--trb
Plenty of legitimate criticisms can be formulated against Java, JSP and JDBC, but I think we can safely ignore what this guy has to say about it.
Always keep a sapphire in your mind
Java can be platform independent because it includes a very larg class library structure.
C also have a large library that is provided by the OS that you #include. C++ has the STL and some other libraries
I believe thats why java feel awkward to a lot of programmers not familiar with its class libraries who want to use c system calls or shell calls to get the job done. The java folks created this because cross platform compatability is hard without this.
However the argument that java is significantly slower than c is pretty much moot. For test and XML processing its almost right there, and significantly easier to write code. All the extra data structures and types allow coders to use more efficent structures easily, usually resulting in faster code. (Similar to the way Perl coders can write blindly fast code easily using the built in Hash functions)
I'm not saying Java is better than everything else, just use the right tool for the job your doing.
True, but Perl is hardly the Unix analogue to Visual Basic. Visual Basic is very easy to learn and use, so "VB Jedi" doesn't have much weight. VB exists to make complete applications rapidly. On the other hand, Perl's strength is in text processing.
A function to reverse the order of the words in a sentence is a single line of Perl, but could be a hundred lines of C or VB.
A program to display a form with two text boxes, and display the sum of the numbers in those two boxes, would take seconds to write in VB, but hours in Perl or C.
A program to perform a numerical simulation would take about the same time to write in all three, but the Perl script would run considerably slower than the C or VB program.
I do believe Borland Delphi has a considerable edge over Visual Basic. No runtime libraries, and the language (Object Pascal) is as featureful as C++. To remain topical, I don't think there's any reason to ever use Java, save programmer-masochism.
Choose your tools wisely.
"[A] high IQ is like a Jeep; you will still get stuck, just farther from help!" --Just d' FAQs, c.g.a
Of course, while your example is an exaggeration, there is some truth to it. Then again, in the (remote but nonzero) possibility that you did cut yourself:
/usr/human/hand/finger on line 29371"
ASP would randomly write some data into weird places, and put up a pretty page telling the world that it had a problem...
PHP would just return a plain, white page saying, "PHP: Warning: could not un-recut in
and Java would call 911 for you.
Right tool, right job. If you don't need complete production stability for a moderate webapp with a short lifetime, by all means use PHP. For a production control system, I'd pick Java.
-Richard
You're special forces then? That's great! I just love your olympics!
... But the more I read, the more I code, the more I continue to learn and experience in the sfotware development industry - The more I begin to begrudgingly admit that the man is right more times than not. And I hate being wrong, so it's not like I'm particularly pleased with this turn of events.
To the contrary, it seems that it was -I- who was wrong by way of arrogance and hubris. I'd developed dozens of web apps, I'd been on teams designing and developing enterprise, corporate and consumer apps - I thought he was just full of it. What'd he know?
But as I started working with junior developers more, planning and managing projects more, rewriting inherited projects years after designing their previous incarnations - I started to see an eerie parallel to what the man had said.
Even if you still think yourself the ultimate programmer, incapable of mistake or misstep, impervious to making a bad design the first time through a problem - there still comes a time in which you work with developers less talented than yourself, developers less experienced than yourself. Therein you will painfully learn the wisdom of what tools, truisms, and technologies actually -help- make successful projects, and which just hinder.
I still find him to be an arrogant, pompous, ass; but what wise-ass hacker isn't? It's our calling card.
// "Can't clowns and pirates just -try- to get along?"
No language is without flaws. In C, the golden boy among die-hard geeks, you spend as much time managing memory and pointers as you do creating application logic. C++ saves many of those problems while introducing new pseudo-OO constructs that have peculiar and arcane rules governing their use. C# opts to provide far too many keywords for nearly identical behaviors and then renames half of them to look "new". Perl is terribly powerful, but can become obfuscated and impossible to maintain if used most efficiently. VB glosses over so many basic programming principles that its users waste time and CPU cycles re-reinventing the wheel. I can't say I know what's wrong with many others because I haven't used them, but no language is perfect.
That said, Java has terrific benefits and some deadly flaws. JSPs, for one, are a mess. Embedding code for even such simple tasks as displaying dynamic fields is error-prone and difficult to maintain. Add to that the fact that so many JSP developers leave reams of business code in the JSPs themselves, and the hackish nature of JSP comes to light. This is not, however, a simple Java problem, and it plagues any similar templating languages. I have seen some ASP pages that were phenomenally large. Bad practice is bad practice, irregardless of where it occurs.
Java also suffers, as many know, from serious memory issues. In the rush to provide a single language platform for applications across all aspects of software engineering, Java tries to do too much in too many places. Java can be embedded inside phones for small Internet clients and video games, or loaded onto the largest servers for massive Java-based enterprise integration applications. It does both of those things exceedingly well, providing powerful abstractions at both micro and macro levels. The grey area in the middle is where most people stumble. Drawing the line between "enterprise" and "standard" code libraries is very difficult, and many "enterprise" features remain in the "standard" version of Java, adding to the bloat. What's worse, only within the last couple years has the question of memory consumption begun to be addressed in earnest by Sun engineers. There are many lights ahead, however, be it the improved base memory handling in Java 1.5, or the eventual integration of Apple's VM-sharing innovations into the Sun Java proper.
Java being staticly type has other problematic side-effects; namely, as data and systems outside an application change or as the application as a whole needs to grow and adapt to new requirements, single small changes in a few classes can explode into massive alterations throughout the system. Again, much of this can be mitigated with rigid adherence to preferred OO practices. If those practices are not enough, there are a number of freely-available APIs and libraries to allow for more dynamicity and looser coupling between tiers, almost certainly easing these upward transitions.
At the end of the day, any software development group wants the tool that gets the job done. No project I've ever been associated with chose Java because of market hype or buzzword psychosis. They chose Java because it presented the most complete set of enterprise service abstractions in a single platform, without needing vast amounts of glue code to aggregate them into a single, homogeneous enterprise application. I have also never been on a Java project that failed, although many stumbled along the way. Java is not market-successful simply because it is hyped, or because it is trendy, or because I say so. It is successful because it provides developers more tools in a single toolbox than other comparable languages.
You can use JSP just like a template engine as well, if you want. Sun calls this JSP "model 2", i.e. use servlets for control, and only use JSP for the "view" just like any other template engine.
It has one advantage (I tried freemarker etc too), which purists might find a disadvantage: sometimes you can "sin" and use a tiny little bit of Java code on your JSP. Also most template engines have some built in logic for if/else or some even have some simple loop structures. Why learn yet another language (even if simple) when you can also use Java. Just restrict yourself and confine your JSP-java to the simplest possible use. It works well and is a practicle solution, while still giving a clean MVC structrure (which template engines try to force on you).
I think we gave different interpretations to 'hardcoding SQL statements'. I don't have any objection to keeping the SQL separated out and making it easy to switch from one dialect to another - although usually it is better just to code to the ANSI SQL standard, with some allowance for common deviations like Oracle's ''-as-null. What I have a problem with is deciding that any form of SQL is evil, and treating the database like a glorified (and rather slow) one-row-at-a-time object store, in order to avoid 'hardcoding' such heinously non-portable constructs as 'select name where age > 50'. And yes, this is based on experience.
One point - the 'nonportable SQL verbs' you mention can in some cases be the only way to tweak the best performance out of an RDBMS. Using a nonstandard extension to SQL is not a decision to be taken lightly, but it's good to at least have the option.
-- Ed Avis ed@membled.com
A prototype is something quick and dirty that just has to look right. Unfortunately, many people mistake it for the real thing. They claim to have written the program when they barely have a prototype.
Sure, it sorta works now, but it's piss-poorly documented and a nightmare to maintain. It's also already bursting at the seams, so when (not if) the requirements grow any larger, it'll be a flipping disaster. As the monster grows, it quickly becomes far more expensive to change anything in that spaghetti code mixture of logic, presentation and hard-coded values, than it would be to throw it all out the window and start again.
I've had the mis-fortune of having to maintain a project which had been thrown together by unskilled monkeys in PHP. Guess what? It was a fscking disaster.
One problem was precisely PHP's weak typing. Sure, it's neat if all you've ever made are small simple sites, but past a point it becomes a liability.
After having went through several maintenance and change cycles, obviously the programmers of that application had obviously lost track of when something is supposed to be a string and when it's supposed to be a value. The fact that in PHP if (x == 0) is true when x is "", or for that matter when X equals "OTHER", didn't help either.
In a strongly typed language, this just means gracefully getting a compile error, which is solved in 1 minute. In PHP it was just that the program sometimes mysteriously malfunctioned, even though most of the time it worked right. What would have been a few minutes of debugging in Java, was several days of debugging in PHP, on top of the cost of corrupted production data.
And that was only one of the many problems that that large application had. (A second one was the exact same mistake in reverse: if (x == "") is true when x = 0.)
Basically every single attempt they had made at reusing code was littered with this kind of mistakes. It was like it was the poster program for Murphy's Law: If it was possible to pass the wrong data type in a parameter, somewhere they had actually done so. And that weak typing just let them shoot themselves in the foot without any warning.
So you know what? I'm sick and tired of these blogging monkeys, making judgements they're simply not qualified to make. Just because any unskilled burger-flipper could quickly throw together a 3 page site in PHP, doesn't mean they have _any_ clue how to make a complex enterprise system, that can also be maintained and extended later.
A polar bear is a cartesian bear after a coordinate transform.
Absolutely, Give me PERL/CGI over WebSphere anyday. In fact, compiling code for an interpreter is laughable. Java should be a scripting language. Compiling millions of lines of Java is such a joke it is no longer realistic with Makefiles. You have to use ANT which doesn't support any other platform. The benefits of a scripting langauge far outweigh the benefits of byte code in my opinion. My experience with the WebSphere is that the web application claims over CGI are exaggerated especially with regards to performance. Furhtermore, the expenses of porting from WebSphere 2.0, 3.0 to 4.0 are far greater than any other C porting expense I've had to date. Java may be write once, run anywhere, but Java/XML/JSP/XSL/XSLT code written for application servers is not. The switch to EAR, WAR and J2EE was expensive with no discernable payoff. Web application servers are a waste of time because the standards change so fast.
However, 1/2 million lines of C/CGI scripts written 7 years ago compile on Solaris, AIX, and Linux with only one person spending two-weeks porting code that is still run in production today. Because ANSI C is a mature standard it is far closer to "write once, run anywhere" than Java is if the authors of the C code know it needs to run on multiple platforms and stay within the ANSI C/ POSIX universe.
> Those things sound like stuff you'd write for
> those useless reports the bosses always want
> comparing apples to porcupines. Most database apps
> I've seen use pretty simple queries;
> it keeps your memory overhead down, and makes your
> app run more smoothly.
A few thoughts:
1. If you think reports are useless, then you probably put tape over the guages on the dashboard of your car as well. I can't help you there.
2. And you deliver customer portal, don't you want to show info about sales they've made in the past, credits they've accumulated, savings they've made via your 'preferred customer program', etc? if not, then you're behind the curve on portal design. if you do - are you going to send them a separate application? Or are you going to run some of these queries from your portal. Hint: pick the last option.
3. Most database apps only do simple queries. You're right. That's because the average developer wants to keep the job simple, can only write basic SQL, and doesn't have experience with usability.
4. Yep, it can take more memory. Then again, memory's cheap.
> If you're using multiple outer joins for
> anything other than reports, your schema's
> probably screwy.
5. The schema shouldn't be limited by your inability to code multiple outer joins or deal with optional data.
6. See #2 above. The concept of a 'report' being something that somehow is done in other applications is antiquated. Transactional apps have a choice: deliver only transactional views of the data - and force the user to guess what the heck's going on or go to another app, or encompass some basic reporting in the transactional app.
> All that stuffs fine if you're working for the
> government, and they can buy you a billion
> dollars worth of hardware,
> but if you're putting together an app for
> accounting and inventory control for a
> relatively small company, and you're
> using those types of queries, you're going to
> make their hardware scream for mercy, and them
> very unhappy with the speed of your fancy new
> app.
Don't know where to start, but here's a try:
1. Use a real database
2. Tune it right
3. Put it on reasonable hardware
4. Identify the performance needs (based on usability objectives) for each step in each use case. Some queries will have to be lightning-fast, others won't. Learn the difference.
5. Redundancy in the database is your friend, just got to manage it right. It will allow you to take queries you would have thought would be very slow, and run them at blazing speeds. This is also best-practice.
I do this all the time and it always results in fast applications that users *love*. There's no need to limit your use of the database to trivial queries unless you're just prototyping, aren't being paid enough to finish the work, or are using ISAM files.
First of all, your "easy to learn" comparison is asymmetric: you didn't include the term "well" in the Perl version. Secondly, I, personally, think that Java is easier to learn than Perl. I also don't think I'm the only one who thinks so.
Though I'm not sure what you mean by "small programs", but the "Great Computer Language Shootout" suggests a high amount of variation between languages (language implementations, actually) for very small programs.