Please create an account to participate in the Slashdot moderation system


Forgot your password?
Java Programming IT Technology

Phillip Greenspun: Java == SUV 974

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."
This discussion has been archived. No new comments can be posted.

Phillip Greenspun: Java == SUV

Comments Filter:
  • JAVA is the suv? (Score:4, Insightful)

    by 192939495969798999 ( 58312 ) <info@de v i n m o o r> on Monday September 22, 2003 @08:46AM (#7023514) Homepage Journal
    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.
  • by 192939495969798999 ( 58312 ) <info@de v i n m o o r> on Monday September 22, 2003 @08:50AM (#7023543) Homepage Journal
    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.
  • by Anonymous Coward on Monday September 22, 2003 @08:52AM (#7023562)
    >Java is the developers' programming language?

    Oh please. Thats ridiculous. Pick the correct tool for the job. At least C++/vi kept out the VBA-like coders from infecting too many systems, lowering the entry barrier and making it easier is not always a good thing....
  • by BWJones ( 18351 ) on Monday September 22, 2003 @08:52AM (#7023566) Homepage Journal
    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. (Score:5, Insightful)

    by botzi ( 673768 ) on Monday September 22, 2003 @08:52AM (#7023567)
    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

  • by linuxislandsucks ( 461335 ) on Monday September 22, 2003 @08:55AM (#7023595) Homepage Journal
    Its a bad comparison from a non programmer..

    come on people hwo small is the java vm in phones.. java programs at 30-60 k in SUV?

    Now MS NET that is an SUV!!!!
  • by msgmonkey ( 599753 ) on Monday September 22, 2003 @08:56AM (#7023596)
    Bad programmers write bad programs regardless of the language.
  • by Anonymous Coward on Monday September 22, 2003 @08:57AM (#7023607)
    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:Finally (Score:5, Insightful)

    by gilgongo ( 57446 ) on Monday September 22, 2003 @08:59AM (#7023635) Homepage Journal
    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?

  • by aborchers ( 471342 ) on Monday September 22, 2003 @08:59AM (#7023636) Homepage Journal

    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...
  • by Anonymous Coward on Monday September 22, 2003 @09:03AM (#7023664)
    I dunno, SUV=Resource hog, slow, and bulky. Sounds accurate to me....

    Next stop, Flash is the Volkswagon Beetle, cute on the outside, trouble on the inside. :)
  • by Anonymous Coward on Monday September 22, 2003 @09:05AM (#7023681)
    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.

  • Re:Agreed! (Score:5, Insightful)

    by fshalor ( 133678 ) <> on Monday September 22, 2003 @09:05AM (#7023684) Homepage Journal
    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...
  • by jacksonyee ( 590218 ) on Monday September 22, 2003 @09:05AM (#7023691) Homepage

    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.

  • Re:Agreed! (Score:1, Insightful)

    by flu1d ( 664635 ) on Monday September 22, 2003 @09:06AM (#7023694) Homepage
    it pollutes the environment and wastes gas... and has a tendancy to roll over and crash more than any other vehicle.
  • Ummm... RTFA? (Score:5, Insightful)

    by sporkboy ( 22212 ) on Monday September 22, 2003 @09:06AM (#7023696) Homepage
    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.
  • Re:Finally (Score:5, Insightful)

    by Hard_Code ( 49548 ) on Monday September 22, 2003 @09:10AM (#7023724)
    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"
  • by Junks Jerzey ( 54586 ) on Monday September 22, 2003 @09:12AM (#7023740)
    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 (Score:3, Insightful)

    by Hard_Code ( 49548 ) on Monday September 22, 2003 @09:12AM (#7023749)
    "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. :(
  • by Powercntrl ( 458442 ) on Monday September 22, 2003 @09:13AM (#7023754)
    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.
  • by Pfhreakaz0id ( 82141 ) on Monday September 22, 2003 @09:14AM (#7023759)
    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.
  • by surfsalot ( 15319 ) <ramanujon&gmail,com> on Monday September 22, 2003 @09:14AM (#7023765) Homepage
    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.
  • by node159 ( 636992 ) on Monday September 22, 2003 @09:15AM (#7023775)
    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.
  • Discredited (Score:5, Insightful)

    by dnoyeb ( 547705 ) on Monday September 22, 2003 @09:18AM (#7023795) Homepage Journal
    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:Finally (Score:5, Insightful)

    by (trb001) ( 224998 ) on Monday September 22, 2003 @09:18AM (#7023796) Homepage
    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 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.

  • Re:Whatever dude. (Score:5, Insightful)

    by B'Trey ( 111263 ) on Monday September 22, 2003 @09:19AM (#7023803)
    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++.
  • by Get Behind the Mule ( 61986 ) on Monday September 22, 2003 @09:21AM (#7023820)
    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.
  • by Hard_Code ( 49548 ) on Monday September 22, 2003 @09:22AM (#7023833)
    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.
  • by I8TheWorm ( 645702 ) on Monday September 22, 2003 @09:25AM (#7023849) Journal
    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.
  • by Eisenfaust ( 231128 ) on Monday September 22, 2003 @09:31AM (#7023892) Homepage
    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.
  • by PowerPill ( 687850 ) on Monday September 22, 2003 @09:35AM (#7023923)
    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...
  • by acomj ( 20611 ) on Monday September 22, 2003 @09:41AM (#7023981) Homepage
    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.

  • by shamilton ( 619422 ) on Monday September 22, 2003 @09:42AM (#7023994)
    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.

  • by Ed Avis ( 5917 ) <> on Monday September 22, 2003 @09:42AM (#7024000) Homepage
    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:Thank You (Score:5, Insightful)

    by rjstanford ( 69735 ) on Monday September 22, 2003 @09:43AM (#7024015) Homepage Journal
    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.

  • Re:Finally (Score:3, Insightful)

    by cca93014 ( 466820 ) on Monday September 22, 2003 @09:44AM (#7024018) Homepage
    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.
  • by KDan ( 90353 ) on Monday September 22, 2003 @09:53AM (#7024098) Homepage
    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).

  • Re:Finally (Score:1, Insightful)

    by Anonymous Coward on Monday September 22, 2003 @09:53AM (#7024102)
    I should point out that the enterprise application I've seen (And the company I work for develops J2EE apps. I do systems integration work for them.) tend to have horrible scalability, despite application-level persistence and database pooling. I'm tempted to say "because of" but I won't.

    From personal experience there's nothing to indicate in the least that either of these 2 features inherently make the app more scalable. What seems to make apps more scalable is reasonable design. Not the tools you use to design it.
  • Re:Discredited (Score:2, Insightful)

    by RexRuther ( 221243 ) on Monday September 22, 2003 @09:53AM (#7024103) Homepage Journal
    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.
  • Grain of salt (Score:2, Insightful)

    by LDoggg_ ( 659725 ) on Monday September 22, 2003 @09:53AM (#7024108) Homepage
    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 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.
  • by evil_one666 ( 664331 ) on Monday September 22, 2003 @09:56AM (#7024129)
    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

  • by *weasel ( 174362 ) on Monday September 22, 2003 @09:59AM (#7024164)
    ... 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.
  • by dtrent ( 448055 ) on Monday September 22, 2003 @10:01AM (#7024180)
    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.
  • by Headius ( 5562 ) on Monday September 22, 2003 @10:09AM (#7024249) Homepage Journal
    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.
  • by Anonymous Coward on Monday September 22, 2003 @10:09AM (#7024251)
    due to the Slashdot effect. However, I would like to make a point of my own, in that Java is not the be-all and end-all of programming languages. It has its uses - and so does COBOL, like it or not. The problem is that too many programmers get good (or think they are good) in one language, and use that for everything - it's like a carpenter who only knows how to use a saw, not a hammer or screwdriver or plane...

    A lot of people here jump very quickly to defend Java, and the same people jump to slay Pascal or Ada. But each language has its purpose, and if you use it for that purpose, it shines like a diamond.

    I use Java - when I need some cross-platform web-based code or whatever. But if I'm running a quick script, I'll write it in Perl. If I'm doing some quick Windoze jobbie I'll write in VB. I use the correct tool for the job, rather than adapting the job to fit the tool. And if a few more of you stupid "college graduates" would learn to do that then just maybe the software industry wouldn't be quite so screwed up.

  • by Mr. Shiny And New ( 525071 ) on Monday September 22, 2003 @10:12AM (#7024271) Homepage Journal
    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.
  • by panurge ( 573432 ) on Monday September 22, 2003 @10:20AM (#7024345)
    In the past I've had to fire PhDs because they couldn't get the job done. PhDs tend to know a great deal about a very small subject - a very necessary thing in any difficult field, but it does tend to restrict their ability when it is necessary to have a big picture. And, unfortunately, good systems design needs a big picture appreciation. When it comes to assessing Java versus C++ versus the P languages, I'll listen to a guy who has developed a banking system or two, even if he never went near a university comp sci course.
  • JSP is OK (Score:4, Insightful)

    by Baki ( 72515 ) on Monday September 22, 2003 @10:28AM (#7024420)
    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).

  • by jjohnson ( 62583 ) on Monday September 22, 2003 @10:33AM (#7024465) Homepage
    Allow me to translate the parent: "Java sucks hairy donkey balls. Convince me otherwise."
  • Re:Discredited (Score:5, Insightful)

    by Pfhreakaz0id ( 82141 ) on Monday September 22, 2003 @10:47AM (#7024572)
    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.
  • by Ed Avis ( 5917 ) <> on Monday September 22, 2003 @10:49AM (#7024592) Homepage
    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.
  • by Anonymous Coward on Monday September 22, 2003 @10:50AM (#7024609)
    Oh, shut up. I'm guessing that you've never written a single line in C#. Frankly, .NET rocks, despite its Microsoft lineage.
  • Re:Whatever dude. (Score:3, Insightful)

    by yomahz ( 35486 ) on Monday September 22, 2003 @11:06AM (#7024752)
    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.
  • by kpharmer ( 452893 ) * on Monday September 22, 2003 @11:18AM (#7024862)
    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?
  • Re:Finally (Score:5, Insightful)

    by Moraelin ( 679338 ) on Monday September 22, 2003 @11:19AM (#7024874) Journal
    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.

  • 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:Agreed! (Score:2, Insightful)

    by Anonymous Coward on Monday September 22, 2003 @11:34AM (#7025008)
    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.
  • by shostiru ( 708862 ) on Monday September 22, 2003 @11:38AM (#7025041)
    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.

  • Don't forget XML. (Score:4, Insightful)

    by Mybrid ( 410232 ) on Monday September 22, 2003 @12:07PM (#7025320)
    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:Tcl is good (Score:2, Insightful)

    by GenSolo ( 444636 ) on Monday September 22, 2003 @12:20PM (#7025422)
    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.
  • by kpharmer ( 452893 ) * on Monday September 22, 2003 @12:44PM (#7025635)
    > 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.

  • by holzp ( 87423 ) on Monday September 22, 2003 @12:45PM (#7025647)
    you could also write your application to suck up huge amounts of memory and bandwitdh for no reason but buzzwords...
  • by StillNeedMoreCoffee ( 123989 ) on Monday September 22, 2003 @12:55PM (#7025738)
    "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's Cover (Score:3, Insightful)

    by KrispyKringle ( 672903 ) on Monday September 22, 2003 @01:03PM (#7025805)
    "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:Tcl is good (Score:3, Insightful)

    by Slime-dogg ( 120473 ) on Monday September 22, 2003 @02:14PM (#7026382) Journal

    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:

  • by drakaan ( 688386 ) on Monday September 22, 2003 @02:24PM (#7026476) Homepage Journal
    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, they?

  • by Mad Marlin ( 96929 ) <> on Monday September 22, 2003 @02:40PM (#7026617) Homepage
    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.

  • by ElGuapoGolf ( 600734 ) on Monday September 22, 2003 @02:47PM (#7026664) Homepage
    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.

  • by SoTuA ( 683507 ) on Monday September 22, 2003 @02:55PM (#7026714)
    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.)

  • by tungwaiyip ( 608795 ) on Monday September 22, 2003 @02:58PM (#7026767) Homepage
    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.

  • by rk ( 6314 ) on Monday September 22, 2003 @03:01PM (#7026795) Journal

    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.

  • by cakoose ( 460295 ) on Monday September 22, 2003 @03:14PM (#7026978) Homepage
    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! (Score:2, Insightful)

    by figa ( 25712 ) on Monday September 22, 2003 @03:26PM (#7027107) Journal
    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? (Score:3, Insightful)

    by Bodrius ( 191265 ) on Monday September 22, 2003 @03:47PM (#7027338) Homepage
    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.
  • by Dr. Bent ( 533421 ) <> on Monday September 22, 2003 @03:56PM (#7027471) Homepage
    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.
  • by Anonymous Coward on Monday September 22, 2003 @04:28PM (#7027776)
    Maybe you should spend less time worrying about your application being decompiled and allowing people to see your super secret database and instead spend time setting up proper rules that limit who can connection to which databases from which addresses etc. Do you really think I give a rat's ass if someone sees my database password when it doesn't even accept connections from anywhere besides a single IP address? And that IP address is on a private network?
  • Misusing J2EE (Score:2, Insightful)

    by dewdrops ( 79519 ) on Monday September 22, 2003 @04:52PM (#7028026) Homepage

    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.

  • by avdp ( 22065 ) * on Monday September 22, 2003 @06:39PM (#7028917)
    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.
  • by ttfkam ( 37064 ) on Monday September 22, 2003 @09:06PM (#7029946) Homepage Journal
    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 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.

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller