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."
"If I do not want others to quote me, I do not speak." -- Phil Wayne
JAVA is the suv? (Score:4, Insightful)
Programming lesson 101 (Score:4, Insightful)
Re:JAVA is the suv? (Score:1, Insightful)
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....
Complex programming (Score:4, Insightful)
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)
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
its a bad comparison (Score:2, Insightful)
come on people hwo small is the java vm in phones.. java programs at 30-60 k in totla..an SUV?
Now MS NET that is an SUV!!!!
Re:Too much formalism (Score:5, Insightful)
Re:JAVA is the suv? (Score:4, Insightful)
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. [jelovic.com]
Re:Finally (Score:5, Insightful)
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:JAVA is the suv? (Score:2, Insightful)
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.
Ah, I see you've come to the same conclusion yourself...
Re:Worst analogy ever (Score:1, Insightful)
Next stop, Flash is the Volkswagon Beetle, cute on the outside, trouble on the inside.
Java is to Visual Basic is to.... (Score:2, Insightful)
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:Agreed! (Score:5, Insightful)
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:Make Java Open Source! (Score:4, Insightful)
You mean like Kaffe [kaffe.org]?
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)
Ummm... RTFA? (Score:5, Insightful)
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)
Modern PCs are more like SUVs (Score:3, Insightful)
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)
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 (Score:2, Insightful)
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.
Re:Programming lesson 101 (Score:2, Insightful)
I agree though, short of a mapper tool, you're gonna have to have SQL SOMEWHERE.
I think everyone is missing the point... (Score:5, Insightful)
Java is like Windows XP, can anybody say bloatware (Score:5, Insightful)
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)
"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)
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:Whatever dude. (Score:5, Insightful)
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++.
Warning: Knucklehead (Score:3, Insightful)
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:JAVA is the suv? (Score:5, Insightful)
Re:Programming lesson 101 (Score:5, Insightful)
Write your code and STFU (Score:2, Insightful)
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.
Re:JAVA is the suv? (Score:3, Insightful)
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
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
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...
Java includes all the libraries/C/C++ use Unixs (Score:4, Insightful)
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.
Re:Obligatory: ... then C++... (Score:5, Insightful)
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:Programming lesson 101 (Score:5, Insightful)
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)
ASP would randomly write some data into weird places, and put up a pretty page telling the world that it had a problem...
PHP would just return a plain, white page saying, "PHP: Warning: could not un-recut in
and Java would call 911 for you.
Right tool, right job. If you don't need complete production stability for a moderate webapp with a short lifetime, by all means use PHP. For a production control system, I'd pick Java.
-Richard
Re:Finally (Score:3, Insightful)
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:JAVA is the suv? (Score:3, Insightful)
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:Finally (Score:1, Insightful)
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)
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)
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-
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 [apache.org] is free. Eclipse [eclipse.org] is free. You can pull down an SDK from Sun [sun.com] 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 (Score:2, Insightful)
Its always a bug waiting to happen
I used to think Greenspun was a pompous ass (Score:5, Insightful)
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:Warning: Knucklehead (Score:2, Insightful)
Java has issues, but not the ones mentioned here (Score:5, Insightful)
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.
Too bad I can't actually read the thing... (Score:1, Insightful)
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.
Re:JAVA is the suv? (Score:3, Insightful)
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:its a bad comparison (Score:2, Insightful)
JSP is OK (Score:4, Insightful)
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:My Java Problem. (Score:3, Insightful)
Re:Discredited (Score:5, Insightful)
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:Because, prudence (Score:4, Insightful)
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:so I guess that would make C# the.... (Score:1, Insightful)
Re:Whatever dude. (Score:3, Insightful)
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.
Re:Programming lehttp://developers.slashdosson 101 (Score:2, Insightful)
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)
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:I used to think Greenspun was a pompous ass (Score:2, Insightful)
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)
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.
Re:Programming lesson 101 (Score:2, Insightful)
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)
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)
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:Programming lehttp://developers.slashdosson 101 (Score:4, Insightful)
> 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.
Re:Programming lesson 101 (Score:5, Insightful)
Re:JAVA is the suv? (Score:2, Insightful)
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)
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)
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:
Re:Look what it's competeing against. (Score:2, Insightful)
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:
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. (Score:3, Insightful)
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.
Re:JAVA is the suv? (Score:2, Insightful)
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? (Score:2, Insightful)
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.)
Who is this Philip Greenspun? (Score:2, Insightful)
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. (Score:2, Insightful)
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. (Score:3, Insightful)
First of all, your "easy to learn" comparison is asymmetric: you didn't include the term "well" in the Perl version. Secondly, I, personally, think that Java is easier to learn than Perl. I also don't think I'm the only one who thinks so.
Though I'm not sure what you mean by "small programs", but the "Great Computer Language Shootout" [bagley.org] suggests a high amount of variation between languages (language implementations, actually) for very small programs.
tcl! (Score:2, Insightful)
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)
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.
Re:Programming lesson 101 (Score:3, Insightful)
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 (Score:1, Insightful)
Misusing J2EE (Score:2, Insightful)
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.
Re:Programming lesson 101 (Score:3, Insightful)
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.
Re:Java = training wheels (Score:3, Insightful)
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.