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."

Comments

Agreed!

[toupsie]

It pollutes the environment and wastes gas...

Re:Agreed!

[parseexception]

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.
not only that if you have to change direction quickly it will roll over and burst into flames

Re:Agreed!

[fshalor]

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...

Re:Agreed!

[Anonymous Coward]

Java is an all-terrain vehicle of code (runs on multiple OS's well) which has lotts of flexibility

Yes, but there's a key difference between Java and an SUV:

When people use Java, it's usually because they NEED (or want) to run on multiple OS's or need/want that flexibility.

With SUV's, on the other hand, how many people who buy SUV's actually go offroad with them? Hardly any. They buy all that offroad power, and then drive on the damn road. Most of the SUVs you see in the parking lots are immaculately clean.

JAVA is the suv?

[192939495969798999]

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.

Re:JAVA is the suv?

[Anonymous Coward]

You mean, "JAVA is the language of the people who like to call themselves developers."

Re:JAVA is the suv?

[Anonymous Coward]

JAVA is the developers' programming language.

With all respect, that's crap. Java is the _managers'_ programming language of choice. It enforces a particular style of programming (right down to naming convontions), it takes a specific programming 'paradigm' (OO) to an unnecessary extreme and it's chock full of trendy buzzwords and BiCapitalised MumboJumbo. Perfect for PHBs.

JAVA may be slightly slower than other languages,

Says the Iraqi Information Minister.The fact is that, thanks to it's use of garbage collection and because it stores non-primitives on the heap, Java will always be _significantly_ slower than C/C++, no matter whose JIT you are using.

This article explains it well.

Re:JAVA is the suv?

[aborchers]

it provides for rapid development and portability that are a developer's dream

That must explain why we've spent the last week wasting our time with a newly delivered peice of code that refuses to run.

No, the incompetence of your developer explains that. Just because you can write it in Java doesn't guarantee its portability. Java gives you abstractions that can be used to guarantee portability, but it is a complete language and therefore also gives you, to nick the famous axiom about C, enough rope to shoot yourself in the foot.

Whoever wrote the stinking pile of crap wasn't what I'd call "a developer", either. I'd call them something, but certainly not a "developer"

Ah, I see you've come to the same conclusion yourself...

Re:JAVA is the suv?

[wegrzyn]

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.

Re:JAVA is the suv?

[Twylite]

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.

With a dynamic language ... you could do bind variables by having the database interface look at local variables in the caller's environment

And if you look at development guides and bug reports, you'll find that it is exactly this sort of implementation that has insidious security holes. The security of systems that provide such shortcut functionality depends on the developer understanding how to use the system properly. Unfortunately it is quite often developers who don't have the time or inclination to understand that use these shortcuts.

With Web applications, nearly all of the engineering happens in the SQL database and the interaction design, which is embedded in the page flow links. None of the extra power of Java is useful when the source of persistence is a relational database management system such as Oracle or SQL Server

Greenspun seems to believe all "web applications" are Internet (rather than Intranet) applications. Beyond management systems (CMS and document management) I have seem few significant intranet systems that are merely a web interface to a database. Many intranet web applications interface to accounting, stock, POS, banking, quotation and other systems, where integration cannot be accomplished using a database. A Gung Ho "do it all in the web page because its fastest" approach is the quickest route to failure.

So ASP and PHP have their place, and they're almost certainly easier to understand for a CS senior who isn't interested in reading up on the design principles behind JSP ... but that doesn't make them better.

Re:JAVA is the suv?

[Hard_Code]

The second part of the course he runs (or at least writes the curricula for??) should be to actually MAINTAIN the last class's code. Then he might get an idea why a lot of people prefer Java and servlets (and to a lesser extent JSP) over ad hoc glued together scripts.

Re:JAVA is the suv?

[hplasm]

Ok, then Java isn't an SUV. It's the Econoline/ Transit van of the programming world. Until you get stuck behind it, it's fine...

Re:JAVA is the suv?

[PowerPill]

This is my own opinion drawn from my own experiences. Flames not necessary. =)

Has anyone ever considered where you might cut costs in one place you might end up losing those gains in another? Like robbing Peter to pay Paul sort of thing.

Yes I've heard It makes for a rapid devel environment from many a developer/programmer as it facilitates ease of coordination efforts etc. The last company I worked for decided to become a fully accreditted registrar a few years back just in time for the release of the .ca registry to CIRA... Devel used Java.

The decision was based on the idea that the sooner we were up and running the better jump we'd have on the competition. At the time we were the quickest company to ever set up a "registry shop" from the get go. It took us just over 5 months. And it worked. We had an edge over others concerning .ca's. Great...

But it was an administrators NIGHTMARE to keep the system up and running afterwards. I was always against java for jobs as big as that and well... That experience proved it once and for all for me. It wasn't like the developers were morons either. They were some of the brightest minds I've ever had the pleasure to work along side with.

So with rapid development aside, does that nullify the expense of deployment and maintaining the end system? I sincerely believe that money could be saved in the long run if (in this case) Java was left well enough alone. Maybe there are some true success stories regarding systems based on Java but I haven't ever witnessed the creation of one myself. But in retrospect, we did get the "jump" though.

I'm not a developer, just a lowly systems engineer so I can't throw forth many of the virtues of using Java(I use perl/php/shell scripts etc). I won't argue that point as I beleive the good things people say about it(Java).

But I can truly attest to dealing with it afterwards! All that that experience showed me was that if you need something up and going in a pinch, Java can do that for you. But Quick'n Dirty isn't always the best choice. We could have just as easily used perl instead. Basically I beleive this is something to really consider before making any final decisions.

Just my 2 cents...

Re:JAVA is the suv?

[Ed Avis]

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.

Re:JAVA is the suv?

[ElGuapoGolf]

Hello World doesn't really count for portability, does it?

I know with Java I can write an application with DB connectivity and a GUI and have it run on AIX, Windows, and Linux. Without having to change a line of code.

Now I know it's possible to do this with C (Actually, is it? Is GTK available on AIX? Is GTK any less horrible on Windows than it used to be), but it'd take much more time, and I'd end up with all sorts of conditional code based on OS.

I might suggest Java is the language of choice for programmers who have jobs to do, need to write tight code, and don't have all the time in the world.

Re:JAVA is the suv?

[revscat]

Plus imho Tomcat is a pain in the ass to configure, and you gotta keep javac'ing, and so on. Just give me a language where I can throw in a little bit of code in the middle of a webpage, in the regular web directory, and be done with it.

Boy, what da HELL you talkin 'bout? Looky heah:

<body>
<p>
<% for (int i = 0; i < 100; i++) { %>
<b>Youz dummer dan a gator on whiskey!</b>
<% } %>
</p>

Now, what so hard 'bout dat? Looks like code t'me! Looks like it's in the middle of a page! Hit it, load it, be done with it. Need t'change a value? Change it, save it, reload it. You all needs t'pull yo cranium outta yo backside, mmmhmm.

"Gotta keep javac'ing." I declare, that's the DUMBEST thing I done heard all day.

Re:JAVA is the suv?

[KDan]

A little database app isn't worth considering Java for. Would you write a trivial .sh file in assembler or C? Didn't think so. Don't write little db apps in java, either.

For a big, enterprise-class db-driven web application, though, J2EE is a treat (there's a reason why it's called Java 2 Enterprise Edition).

Daniel

Re:JAVA is the suv?

[Mr. Shiny And New]

Well, I have only one point to make in response to your comment about your project. In general, a programming language doesn't have anything to do with code maintenance. A well-written C program will be just as easy to maintain as a well-written java program or a well-written php program. However, some programming environments (like java) provide/enforce certain features for organizing code which helps. But in the end, it's up to the developers to write properly organized code, that does the job right.

I've seen java products that succeeded and java products that failed, and it's not usually Java that decides the difference. However, I have noticed that programs written quickly, in order to get to market faster, usually suffer from having too many corners cut in the design and implementation. These affect long-term maintainability more than the choice of the language.

Java can help you get to market faster (than, say, C) by eliminating certain kinds of bugs, like memory bugs, and by providing a set of tools (like the Java class libraries) to help you write business code. But in the end, the programmers are responsible for writing the code you have to maintain.

Re:JAVA is the suv?

[StillNeedMoreCoffee]

"It enforces a particular style of programming (right down to naming convontions), it takes a specific programming 'paradigm' (OO) to an unnecessary extreme and it's chock full of trendy buzzwords and BiCapitalised MumboJumbo. Perfect for PHBs."

So whats your point?

If you are writting low level nose to the cpu clock code, then you use a prettied up assembler language alike C or C features of C++. If you are writting time critical applications (short time to customer) then you are writting in a highter level language, or in C++ using the OOP features. If you are using the OOP features in C++ then the proformance is comparable.

But at the end of the day, if you have a memory leak or if you have to go back and actually maintain or evolve your code over time (them most common business situation) then a clearer language and easier to change environment is where you want to be.

