On Mar 31, 2005, at 10:25 AM, Gabriel Sechan wrote:
Everything can start using Java when you start buying my hardware for me.
And I'll listen to your language opinion when you start contributing code to any project that I'm on.
Java is still, and likely will always be, a CPU and memory hog. Moore's law be damned- *my* hardware doesn't get any quicker every year.
First: I don't find it to be a CPU hog. Even running a JOrbis decoder at 320kbps seems to use about the same kind of CPU as iTunes.
Second: I don't find it substantially larger memorywise than any other application. Perhaps I'm not looking at it terribly critically when my window manager (KDE or Gnome) seems to soak up a significant fraction of 100 Megabytes, anyhow. However, I might concede this. The fact that it is becoming the de facto standard on cellular phones seems to argue against this statement, however.
Third: tough. Spending 5% of scarce open source programming time (and the jump from C to Java is probably more than 5% savings) to support someone who won't spend $200 probably not a good trade.
As for the STL- there's a reason people don't use it. Its not easy to write, and even worse to maintain. It falls in under the realm of too clever. You can do a lot of work with it in very few lines of code, but its very difficult to understand or debug those lines. Its better to avoid using it and write more lines but end up with a clearer program. I personally tend to use C over C++ due to seeing way too many bad OO designs that decided they needed to use way too much inheretance and far too many classes because "its OOP".
STL is orthogonal to OOP. Bad OO is not limited to C++. It has only been in the past 5 years that people have figured out that deep inheritance *in any language* is bad.
However, I find the STL *always* better than anything written by hand. Hand written lines may be "clearer" (which I would dispute) but are always *buggier*. STL usage never has fencepost errors, null pointer errors, casting problems, etc. That is, in fact, the stick I normally beat people with to get them to use the STL when I get called in to look at a bug: "Gee, you can spend a couple hours looking for the bug in your custom rolled routine, or you can spend 30 minutes using the STL idiom for that--almost all of that 30 minutes spent learning. Your call." The ones who choose the STL generally finish up and move on within 30 minutes; the rest normally take longer than that and still wind up with another bug later. After that, STL usage is self-reinforcing.
To throw in my experience, the only language which gets even *remotely* close to being cross platform portable from a multimedia standpoint is Java. There is a reason why everybody uses Macromedia Director to ship multimedia apps on the web; all the other solutions suck (including Java, but Java is least bad)
Umm, you use a multimedia multiplatform library, and it all magicly works on whatever platform. Platform portability is a laughable argument- thats what libraries are for. You put the paltform differences in the library. There's good, multiplatform multimedia libraries out there for just about any language under the sun.
You miss the point. Java and Director are *already installed* on 99% of the computers that people want to generate applications for.
We've been through this argument; opens sourcers still don't get it. The user experience extends from initial web page button click ("Hey, that might be cool!") to quit. "Well, you just have to install ..." flunks Step 1. Look at the number of people who refuse to develop for .Net simply because of "Well, you just have to install ..."
Bleh, dear god no. Java is bloated enough. Having everything under the sun part of the standard library and distribution is not a good thing. WHen you do that you get subpar libraries with lots of silly dependancies and ugly design.... sorta like Java's standard library.
I dispute that. The Java standard library has been reasonable in most places and actively good in others. Its support for threads is actively good. The stream I/O library is a bit verbose, but is also good. Yeah, it has its warts (Date, anyone? Yecch!), but I find your opinions suspect without further concrete evidence.
What I call "convenience", you call "bloat". This holds irrespective of library, language, or application. Taken a look at a "convenience" install of Python or Perl. Or, better yet, lets put you on a "real" Unix system and see how many libraries you have to suck in to use your favorite applications.
The only difference is that we gave C bloat a name--Linux.
-a
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