If you asked me if I wanted to reverse engineer someone else's code to modify it, and one case was a C or a C++ program and a Java program. Well no contest. I have a chance of getting home on the weekend if it is a Java program. The other and lets burn the late night oil just to understand it.

Sometimes conventions pay off big time.

Re:JAVA is the suv?

[ElGuapoGolf]

See... that's bad....

Swing hasn't been slow for a long time. Bad programmers can make poor Swing slow, sure. Bad programmers can make QT slow. Decent programmers can make GTK do odd things (flicker anyone)...

Try using a tool like SmartCVS... completely swing based, and with a nice look and feel (it ain't ugly). It's fast and responsive, a good example of a well written swing app.

Re:JAVA is the suv?

[SoTuA]

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.

What does different JVMs have to do with portability? It's like arguing that GCC sanity checks say that C is not portable ("oooh, it says my compiler is not the same one used for compiling my kernel! Who said C is portable? I need DIFFERENT COMPILERS, oh my"). Or you really expect portability to mean the same BINARY EXECUTABLE runs on every platform? (in java your .class files are portable, your JVM is *not*. The jvm must be platform-specific.)

so I guess that would make C# the....

[Anonymous Coward]

Pinto?

Re:so I guess that would make C# the....

[Epistax]

I think VB would be one of those things you put together with lego.

Finally

[doe]

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.

Re:Finally

[Anonymous Coward]

I've been writing web applications since the late 70s (initially for the NSA before we made it public) and in my experience Java has a lot of inherent faults that render it useless for large scope projects.

It's cross-platform feature has been tainted by the agenda of the forces that dominate the respective operating system (BeOS, Windows, OS/2, Mac OS, and AIX). That is a pity since Sun had done such a phenomenal job in releasing the first public Java release back in 1985 which at the time would run on Commodore 128 and my Amstrad PC. About a year later they released a IBM PC version but unfortunately it required 256k of memory which made it dificult to deploy at the time.

Re:Finally

[gilgongo]

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?

Re:Finally

[Hard_Code]

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"

Re:Finally

[(trb001)]

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

Re:Finally

[Lordrashmi]

JSP sucks....

However, I currently am working to migrate our PHP web application to Java and it is going well. I am using Servlets + FreeMarker templates. Using a template system allows me to change some of the presentation details without recompiling and Servlets prevent me from killing myself because of the giant nasty hack that is JSP...

Yes, I might seem bitter but I can see no real reason to use JSP. The only argument I can get from anyone on for it is "You don't have to recompile and deploy it". That was a good point before application servers accepted changes on the fly to the code. Now I just recompile the one servlet and Tomcat reloads it. Simple...

Re:Finally

[Anonymous Coward]

as silly as putting Linux on your toaster...sure you could do it, but it's not the most efficient solution.

That's right. Everyone knows that NetBSD is the toaster OS of choice!

Re:Finally

[cca93014]

Firstly, yes, Java was never meant to be a scripting language.

Secondly, if you are building large web applications with a scripting language then you are not doing it right. I do not believe you came up to an overhead problem in Java and not PHP. Java outperforms PHP, period.

Actually I think you are talking bullshit.

Re:Finally

[doe]

Not really

We're using PHP to connect to different sort of backend databases and other services. We used mostly Oracle in the past, but have made a move to Postgres mostly due to the cost. We're still using Oracle for clients who are willing to pay for it.

My most recent assignment was using DB2 on an IBM iSeries machine (formerly known as AS/400).

PHP can and is used to develop "enterprise" size web applications. It doesn't have to be Java. And I can been the cost of any Java shop around here.

Re:Finally

[Bob9113]

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.

Re:Finally

[Lordrashmi]

No HTML in my Java. Like I said in my post, I use templates. All HTML goes into the templates.

I choose what objects to expose to the template engine, and the template engine then merges the objects with the template. For example, when a user logs in, an object is created that contains personal preferences like font size, colors, what content they want on their front page. Lets call this object "blah" though I can expose it to the template using any name I want. In the template, if I want to get information from that object, I just call ${blah.myMethodName()}.

Re:Finally

[Moraelin]

Let me educate you on a point that you seem to completely miss. (And lots of people with lack of real life experience in large projects miss.) That is: the difference between prototyping and actually making a robust, scalable and (most importantly) maintainable product.

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.

Re:Finally

[Lordrashmi]

Like I said in one of my other comments, my hatred of JSP's come from co-workers ugly code.

I am sure that there are better ways to do JSP then how they were doing it, but it left such a bad taste in my mouth that when I was evaluting how we were going to write our new application, I much prefered Servlets + Freemarker.

If I ever see a case where I think JSP or any other item can do the job better, I will use it.

As far as FreeMarker sucking, I think that was just Velocity/Turbine bitterness. I have had many more issues with Velocity then I have with FreeMarker.

Programming lesson 101

[192939495969798999]

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.

Re:Programming lesson 101

[avdp]

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...

Re:Programming lesson 101

[Pfhreakaz0id]

well, I have a java/web application that doesn't have a signle SQL statement, but it uses Toplink to do a object to DB mapping.

I agree though, short of a mapper tool, you're gonna have to have SQL SOMEWHERE.

Re:Programming lesson 101

[192939495969798999]

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

Re:Programming lesson 101

[I8TheWorm]

Um.. Stored Procedures anyone? LDAP authentication? Connection strings in server side objects? There are TONS of ways to have DB code without stored SQL strings. Plus, you can change SP's without recompiling.

Re:Programming lesson 101

[NeXS]

we developped a SQLRepository object which stores sql code and definitions in an xml file... This file can be packaged together with the jar or an external url... It could be possible to transfert it via secured https to prevent the user to see db structure...

Re:Programming lesson 101

[KDan]

Hibernate.

Daniel

Re:Programming lesson 101

[SoTuA]

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

Re:Programming lesson 101

[Ed Avis]

Pray tell what is the problem with hardcoded SQL statements? Why are they any worse than hardcoded C statements or hardcoded Java statements or hardcoded shell scripts?

SQL is a much higher-level language than C or Java or even Perl. This is why people who talk about 'database abstraction' are usually missing the point. SQL is an abstraction, and a much more expressive one than some object-based mapping full of get_x() and set_x(). But unlike many high-level languages, the extra abstraction of SQL gives you _better_ performance by letting the database optimize your queries for you.

Re:Programming lesson 101

[Dr. Bent]

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.

Re:Programming lesson 101

[shostiru]

Discovering database schema is trivial with many DBMSes, only slightly less trivial in the others. And why would you want to hide your database schema? Anyone who truly wants to steal your schema will have the tools or knowledge to do so. Those most affected will be customers who want to run their own SQL queries against the DB.

I can see the virtue of dynamic SQL queries -- I use them myself occasionally -- although a well-designed DB can go a long way towards reducing the need. However, you've still got a performance hit and increased code complexity with dynamically constructed queries. In a relatively simple app where runtime isn't an issue this is less relevant, on a 100KLOCS app with a hundred million or so entities it's not necessarily a good idea.

Re:Programming lesson 101

[JustAnotherReader]

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.

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.

Re:Programming lesson 101

[holzp]

you could also write your application to suck up huge amounts of memory and bandwitdh for no reason but buzzwords...

Re:Programming lesson 101

[Dr. Bent]

Memory is cheap. Programmers aren't. Any task that I can delegate to a 3rd party library or EJB container is going to save me money and time, and if I have to spend $250 to double the amount of memory in my server, then fine. It's much better than spending weeks of development on a hand-coded SQL persistance mechanism that has to be designed, written, tested, documented and maintained.

Besides, the local entity beans in CMP 2.0 reside in the same VM as the client code, so no RMI calls, and no bandwidth usage. And just as compilers are better at optimization than 99.999% of programmers, chances are an EJB container can optimize database connections and object pooling better than you can.

O/R mapping tools are very powerful. They save time and money. If you like writing SQL queries yourself, and don't mind working overtime to do it then fine. Me, I like to go home every once in a while.

Re:Programming lesson 101

[avdp]

Oh yes, I can completely see the benefits of storing SQL statement in text files (XML or otherwise) - no question about it. Although I do most of my web programming in scripting languages that don't require compiling, so the benefits are somewhat mitigated. Although typing make is not that hard anyway.

The original poster I responded to seemed to be horrified at hard coding SQL statement since doing so may reveal the db schema to a user. Well, whatever. I don't see the point of hiding a db schema from anyone (is there anything particularly innovative about a db layout? I could probably come up with my own faster than decompiling anything). I would be more concerned about keeping intruders out of my database than hiding it's schema.

Penis extension?

[skaffen42]

OK, I've heard Java called a lot of things and I know it has its faults, but I really don't think the SUV comparison holds water.

Nobody ever started using Java because they wanted to compensate for a small penis, which is the only possible reason for buying an Hummer.

Complex programming

[BWJones]

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.

Whatever dude.

[botzi]

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

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

Re:Whatever dude.

[B'Trey]

Well, yes. That's exactly the point. An SUV isn't a useless machine. For certain circumstances, it's the perfect vehicle. But it isn't the perfect vehicle for running back and forth to the corner store, and Java isn't the ideal language for scripting web pages. The whole point of camparing Java to an SUV is that both are powerful pieces of equipment all too often used for trivial tasks.

And you can't say the same thing about C++ because, at least last time I checked, there weren't very many web pages being written in C++.

Re:Whatever dude.

[hachete]

He's obviously never had to maintain large perl programs. Given the potential for pitfalls (synonyms are shite, scoping is just pure bollocks wrt $_, I've met precious few people who know what local means, even if it is written in the book - having two mechanisms for scope - just how does that work then?), I wouldn't use Perl for anything bigger than a 100 lines, even then it would have to be "throwaway".

$_ doesn't matter on a small level like that but $_ with a couple thousand functions and various programmers meddling at intervals, not at all entirely contiguous and it'a recipe for disaster. Been there, done that. Never again.

If someone were to say to you "I'll just write this little script, it won't take me long" I'd advise that you either (a) fire them or (b) run for the hills. They have no idea what they're doing. In the long run, all you get is grief.

Oh yes, I've seen the cesspit that is CPAN.

h

Would you like a nice long sig with that, madam?

Re:Whatever dude.

[yomahz]

But it isn't the perfect vehicle for running back and forth to the corner store, and Java isn't the ideal language for scripting web pages.

That's the thing... most people who develop dynamic websites are developing rather simple applications that are fine for scripting languages such as Perl or PHP.

That really doesn't mean that Java doesn't have it's place as a Web/HTML/XML language. When you start to develop Enterprise level webapps you'll soon start finding yourself with a bunch of spaghetti code to maintain with these scripting languages.

When you're integrating Web Services, XML, distributed computing with transactions, security, resource pooling, and concurrency you'll, more than likely, find yourself in a world of hurt. That's where Application Servers, EJBs, and frameworks that use established, successful design patterns (such as Struts, JSF, etc.) come into play.

Sure it's overkill for your average web scrapper but it definitely has it's place. Even if you were able to squeak out an Enterprise level application with Perl or PHP faster than Java, I'd place a hefty wager that you'll spen 10x the amount of time supporting and extending it.

Jeep is better than SUV

[mnmn]

Where ANSI C is the jeep of them all. C++ is a two-door which looks nicer but is slightly less useful. C can be used and abused by anyone anywhere and will obviously outlast Java, but anyone with money to throw and show off (at the cost of wasting enormous resources) will get the SUV. Smaller programmers here and there (not smaller in importance) will use the bicycle which would be Perl. For now, I'll just take a walk (BASIC)

Re:Jeep is better than SUV

[pebs]

Take a hike (use assembly language)

Re:Jeep is better than SUV

[Master Controll Prog]

no, you misunderstand asm. and seth is still a not-very-dark name, no matter what you say.

mv drk sth
nop

Java's not an SUV!

[Steve G Swine]

SUV's start up instantly!

Like a SUV huh?

[weave]

Let's see, I can't read the article because it's slashdoted already, let me take a stab...

Weave's rushed tongue-in-cheek SUV vs JAVA comparison:

• Very successful, can't sell enough of them. Nope
• Crushes the competition (anything that gets in the way). Nope
• Able to crash in spectacular ways if not handled correctly. Maybe
• Bloated, overkill. Yes
• Wastes resources. Yes
• Preferred by men with small penises. Yes
• Can put everything including the kitchen sink into one. Yes
• Is seldom used to do all of that. Yes
• Promoted by using annoying advertising. Yes

Re:Too much formalism

[msgmonkey]

Bad programmers write bad programs regardless of the language.

Java's Cover

[nthomas]

The blog seems to be down, but in case anyone was interested in a similar story:

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

Re:Java's Cover

[Avumede]

Graham's article is a load of crap. Not having any factual information to say, his arguments against it are:

1) It's bad because it's energetically hyped. Unlike Lisp, where no one uses it because everyone is too busy posting on comp.lang.lisp about how wondeful a language it is?

2) It's aimed low. Gosling has already called bullshit on this argument.

3) It has ulterior motives. So what?

4) No one loves it? Well, those of us who used to use C++ appreciate it a hell of a lot.

5) People are forced to use it. Wrong. Countless companies choose it because it is an appropriate technology.

6) It has too many cooks. I find this a huge advantage to Java. It means their API's very well thought out. It's why Java is nicely internationalizable, for one.

7) It's bureaucratic. Their API's are no more verbose than many languages. Any "bureacracy" that exists is to promote flexibilty.

8) It's pseudo-hip. Like quoting Paul Graham.

9) It's designed for large organizations. True, because large organizations have to do somethign more complicated then the typical perl script can handle. His arguments here are debunked by Gosling in my previous link.

10) The wrong people like it. That is, Paul Graham's friends don't like it, people Paul Graham doesn't know like it! What an argument!

11) Its daddy is in a pinch. I fail to see how this is relevant.

12) The DoD likes it. The DoD also likes the internet, they were one of the first government agencies to really take to it. Does that say something bad about the internet now?

Comparing Java to Lisp or (ugh) Perl is a joke. Well, I think perl is very ugly and counter-intuitive, so let's take Python as an example. If I were to make a simple website, i'd use Python instead of Java. If I were to do a hacker type of activity, something that may not be around 3 years from now, I'd use Python. Or even Lisp if it was something just for me. They'd be wise choices. However, for an enterprise app? Java is an excellent choice.

Re:Java's Cover

[Sphere1952]

I've been at this programming thing long enough to know that everything Graham said is completely correct.

In fact, strong typing is stupid. If you want to treat a byte as a char in one statement and as a bit vector in the next you shouldn't have to beg the computer to let you do exactly what it does on its own. (Study the bit structure of ASCII sometime, and you'll understand.)

Re:Java's Cover

[KrispyKringle]

"strong typing is stupid"

I think that speaks well for your credibility. You've been at "this programming thing" for a long time, eh? I assume the only languages you've used have been scripting languages like Perl, PHP, and Python? Or perhaps you program enterprise-level applications entirely in assembly, eh? Cut me a break. Strong typing is a core requirement in any serious programming language (don't get me wrong; I'm a huge fan of Perl and PHP has its uses, but neither are meant for the sort of tasks you might use C, C++, or Java for--and vice versa; C, C++, and Java are hardly meant for quick-n-dirty scripting).

And don't get so arrogant. "Study...and you'll understand," right? I understand a few things. In my experience, programmers--myself included--benefit greately from the checks and controls of strong typing. Without it, the compiler cannot make sure that you, the coder, aren't doing something stupid. And yes, you can say, "well, I don't do that sort of thing and don't need no stinkin' machine to help me out" but thats just ignorant. The entire process of programming is one of interpreting human ideas into machine instructions. That's a task people aren't particularly good at, and the more help we can get, the better. That's why you don't program entire apps in assembly, thats why we have compilers check for syntax errors, unreachable statements, and other stupid things, and thats why we have strongly typed languages to make sure we aren't doing something stupid.

Oh, and you ever have to work on a legacy app someone programmed in PHP or Perl or some other weakly-typed language? It's pure hell.

Re:Java's Cover

[butane_bob2003]

4. No one loves it. C, Perl, Python, Smalltalk, and Lisp programmers love their languages. I've never heard anyone say that they loved Java.

What?
I love Java. There I said it. Of course script kiddies love their languages. What else do they know? I think Paul Graham should try building an enterprise app in java before hes starts spouting mostly foundles criticisms. Most of the people who have nothing good to say about Java know fsck all about it. This holds true for most people's views on languages/technology. Ignorance is bliss, write an article!

Thank You

[JamesP]

Someone spoke for that overbloated thing that is Java.

Sun really beat M$ in THAT game. If you want to do anything in Java you need a hundred classes, calling a million methods and passing them several times.

PHP and ASP are much more simple.

Java joined the complexity of the Windows API with the speed of an interpreted language, along with some bitches as strong-typing, millions of similar classes.

PHP
cut(bread)

ASP
bread.cut();

Java
knifeh = new KnifeHandle
knifeb = new KnifeBlade
k = new Knife
k.Attach(knifeh)
k.Attach(knifeb)

_try()
{ bread(k.cut)
}
catch (Outch)
{
dial.dialnumber(911);
}

Re:Thank You

[rjstanford]

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:

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 /usr/human/hand/finger on line 29371"

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

Re:Thank You

[erikdotla]

#!perl
$bread = qq(wheatwheatwheat);
$bread =~ s/(\S{5})/$1 /g;

# :)

non karma whore article text

[Anonymous Coward]

Our students this semester in 6.171, Software Engineering for Internet Applications have divided themselves into roughly three groups. One third has chosen to use Microsoft .NET, building pages in C#/ASP.NET connecting to SQL Server. One third has chosen to use scripting languages such as PHP connecting to PostgreSQL and sometimes Oracle. The final third, which seems to be struggling the most, is using Java Server Pages (JSP) with Oracle on Linux. JSP is fantastically simpler than "J2EE", which is the recommended-by-Sun way of building applications, but still it seems to be too complex for seniors and graduate students in the MIT computer science program, despite the fact that they all had at least one semester of Java experience in 6.170.

After researching how to do bind variables in Java (see the very end of http://philip.greenspun.com/internet-application-w orkbook/software-structure), which turns out to be much harder and more error-prone than in 20-year-old C interfaces to relational databases, I had an epiphany: Java is the SUV of programming tools.

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). But the programmers and managers using Java will feel good about themselves because they are using a tool that, in theory, has a lot of power for handling problems of tremendous complexity. Just like the suburbanite who drives his SUV to the 7-11 on a paved road but feels good because in theory he could climb a 45-degree dirt slope. If a programmer is attacking a truly difficult problem he or she will generally have to use a language with systems programming and dynamic type extension capability, such as Lisp. This corresponds to the situation in which my friend, the proud owner of an original-style Hummer, got stuck in the sand on his first off-road excursion; an SUV can't handle a true off-road adventure for which a tracked vehicle is required.

With Web applications, nearly all of the engineering happens in the SQL database and the interaction design, which is embedded in the page flow links. None of the extra power of Java is useful when the source of persistence is a relational database management system such as Oracle or SQL Server. Mostly what you get with Java are reams of repetitive declarations at the top of every script so that the relevant code for serving a page is buried several screens down. With a dynamic language such as Lisp, PHP, Perl, Tcl, you could do bind variables by having the database interface look at local variables in the caller's environment. With Java the programmer is counting question marks in the SQL query and saying "Associate the 7th question mark with the number 4247", an action that will introduce a bug into the program as soon as the SQL query is modified (since now the 7th question mark has been moved to become the 8th question mark in the query).

Re:Worst analogy ever

[Anonymous Coward]

Mmm, nice comparison, can I compare assembly programming to bull running, it gets you fit and fast, but it winds up being a pain in the ass.

Harvard: The 'SUV' of Higher Education?

[hethatishere]

Just a thought from a friendly MIT student.

Re:/.'d already....

[jrc313]

Google does

Phillip Greenspun

[Hard_Code]

Phillip Greenspun == Hot air balloon of programming pundits

Re:Phillip Greenspun

[kisrael]

Phillip Greenspun == Hot air balloon of programming pundits

Clearly your anagram generation routine is broken. Here's one:
Phillip Greenspun = Gel slipper, hip nun
or
Phillip Greenspun = grep hep ills, unpin!

Obligatory: ... then C++...

[Anonymous Coward]

...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.

Re:Obligatory: ... then C++...

[shamilton]

Of course, PERL and friends, being associated with the academic and UNIX communities, don't have quite the same aroma to them.

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.

Re:its a bad comparison

[angle_slam]

Its a bad comparison from a non programmer..

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?

Java is to Visual Basic is to....

[Anonymous Coward]

My opinion is that Java is a great language and has great portability. It is a good language to learn for the future. Visual Basic is the tool of Microsoft's own agenda. I know Visual Basic 6.0 great, but I was handed some code using VB.Net and I was unable to get the new structure down without significant time. Now if someone has only has .net, what will they do when they want to update my 6.0?

Scroll ahead to java. The programs I wrote years ago are still applicable and can be updated by anyone with any good working knowledge of java. In addition, Java is not going to radically change its structure on a whim or for a business decision.

Microsoft's quest to destroy other languages may render you redoing your applications every 2-3 years and even then, you may find that server functions suddenly stop functioning because of an autoupdate.

For me, Java is the way to go for now. Others may go with VB. It doesn't matter as long as the job gets done and we can stop this arguement. BTW, look at the job openings for a java programmer vs. VB.

-SenatorPerry
http://www.newberrycollege.net

Re:Make Java Open Source!

[jacksonyee]

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.

Ummm... RTFA?

[sporkboy]

JSP is fantastically simpler than "J2EE", which is the recommended-by-Sun way of building applications, but still it seems to be too complex for seniors and graduate students in the MIT computer science program, despite the fact that they all had at least one semester of Java experience in 6.170.

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.

Google cache

[stienman]

Google cache of the blog entry.

Also below:
Our students this semester in 6.171, Software Engineering for Internet Applications have divided themselves into roughly three groups. One third has chosen to use Microsoft .NET, building pages in C#/ASP.NET connecting to SQL Server. One third has chosen to use scripting languages such as PHP connecting to PostgreSQL and sometimes Oracle. The final third, which seems to be struggling the most, is using Java Server Pages (JSP) with Oracle on Linux. JSP is fantastically simpler than "J2EE", which is the recommended-by-Sun way of building applications, but still it seems to be too complex for seniors and graduate students in the MIT computer science program, despite the fact that they all had at least one semester of Java experience in 6.170.

After researching how to do bind variables in Java (see the very end of http://philip.greenspun.com/internet-application-w orkbook/software-structure), which turns out to be much harder and more error-prone than in 20-year-old C interfaces to relational databases, I had an epiphany: Java is the SUV of programming tools.

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). But the programmers and managers using Java will feel good about themselves because they are using a tool that, in theory, has a lot of power for handling problems of tremendous complexity. Just like the suburbanite who drives his SUV to the 7-11 on a paved road but feels good because in theory he could climb a 45-degree dirt slope. If a programmer is attacking a truly difficult problem he or she will generally have to use a language with systems programming and dynamic type extension capability, such as Lisp. This corresponds to the situation in which my friend, the proud owner of an original-style Hummer, got stuck in the sand on his first off-road excursion; an SUV can't handle a true off-road adventure for which a tracked vehicle is required.

With Web applications, nearly all of the engineering happens in the SQL database and the interaction design, which is embedded in the page flow links. None of the extra power of Java is useful when the source of persistence is a relational database management system such as Oracle or SQL Server. Mostly what you get with Java are reams of repetitive declarations at the top of every script so that the relevant code for serving a page is buried several screens down. With a dynamic language such as Lisp, PHP, Perl, Tcl, you could do bind variables by having the database interface look at local variables in the caller's environment. With Java the programmer is counting question marks in the SQL query and saying "Associate the 7th question mark with the number 4247", an action that will introduce a bug into the program as soon as the SQL query is modified (since now the 7th question mark has been moved to become the 8th question mark in the query).

-Adam

Godling's Glossary for Java

[SuperBanana]

Java, n.
The Philosopher's Stone of the alchemists, the Second Coming of Christ, the Maltese Falcon, and the fourth Star Wars movie, all rolled into one. A technology for developing programs that will run on any platform, and crash in a different way on all of them. A mighty acorn that grew from a tiny Oak. An idea whose time has come, leaving General Magic to sleep on the wet spot.
-Godling's Glossary

i'm sorry but..

[gl4ss]

**Our students this semester in 6.171, Software Engineering for Internet Applications have divided themselves into roughly three groups. One third has chosen to use Microsoft .NET, building pages in C#/ASP.NET connecting to SQL Server. One third has chosen to use scripting languages such as PHP connecting to PostgreSQL and sometimes Oracle. The final third, which seems to be struggling the most, is using Java Server Pages (JSP) with Oracle on Linux. JSP is fantastically simpler than "J2EE", which is the recommended-by-Sun way of building applications, but still it seems to be too complex for seniors and graduate students in the MIT computer science program, despite the fact that they all had at least one semester of Java experience in 6.170.**

but they should be able to do them in all three of the choices they had, or was the course subtitled: "gaining profiency in one of 3 systems for doing one kind of a web project"?

and jsp is simpler than j2ee? jsp is part of j2ee, heres a clip from somewhere

***"What Is JSP?

JavaServer Pages (JSP) is a Sun Microsystems specification for combining Java with HTML to provide dynamic content for Web pages. When you create dynamic content, JSPs are more convenient to write than HTTP servlets because they allow you to embed Java code directly into your HTML pages, in contrast with HTTP servlets, in which you embed HTML inside Java code. JSP is part of the Java 2 Enterprise Edition (J2EE).

JSP enables you to separate the dynamic content of a Web page from its presentation. It caters to two different types of developers: HTML developers, who are responsible for the graphical design of the page, and Java developers, who handle the development of software to create the dynamic content.

Because JSP is part of the J2EE standard, you can deploy JSPs on a variety of platforms, including WebLogic Server. In addition, third-party vendors and application developers can provide JavaBean components and define custom JSP tags that can be referenced from a JSP page to provide dynamic content.

"***

and are we a little generic here (from greenspun)**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).**

that's nice, what kind of a 'project' is this project in this? the whole point in using java in projects like this is that you can reuse the code in other parts straight(heck, make a game for a java phone, then use the _same_ compiled classes on the server to determine if the uploaded scores are legit that you use for game engine on the j2me device). sure there's other points as well, like not tying yourself to microsoft(though, that is a point for php as well).

and really, people who use visual basic for big projects don't except to live long.. or be taken seriously on slashdot. surely you can do it seemingly cheaper when anyone can do it(but if mit produces people who aren't able to learn any language that suits the job best in reasonable time i've kinda lost my respect for them).

Modern PCs are more like SUVs

[Junks Jerzey]

They require lots of power, and the capabilities provided by that power consumption aren't needed by 99% of the people who buy them. That' pretty much describes SUVs.

If the auto market were like the PC market, though, then you wouldn't be able to buy anything except a SUV.

Wow

[Hard_Code]

"Supposedly this situation has been improved in JDBC 3.0 but this example of Java's inferiority to C interfaces from 20 years earlier should remind you to be skeptical of vendor claims for the advantages of new languages and development tools."

Wow! You're right! I guess because Java has a minor annoyance that supposed to be fixed in the next release of that specific API, that the whole language and libraries are worthless and we should all go back to C for everything! How brilliant! I will never trust Sun again when they say "Java is a revolutionary new language whose main feature is that you do not have to set variables in PreparedStatements by ordinal value! We are basing our whole language on this!" Big fat liars. :(

Re:Worst analogy ever

[Powercntrl]

I dunno, SUV=Resource hog, slow, and bulky. Sounds accurate to me....

While I refuse to try and dispute such an inane analogy as comparing SUVs to Java, I will comment on the SUV aspect.

Where the hell does everyone live that SUVs are moving slowly?! Most SUV drivers I see on the highway go recklessly faster than the speed limit - even in bad weather. Some of the drivers honestly appear to be driving like they believe their SUV has a device under the hood that can modify the laws of physics to give them perfect traction on a slippery road and allow them to stop with the same amount of distance as a car.

Oh sure, there's the Fast and the Furious wannabes in their riced out Type R mobiles driving insane too... But when you see this big Ford Expedition tailgating you and then cutting you off so he can do 80MPH in a 55MPH zone IN THE RAIN, you begin to wonder what these people are thinking.

The vehicles I usually see travelling the slowest are soccer moms in minivans and cars old people seem to like... Crown Vics, Lincolns, Oldsmobiles.

I think everyone is missing the point...

[surfsalot]

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.

Java is like Windows XP, can anybody say bloatware

[node159]

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.

JSP type 1 applications

[tgreiner]

What this guy describes is called a JSP "type 1" application. It (ab-)uses the JSP's ability to embed Java code directly into the JSP page (which is typical for languages like PHP). Doing this is a BAD idea.

You will typically

• use Java beans or some other utiliy classes to encapsulate data base or business logic access (type 2)
  
• use a Java tag library like Jakarta struts to provide you with an application framework and common used tags (logic tags, bean access etc.) (type 3)
  

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.

My language comparison

[Jugalator]

IMHO...

• Visual Basic -- is a comment really necessary?
  
• Java -- does what it's supposed to do
  
• C# -- tries to be more advanced than Java, and is, but is rather similar in the end...
  
• C / C++ -- now we're getting somewhere... does the job efficiently, but be sure you can handle it
  
• Assembler -- it's cool, it's efficient, it's deadly if handled wrong

Discredited

[dnoyeb]

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.

Re:Discredited

[RexRuther]

I will not say that VB is better than Java, but in certain situations VB works well. It is relatively fast and makes simple programs simple.

Please don't dis VB. There is a large comunity of developers who use it, and generalizing that they are all idiots is, well, stupid.

Re:Discredited

[Pfhreakaz0id]

VB IS better than Java, for any application with a UI that doesn't need to run anywhere besides Windows.

That fact is unasailable. It will run faster, and can be written in a fraction of the time by a VB developer who has a clue at all.

Re:Discredited

[SatanicPuppy]

VB needs too much server, and it doesn't run well on any server except a windows server, which causes it's own problems.

Faster? Maybe against Java running on windows, under IIS. Faster to code? Could be. Point and Drool is hard to beat...for time.

Re:Discredited

[poot_rootbeer]

He suggests that Visual Basic is better than Java. I will refrain from comment, the quote speaks for itself.

Rootbeer's Corollary to Godwin's Law:

On Slashdot, the terms "Visual Basic" and "Hitler" shall be interchangeable.

Warning: Knucklehead

[Get Behind the Mule]

This missive contains a few blaring warning signs of a guy who has not learned best practices for Java programming, and indeed is very naive about the needs of enterprise software development.

• He seems to equate Web application programming with programming JSP scripts. In fact, he doesn't seem to draw much of a distinction between JSP and everything else that Java encompasses.
  
• In the context of Web application programming, he declares: "Mostly what you get with Java are reams of repetitive declarations at the top of every script so that the relevant code for serving a page is buried several screens down." The rationale for this statement is nowhere to be found, and it's anybody's guess what in the world he's talking about.
  
• The only concrete complaint he brings up has to do with the way you assign values to bind variables in a prepared SQL statement in JDBC. Again, this is in the context of Web applications, which he conflates with JSPs (he talks about "script variables"). But first of all, one of the very first best practices anybody learns is that you don't include raw Java code in JSP scripts: instead, use actions, directives and custom tags to lay out the script like HTML, and delegate all programming to proper Java classes. Or better yet, use a framework like Struts. And second, a guy who dismisses JDBC altogether because of syntactical construct he dislikes, without considering all of the other benefits that it provides, is probably completely naive about the needs of DB programming for the enterprise.
  
• He says: "People who are serious about getting the job done on time and under budget will use tools such as Visual Basic." No further comment necessary.
  
• Also: "If a programmer is attacking a truly difficult problem he or she will generally have to use a language with systems programming and dynamic type extension capability, such as Lisp." Again, no further comment, except to note that no one, I mean no one in business computing considers using Lisp. (Now some smartass Slashdotter will come along and triumphantly cite some obscure exception, which only confirms the rule.) This to me is a sure sign of a guy stuck in academia.
  
• Of JSP he says, "... still it seems to be too complex for seniors and graduate students in the MIT computer science program, despite the fact that they all had at least one semester of Java experience ..." I expect that seniors and grads at MIT are very smart, but good software engineering discipline usually requires years to learn, even by the smartest cookies. To expect it after one semester is another clear sign of enormous naivete.
  

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.

Re:Warning: Knucklehead

[dtrent]

I wish I had the year back I spent drinking the Java coolaid only to find out what I already knew (to turn a phrase from Louis Armstring): If it *feels* slow, it *is* slow.

Re:Warning: Knucklehead

[11223]

Again, no further comment, except to note that no one, I mean no one in business computing considers using Lisp.

Your ignorance is astounding. No, I'm not going to cite some obscure example. Instead I'm going to point you at the Franz "Success Stories" site at http://www.franz.com/success/. Read through all the categories. Then realize these are just the people who thought it worth $10k to use Franz's Allegro Common Lisp. Also see all the applications that Xanalys develops with their LispWorks product.

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.

Missed points

[Marc2k]

If you don't get why it's an SUV, then you didn't read the article.

The point is that most programmers use Java because of its premise of programmatic power. While the metaphor may not stretch to every use of Java, Greenspun talks particularly about WebApps in general, and JSPs in particular. His only point was that while Java *is* powerful, for a low or mid-end Web application system, most of the engineering has to do with designing the database correctly, and integrating everything tightly. Perl and PHP are widely used because they're not as verbose in such situations, and a more powerful language is NOT needed at the presentation layer, and Java _is_ infamous for its boiler plate requirements.

This, and this alone, is why he likens Java to SUVs, because of the metaphorical holier-than-thou driver, who buys into a $100k Hummer because supposedly it can handle hardcore 4x4ing, but in reality knows it's only driving to Bed, Bath, and Beyond and back. Personally, I'm not often a detractor of Java, but I have worked a good deal with Perl for such things, and in this respect: I agree with him.

Ummm???

[ayjay29]

How can "Java == SUV". it does not support operator overloads?

Maybe Java.equals (SUV).

Write your code and STFU

[Eisenfaust]

I am getting quite tired of these silly comparision between programming languages. Obviously, depending on the requirements of the task you need to complete a certain programming language may prove to be more useful than another. Obviously you aren't going to want to write an interrupt service routine or other such time critical platform dependant piece of code in java. But for something that needs to be platform independant java may be a viable solution.

So... pick a language, then do your job. repeat.

Obviously you aren't going to drive an SUV in a Formula 1 race, but maybe if you need to transport 7 people and tow a 20 foot long boat up to the mountains, it might be a good choice.

Java includes all the libraries/C/C++ use Unixs

[acomj]

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.

Tcl is good

[DavidNWelton]

Tcl has a lot going for it. It has a very nice C API, is simple to work with, is extendable to deal with more complex problems (namespaces, OO), and is easy to read 6 months down the road.

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.

Re:Tcl is good

[Directrix1]

I personally don't see Mr. Greenspun's point. Most kids straight out of college don't know jack about shit. I find java to be quite easy to use, and very intuitive. And it has an available toolset the size of Montanna, if one thing doesn't work then another will. With java you know you can get anything done. Its like the swiss army knife of programming languages. Granted .Net has most of these features except the availability of tools. But comparing it to a scripting language, bah humbug.

Re:Tcl is good

[GenSolo]

With java you know you can get anything done. Its like the swiss army knife of programming languages.
Well, it is a Turing-complete language afterall. The fact of the matter is, you can't do anything in Java you can't do in C++ or C or assembly language or raw machine language for that matter. The only difference is time/space efficiency, in both execution and code-writing.

Re:Tcl is good

[blibbleblobble]

"The fact of the matter is, you can't do anything in Java you can't do in C++ or C or assembly language or raw machine language for that matter."

You can write an arbitrarily complex program in any language... you just have to use that language to write a Lisp interpreter first...

Re:Tcl is good

[Slime-dogg]

The main point of the blog was a discussion of web based pages. It is interesting to note that he talks about the difficulty of students grasping enterprise Java concepts when they've only had one semester of Java programming. This semester was most likely an intro course. This is similar to letting a 12 year old drive a car, some will get it and drive fast, others will crash into a light post five feet away.

He also discusses the need for redeclarations of items in these pages, which is a design problem at worst. If his students planned properly, they'd use inheritance to take care of the common things connections and queries. There's no reason for common repitition.

The .Net environment is a bit more forgiving for beginners. Building pages is as easy as using a forms designer. This would explain his lack of complaint for that product. In most cases, however, I'd say that programming C# and programming Java are more similar than not.

As for scripting... I would tend to agree that they are better for hammering out applications quickly. The issue here is the decision to have an interpreted language versus a compiled language. I, for one, would rather have my html output code fully compiled, for the best use of the machine. It just makes more sense. :shrug:

No, Thank You!

[CausticPuppy]

For providing examples of invalid syntax in PHP, ASP, and java!

Grain of salt

[LDoggg_]

This guy's article is utter crap. Phillip Greenspun is either a moron or nothing more than a common troll.

JSP is fantastically simpler than "J2EE"

J2EE is a collection of java techonologies which includes JSP, not a single development paradigm. JSP can be used in a model-view-controller as a view or used to write simple stand-alone applications.

After researching how to do bind variables in Java (see the very end of http://philip.greenspun.com/internet-application-w orkbook/software-structure), which turns out to be much harder and more error-prone than in 20-year-old C interfaces to relational databases

Riiiight... Because there is only one way to do this in Java.
First off this is not an inherent problem to Java, but a problem of developer implementation.
Prepared statements are only one way to communicate with databases. You can create your SQL any way you'd like and even bind parameters yourself an then execute a regular Statement.

This is all moot anyways if you plan on teaching students what the real power of using an Object-Oriented language. Most people that have to do this sort of thing for a living would have a bstracted the database layer into objects that thier view is using. The actual method of database connectiving is not irrevelant, but certainly not a hindrance to productivity.

A project done in Java will cost 5 times as much

Good thing he provided research to back that up... Oh wait a minute, he was just trolling again.
5 times more expensive? Hmmm.. apache/tomcat is free. Eclipse is free. You can pull down an SDK from Sun for free.
Well maybe he meant that it will take 5 times a long and of course time=money. Nope. He said that it will "take twice as long ". Confusing logic to say the least.

None of the extra power of Java is useful when the source of persistence is a relational database management system such as Oracle or SQL Server.

Sure buddy, tell that to Oracle. Oracle happens to use Java for its business applications.
Applications based on Relational databases is where Java excels. The java language isn't the reason, its what is being done with Java in the real world that matters.
There are plenty of tools some free some not, that take databases with referential integrity constraints to build objects (JavaBeans, EJBs, JDO, Torque, whatever) with child-parent releation ships and automatic persistence.


Its really a shame that this guy is allowed to teach at MIT.
Here's an idea: how about teaching students to use the right tool for the job? He should leave the zealotry at home unless he could back it up something more than an uninformed tirade or a ridiculous apples-to-oranges comparison with an even more idiotic analogy.

java sql question marks characters

[evil_one666]

With Java the programmer is counting question marks in the SQL query and saying "Associate the 7th question mark with the number 4247", an action that will introduce a bug into the program as soon as the SQL query is modified (since now the 7th question mark has been moved to become the 8th question mark in the query).

Although I am a fan of java I have to agree on the above criticism. Surely there must be possible to build an SQL statement without all those question marks. You dont need them in clean SQL so why do you REALLY need them when calling a statement from java. (I know, I know, you need to delineate fields- well lets make a more elegant field delineator)

Its always a bug waiting to happen

I used to think Greenspun was a pompous ass

[*weasel]

... 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.

Re:I used to think Greenspun was a pompous ass

[16K Ram Pack]

did you miss the symbol out here?

I'm happy to hear someone make a clear argument and provide case studies or statistics to back it up (or parallels). I know I can often get defensive for my position.

But in the case of what he wrote, it seemed sloppy and badly done. Java takes 5 times as long as PHP? On what? A few examples of individual programmers working solo on a non-enterprise project. Bear in mind that I like PHP and I have little knowledge of Java.

Students have totally different priorities to a manager in a computer department. What they build doesn't have to be easily maintainable or allow other developers to easily extend it.

Re:Wahhh !!!

[-brazil-]

Java is slower than C you blockhead. How could it be any other way, given that Java is interpreted whereas C is compiled!?

Java has not usually been "interpreted" for years. And in its JIT compilation, it can use optimizations based on data available only at runtime, which could in some cases make it faster than precompiled C code. Admittedly, that's rare and most of the time Java is slower.

business computing with Lisp

[brlewis]

Who do you think keeps Franz and Digitool in business? Hobbyists? I don't think so; they'd be using one of the free implementations. Your "no one in business computing considers using Lisp" comment shows you don't know what you're talking about.

I myself use Scheme in my employment, and it's helped a lot.

Background

[Ed Avis]

It might be helpful (for those who don't know) to learn a bit about the ArsDigita experience with Java. aD was philg's old company and developed a toolkit (the ACS) based on Tcl and Oracle. The software was a bit kludgy in many ways but had the advantage of being fairly scalable and written close to the database, so you could tune the queries and generally figure out what was going on. The lack of typechecking in Tcl didn't matter too much because SQL queries and stored procedure calls are checked at compilation - and besides, if you keep the edit-test cycle down to under a second you can quickly find bugs.

The rewrite of the system in Java, based on using database abstractions and (would you believe) HTML abstractions was a complete crock and ended up being not only slower than the Tcl/SQL version, but less maintainable and much more buggy. I think they got something out of it in the end, after dropping 90% of the extra complexity and object-oriented-itis, but there's no way Java plus an object-relational mapping layer was the right implementation language.

OpenACS and Java makes a similar argument to philg's, but more coherently and less trollishly. I agree with his essential points however. And what he writes is based on experience, both with managing a web development company and with teaching students.

Java has issues, but not the ones mentioned here

[Headius]

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.

This guy has no idea what he's talking about.

[Dr. Bent]

JSP is fantastically simpler than "J2EE", which is the recommended-by-Sun way of building applications

JSP is a component of J2EE. Here's a tip: When you have an "epiphany" about the nature of something, it ususally helps to have at least a basic understanding of whatever the hell it is you're talking about.

Nah...

[hding]

For example,

http://www.cliki.net/Database

I personally use Pg most of the time now, but I used to use CommonSQL (that comes with Lispworks), on which UncommonSQL is based. That really makes database access dead easy in Lisp.

Re:Programming lehttp://developers.slashdosson 101

[wasabii]

Depends on the application. Check out JDO (Java Data Objects), Hibernate, and Castor. They are all OO->DB frameworks. Your app works with objects, and all the various things objects have, properties that return scalars, properties that return other objects (relationships), properties that return lists of other objects. They map those onto DB statements, which may be generated at application start in a fraction of a second. Usually you build your object model, and then an XML file or two describing the relationships between your objects, and it Just Works. The XML can be autogenerated from the classes themselves if needed.

You would be suprised how many "robust and power applications" do not in fact require much out of SQL at all. Hence the various pushes/ideas with object databases.

Now, if your app is a large reporting app, doing massive SUMs and GROUPings, sure. This doesn't cut it. But it's amazing how the majority of apps just manipulate a set object model.

Phil Greenspun is not anti-Java

[Alethes]

In about 1997, Phil Greenspun wrote in his How to be a Web Whore Just like Me book in Chapter 8:
"You should learn Java. I predict that it will gradually supplant C over the next ten years. Java is going to be big. You heard it here first."

In this particular post, he is not saying that Java is not ever useful or practical. He merely states that people who develop in Java are often using a tool that is not especially suited to the task -- that it's not always the right tool for the job. This is exactly like a single guy who does nothing with his SUV except do a one hour commute to work and home -- it works, but there are more practical solutions.

JSP is OK

[Baki]

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

Re:JSP is OK

[Lordrashmi]

I guess I shouldn't have been so zealous in my hatred of JSP. I am by no means a purist. Hell, I was primarily a PHP programmer. My hatred for JSP comes from seeing the horrible nasty code that the so called "java experts" in another programming group at my company write. I guess I should remeber that even evil things (JSP, .NET, Broccoli) can be used for good.

Huh???? PHP -Good, Java-Bad?

[theolein]

As someone who used an overly complex PHP "application server" for a project that was screaming "decent seperation of logic and presentation" I think the guy is on some nice drug.

PHP is fine for smaller applications. It is an utter desaster for large applications that need maintenance and the ability to be coded by many inidividuals. Every bit of templating done in PHP has to be done by hand or you have to have intimate understanding of the code for the "application server".

JSP allows you to use Java's strengths in that the logic can be done in servlets, beans etc and implemented as one line JSP tags. It's overhead heavy for small projects but excellent for larger ones where you will still be able to figure out what the code does if the original developer left or got fired. This is similar to ASP.Net I imagine.

His comparisons say nothing about the scope of the students applications or the tools used. Anyone doing a whole application in JSP is going to suffer, and this is because JSP is not meant for this, and a comparison of JSP and PHP on this basis alone will make PHP seem better than it is.

As someone else mentioned: Use the right tool for the job.

Re:My Java Problem.

[jjohnson]

Allow me to translate the parent: "Java sucks hairy donkey balls. Convince me otherwise."

Bind variables and SQL

[Stu Charlton]

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.

Greenspun somewhat misguided

[flakac]

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.

Re:Because, prudence

[Ed Avis]

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.

Re:Yikes!

[flab007]

now, there you go! You just circumvent these ugly SQL strings in your code by using .. stored procedures. Plain and simple!

instances vs. classes

[shemnon]

Ahh, the good old ==. We are talking about Java, and instance of something, and an SUV, a tpye label assigned to various other isntances. The headling won't compile, you need to say Java == SUV.class but that's not quite right either. So what the headline should say is...

Java instanceof SUV

We'll ignore the bad naming conventions, specifically it should be a lowercase J. Dont forget also that Java instanceof 3GL and Java instanceof OO.

My favorit happens to be Java instanceof ToyLanguage. The difference between men and boys? The size of their toys!

Java is the UBT

[lardbottom]

Urban Battle Tank

Where else can you feel so safe, but completely fuel inefficient? Plus, if you run into someone else's code, you'll be just fine.

Re:Look what it's competeing against.

[mobiGeek]

... but Php and Java aren't even the same kind of programming language

Agreed.

Java can be used to create all the same types of apps that C can

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++).

...though C cannot be used in all the apps Java can (i.e Web.)

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

As for perl, the fact that it has to be compiled every time it is run kinds of takes away from any speed advantage over Java.

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)

The only language in common use that does everything Java does is fricking Visual Basic

Well...no. VB is stuck on one platform (well, two if you consider MS-Java...though VB.NET is NOT VB).

Re:Programming lehttp://developers.slashdosson 101

[kpharmer]

In my experience the result of this approach limits the database queries to simple selects of lists or individual objects, updates, and inserts. That's fine for many prototypes of simple applications (with very simple data models).

But it breaks down as you add more functionality to the application. For example (keeping it very general) lets say that you want users to select a category to drill-down into for further work. You might start out with just a category name being selected and presented to the user. However, the next step is usability will be to add additional attributes to the name - so that the user has a sense of which categories have the most activity, most pending 'requests', or whatever. So you then need to also select attributes for each category like:
* number of orders/requests/etc performed in last 24 hours
* total number of articles/orders/etc
* number of orders/requests/etc in a critical status

How do you generate the SQL for those attributes. Now, if you are writing your own SQL - you could just join the category names with an inline view of your orders table (grouped) to pull all attributes in a single query. Beats running two separate queries.

So whether it's developed as one or two queries - how would a sql generator build that last query? And if it can't - do you generate 90% of your queries, and then do just 10% by hand. Does that sound useful?

Don't go to a law school to learn programming

[cparisi]

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

This probably says more about the poor teaching than the Java language itself.

Phil's not a troll

[abe ferlman]

You want to know what I really think happened?

Someone at Harvard wanted to load test their server configuration, so they turned to Phil and said "can you post some flame bait and then get it posted to Slashdot for us?"

So you see he's not a troll, just a resourceful engineer :)

Don't forget XML.

[Mybrid]

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.

Re:Wahhh !!!

[StillNeedMoreCoffee]

Well it is a matter of when compilations occurs. In C it has to happen all at once before you ever use it. With Java which is a much more dynamic language by design and with the new JIT compilers, compilation of the byte code (which you could think of as object code in the C envirionment) is turned into machine code segments that are cached by the JVM and run from there. This means that there is a little startup time for that delayed compilation but then the code runs close to C speeds. But then if you don't need to complile everything you don't.

There is some overhead due to the dynamic message passing, but then you have that in C++ as well and is something that would slow both languages down compared to C. The expressibility and re-usablility of the OOPS paragim means that design, and maintenance can be much better with Java than a C program over the entire life a a project for a great savings in time and money for everyone concerned.

Re:Programming lehttp://developers.slashdosson 101

[kpharmer]

> 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.

ACL2

[Animats]

Wow, somebody's still using that thing. 20 years ago I headed a group to develop a proof-of-correctness system that used the original Boyer-Moore theorem prover, along with a Nelson-Oppen type prover. (See "Practical Program Verification" in POPL '83) "ACL" stands for "A Computational Logic". Boyer and Moore went to considerable trouble to formalize mathematics in a completely constructive form, with a theorem prover to prove the theorems. It can build up number theory from something close to the Peano axioms in a few minutes.

It's a very elegant formalization. There's no "forall" or "exists", which eliminates many philosophical tangles. Induction is done by recursion, and you have to prove that the recursion terminates by showing that a nonnegative integer metric decreases on each recursion.

Years later, after object oriented programming came out, it became clear to me how to merge Boyer-Moore theory with object theory. Boyer-Moore theory doesn't have "hiding", and it needs it. Shells should have private and public functions, and if an object cannot be distinguished via the public functions, it should be considered equal for proofs that use only the public functions. This allows fixing up the mess with constructive set theory without adding more axioms.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Type checking and javac-ing

[metamatic]

Java has lots of type-checking, etc. that's usually unnecessary for my simple reporting/collection of database data.

Thanks, I needed a good chuckle. I look forward to reading about your projects in future issues of RISKS digest.

Plus imho Tomcat is a pain in the ass to configure, and you gotta keep javac'ing, and so on.

Yes, Tomcat sucks. Use JBoss. (Or even JBoss with tomcat pre-embedded.) Also, learn how to use Ant. I type three letters and hit return and the system works out all the dependencies, compiles any files necessary, syntax-checks XML descriptors, bundles everything into jar, war and ear files as appropriate (building the jar descriptors for me), and deploys the final single archive file onto my web server. Then it prints out the URL to click to test the result, in case I've forgotten it.

C programming is kind of a bitch if you don't use make, too.

Lisp zealots = Holocaust deniers

[pgreenspun]

Thanks, guys, for giving the Sun E450 (philip.greenspun.com shares that 5-year-old machine with photo.net) and Harvard's little blog server a workout.

Don't assume from my posting that I'm in any personal hurry to learn VB and PHP! But having so many bright young people in 6.171 gives one a fun opportunity to take a high-level look at the programming tools of the moment.

What would I personally prefer to use? The same thing that I would have wanted to use 10 years ago: Common Lisp, CLOS, plus an ML-like type inferencing compiler/error checker. I find this preference, shameful, however, and try to keep it concealed from young people.

Just yesterday I ran into a friend. She's a 23-year-old graduate student in computer science at Harvard. Conversation rolled around to programming tools. Unprompted she said "What I think would be best is Common Lisp Object Systemw with a modern type system". I was stunned. I thought it was only dinosaurs like me that clung to Lisp.

I had a second ephiphany for the week... Believing that Lisp circa 1982 plus some mid-1980s ML tricks thrown in is better than all of the new programming tools (C#, Java) that have been built since then is sort of like being a Holocaust denier.

Re:Look what it's competeing against.

[drakaan]

This is because a web crawler isn't very computationally intensive. You're probably be waiting for I/O most of the time. It's because of this, and not because it's "long-running", that the performances are comparable.

Not really. Write a few text parsers in Perl and Java and you'll see that the "computationally intensive" advantage for Java doesn't exist. Different languages are there for several reasons:

• Programming style
• purpose
• ease-of-use
• cost

Java is cheap (free), multipurpose, and difficult to learn to use well, but suitable for large applications.

Perl is cheap (free), multipurpose, and easy to learn to use, but difficult to create large, maintainable apps with (subject to change with Perl 6?)

As far as how a program performs, unless you're doing a lot of FP math, most small programs of similar function written by programmers of similar skill in a given language will be fairly even, performance-wise.

If you *are* doing a lot of FP math, you're probably using FORTRAN, and nobody really understands FORTRAN, anyway...do they?

Re:Look what it's competeing against.

[Mad Marlin]

C/C++ can be used to make web pages (like CGI) but I wouldn't use it for that purpose. Too much trouble, difficult to program, to debug and to secure.

Actually it isn't that hard. At my last job I wrote all of my programs in C, including CGI's. I normally would use Python for CGI's, but the other people there only knew C++ and Perl. I don't like Perl, and didn't want to program in it again, so I wrote it all in C, since then all I really needed to explain was printf().

If you actually understand how to use pointers, it is easy. But then, that is generally true for C in general. The only reason why people generally have trouble with C is because they don't really understand how to use pointers, and you can't easily write anything at all in C without them, except for useless crap that could be done in GW-BASIC. The only real security issue with C (that isn't inherent to all CGI's, whether in C or Python or Perl) are things like buffer overflows, which again is just a need to better understand how to use pointers.

Who is this Philip Greenspun?

[tungwaiyip]

Why do we care about his opinion? Did he build any large scale scalable web application? Was he involved in maintaining and supporting any commerical projects? Did he make any critical insight of the strength and weakness of these development tools? Sounds like he draw his conclusion mostly from some student project. In that case I would say Microsoft wins hands down. Microsoft is very good at making and packaging complete development tools and is relative easy for novice to learn and use. Does it make VB the best programming language over other alternatives? I won't make that conclusion.

Funny that he claim a project done in Java would be harder to maintain that PHP or Perl. Some example of his opinion with little fact to support.

FYI: Python is not weakly typed.

[rk]

In fact, one could make an argument that it is more strongly typed than Java.

Python, however, is dynamically typed. It has its advantages and disadvantages with a statically typed language such as Java.

There are good arguments for using a dynamically typed language in conjunction with doing unit testing which serves to demonstrate program correctness, rather than mere syntactical correctness. Relying on your compiler to save you from a stupid moment (and let's be honest, we all have them) can get you burnt just as easily.

With that said, a strong static typed language does relieve you from many simple coding mistakes, but you should be unit testing in a large system anyway. Let's be hnoest: those sorts of bugs are the easiest to fix in a complicated system. Much more difficult is finding and removing flaws in encoded business logic. No compiler or code analyzer is going to help you there. Unit tests will.

Partisan bickering about typing mechanisms doesn't address the larger issues of software validation and correctness.

Re:Look what it's competeing against.

[cakoose]

Java is cheap (free), multipurpose, and difficult to learn to use well, but suitable for large applications.

Perl is cheap (free), multipurpose, and easy to learn to use, but difficult to create large, maintainable apps with (subject to change with Perl 6?)

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.

As far as how a program performs, unless you're doing a lot of FP math, most small programs of similar function written by programmers of similar skill in a given language will be fairly even, performance-wise.

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.

tcl!

[figa]

Did you notice how Greenspun snuck tcl in there:

With a dynamic language such as Lisp, PHP, Perl, Tcl, ...

After all these years, he's still miffed that tcl was displaced by Java in his AOLServer. I noticed that none of his students were using tcl either, which must have displeased him greatly.

Binding variables are trivial in Java if you prepare a statement. Here's what Greenspun himself has to say about it:

Note that JDBC, the Java database connectivity library, uses "?" as a bind variable. It is up to the programmer to count the Nth occurence of the ? in a SQL string and bind a value to that. As you can imagine this process becomes error-prone if the SQL statement contains 15 or more variables, a very common situation in real applications. You can also imagine the possibilities for introducing subtle bugs if the SQL query is changed and the bind variable sequence numbers are not properly updated.

So what he's saying then, is that his students are having a hard time counting!

JSP sucks?

[Bodrius]

It would be more accurate to say that it did suck a lot.

JSP was a copy of ASP, created to keep Java as "the web language" and stop the VBScript insanity.

Of course, in the process it copied most of the insanity in ASP, moved a lot of ASP developers with bad habits to JSP, and trained a lot of Java developers into the really bad habits of that type of development.

However, to the merit of JSP, the Java zealots were the first ones to try to fix the mess:

After the first batch of books advocating bad practices, it became common advocated wisdom that application code belongs in Beans and Servlets, and JSPs should be dealt with as cleaner, glorified print-out statements.

Obsessive use of JavaBeans and extensible, Custom Tag Libraries can easily remove most, and often all, of the need for Java code from any JSP application. It looks and feels more like Coldfusion development, which is very nice for HTML interfaces.

And now the Expression Language is essentially a template engine with a scripting language that is not very different from Freemaker et al. The main advantage I see on this is to let you deal with Java code in JSPs not as an aesthetic preference, but as a capital sin (validate the code and refuse anything that has <% or %>).

Now ASP.NET copied most of the improvements and added a few of its own. And the same people who hated ASP find it very appealing now in its new shape.

Perhaps you still would prefer your own TemplateEngine+Servlets combination, perhaps not. But the hacks have changed a lot. They might be worth revisiting.

Misusing J2EE

[dewdrops]

With all due respect, Greenspun's students don't know what they're doing and Greenspun's as clueless about J2EE development as they are (and his ignorance has cost them much extra development time). He writes:

[JSP] still seems to be too complex for seniors and graduate students in the MIT computer science program, despite the fact that they all had at least one semester of Java experience in 6.170.

First off, I bet 6.170 never covered JSPs, so the students are newbies to this and having to pick it up.

Secondly, JSP is for building the presentation layer only and should contain only custom tags and no business logic. As any J2EE developer knows, business logic should be kept in Java and exposed to JSPs via custom tags and servlets. Trying to do it all in JSPs is asking for trouble (as his poor students have found).

I think before he makes any more grand statements about J2EE, Greenspun should learn how to use it.

I've never used websphere but

[TheLastUser]

I have been running a multi server site with resin for a few years now. I haven't seen any of the versioning issues that you mention, even when I converted from Apache/JServ jdk1.1 to resin jdk 1.3.

I do think that the full 3 tier setup is probably a pain in the ass. Maybe a lot of people are resorting to this complexity without reason.

Moving to a war deployment was the best thing we ever did. We have an ant script that checks out the entire web app from cvs, tags the tree, compiles the app, tests and deploys the war to our staging server.

I have found that Java web apps can be more fragile than say perl/CGI so you have to take care , but the advantages for complex sites outweigh the problems.

Re:Programming lehttp://developers.slashdosson 101

[wasabii]

myCategory.getOrders().size();
myCategory.getRequ ests().size();
myCategory.getCriticalOrders().siz e();
myCategory.getCriticalRequests().size();
my Category.getOrdersByState(state);

Or various other ways. The idea is to map the logical functions into the object model so that the code does not have to be concerned with the underlying data model.

getOrders() returns an object that implements List. size() runs a COUNT query. .get() runs a select. This can be lazily cached very very easily (most object persistance frameworks support caching and lazy objects).

This instantly allows the object model to fit into your existing programming methods. This means that getOrder() returns a real Java list, just one that happens to transparent run SQL queries on access. It would have all the common functions a List does, size(), iterator(), etc. Depending on the type of relationship.

Yes, this is overhead. However, it's amazing how fast it actually does perform, thanks to intellegent caching which you do not get for free writing raw SQL statements. Caching of course depends on your implemention. Would be hard to cache if you were running a cluster of boxes. You get the point.

Part of your mapping defination is weither or not the getOrders() list should fill on creation of the category, or weither it should fill on access, or weither it should fill in blocks of 10 or 20.

Re:Java = training wheels

[ttfkam]

Uh hunh. And how many buffer overflow errors have you seen in Java apps? Not just failures. Bugs that open up holes to the server.

So how many of your apps have been security audited?

Read securityfocus.com and BugTraq for a month and then try tellig me with a straight face that a whole hell of a lot of C and C++ coders need training wheels.

Java and other languages (especially scripting languages) are getting faster and smaller in memory footprint quicker than C programs are reducing the number of security related bugs.

Use the right tool for the job and, more often than not, C is not the right tool.

Re:Swiss Knife, Eh?

[Directrix1]

Cool. Show me (in C, no libraries allowed), how to retrieve the free space on a hard drive partition. Let's say the C app is running under Windows 2000, just to make it more specific. You know at some point java does have to bind to native methods. JNI is necessary at some point because this is a Virtual Machine. Also, in all the programs I've written, I haven't had a single problem with a user needing to look at the free disk space in their program (albeit, I haven't written any installers, jars rule all). Sure it can be kind of neat and all to see a number, but Exceptions work wonders. Although, I do agree, a Disk class or something similar would seem pretty logical.