| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Hacks
Hacks
Posted Oct 20, 2005 22:01 UTC (Thu) by ncm (subscriber, #165)Parent article: Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)
It doesn't take much insight to predict the demise of Java fads: they're all doomed, every one. Tate's skill has been in discerning precisely when each one's number is up.
Abandoning type-safety for wild and woolly runtime-typed languages is a familiar pattern among language pundits. Before Bruce Tate went Bruce Eckel. In the toy programs used for teaching, any extra apparatus that only promises to ease maintenance is worse than useless. Such apparatus in Java programs is anyway far too weak to justify its finicky bulk.
Java's designers positively delighted in bolting on elaborate, obligatory apparatus, with a nod to intended function but with most actual usefulness trimmed away. Thus, use of Java exceptions makes code bigger and more complex, and its pervasive object orientation couples programs' components even more tightly. Java 1.5's "generics" relieve the worst demands for pervasive casting, but add no actual power. It's easy to compare almost any language favorably to Java (or, equivalently, to C#).
To build convenience and (immediate) power into a scripting language is easy when performance cost is no object. For a little program, any language will do. A big program needs linguistic structures to help organize it, and it needs to be able to rest most of its weight on those structures. Java has given structural features a bad name because those it provides are too weak to be useful.
The real measure of a language, and of a design philosophy, is not how quickly you can whip up another variation on a theme in one domain. Rather, it's how well it enables its users to package up conveniences and power tools so they may be composed and integrated into systems that haven't been built a thousand times before. Standard C++, for all its historical baggage, is still the only language that even addresses the problem. A well-crafted C++ library can equal the convenience and (immediate) power of a scripting language without sacrificing performance or maintainability.
Someday we will get a language that matches C++'s constructive power and efficiency, without its history or its ponderous build cycle. None has topped the horizon yet, and C++0x will raise the bar higher. In the meantime, we will see thousands of non-standard, barely portable, quick interpreted hacks that, while they do the job, cannot be fitted cleanly into a larger system, or used again even five years later.
(Log in to post comments)
Hacks
Posted Oct 20, 2005 23:33 UTC (Thu) by bronson (subscriber, #4806) [Link]
Java's designers positively delighted in bolting on elaborate, obligatory apparatus, with a nod to intended function but with most actual usefulness trimmed away.That is the single best description of Java I have ever heard.
Hacks
Posted Oct 21, 2005 1:02 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link]
I prefer to think of Java as not so much "object-oriented" as "object-obsessed". I mean, why does a string have to be an object rather than a data type? Personally, I prefer writing Bash scripts to Java.
As far as I can understand, the "big deal" about Java is platform independence. Except that is isn't really. And if you have an open-source application, who cares about compatibility of *binaries*.
Hacks
Posted Oct 21, 2005 3:41 UTC (Fri) by mdaniel (guest, #33232) [Link]
As far as I can understand, the "big deal" about Java is platform independence. Except that is isn't really. And if you have an open-source application, who cares about compatibility of *binaries*.
The "big deal" about Java's "platform independence" is the common "processor" and libraries against which you code. You think OpenSource cured the notion of compatibility? Tell that to the autotools folks, who have built an empire stringing m4 macros and shell together to determine what kind of strcat you have on your flavor of *nix.
The funny thing is that I'm not a Java zealot; I agree with the ancestor's comment that Java is bloated and exceeeeeeeedingly verbose. That does not, however, compromise that Java provides a common vocabulary (I mean that in terms of the language and especially the libraries) for some of the most powerful and maintainable server-side software I've ever encountered.
Hacks
Posted Oct 21, 2005 8:05 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]
Java was intended to be a language for developing client-side code. Perhaps part of the mis-fit we see is because its main occupation today is converse to the one for which it was designed.Bruce
Hacks
Posted Oct 21, 2005 15:12 UTC (Fri) by mdaniel (guest, #33232) [Link]
Java was intended to be a language for developing client-side code. Perhaps part of the mis-fit we see is because its main occupation today is converse to the one for which it was designed.
With all due respect, something like Jini is what Java was intended to do: network-transparent, device-independent, "roaming" code [think of your fridge telling your PDA that you're out of bread]. The fact that people used it for dancing monkeys when it first came out doesn't make James Gosling any happier than it makes you or I.
And I just said it's verbose, not that it's poor at doing its job. It enables a lot of strong software engineering practices very well. I use this example with my cow-orkers a lot: you have ten seconds to tell me what file contains the class com.foo.CoolClass. Where would you look? How would you solve the same problem in C++?
Hacks
Posted Oct 21, 2005 15:24 UTC (Fri) by doodaddy (guest, #10649) [Link]
"As far as I can understand, the "big deal" about Java is platform independence."
I have several Java coding friends and I've read a book on it twice (but had no need for it). I don't think platform independence matters now. Its a good seller up front, but I haven't heard anyone claim how nice it was to port from Sun to Windows or the like.
The biggest seller, at least by listening to the comments, is "no pointers." While they are there and ready to cause trouble, atleast there are no memory leaks (at least theoretically.) I think this is important because the coders I know that use Java did NOT make computer science a calling. They fell into it and it pays well. And it must be comforting to have a language that you can get hired using, for big bucks, without any deep knowledge of "scary things."
I think the next big seller is momentum. There are more jobs in Java (again, high-paid jobs) than in C++, for instance. Notice that almost all of them are IT projects at both big companies and start-ups. Most of which fail. But who cares about that? I think the failure rate is tied to lack of deeper understanding about software engineerings in general in this knee-jerk Java shops.
Then the next big seller is a forced, huge library. (Another friend always said that what people really want in a government is a benevolent dictator.) Java says that its libraries are complete, required, and beautiful. Many are fine, some are long winded. (There are some definite "collegiate"-type projects-turned-library in there, such as the io stream stuff.) But there is something to say for knowing which toolkit to memorize! You can't really say that C/C++ has a definite thread library, less alone an HTTP or XML library that is official. (Please avoid thinking about Java's GUI toolkit which has about 3 "official" versions.)
And finally, I agree that we have not just an "object obsessed" language (I like that name by the way), but an object obsessed programming culture!
Hacks
Posted Oct 28, 2005 3:05 UTC (Fri) by ttfkam (subscriber, #29791) [Link]
"...but I haven't heard anyone claim how nice it was to port from Sun to Windows or the like."
Most likely because the "port" only involved invoking the JVM on a different system. 99.9% of all programs, as long as they don't use native code, require little or no code changes at all. I know mine haven't. Talk to servlet and J2EE developers as to whether it matters to them what system their code runs on.
Not having (explicit) pointers is definitely a selling point. The C++ standard library is definitely an improvement, don't get me wrong, but the memory leaks and buffer overflows reported by SANS and CERT are a testament to the fact that it's not enough.
As for education, I know far more than a few C programmers that never took the CS/CE path. Hell, I've met more than a handful of CS graduates who can't code well at all. CS is an applied mathematics degree, not a programming degree.
Moving on, the "huge" standard library is indeed big, sure. I, for one, am glad of it. Where is the uniform API for XML and XSLT in C++ so that you can swap out implementations without having to refactor your whole project? JDBC long ago outstripped ODBC in the ease of use department. And it's not like bare CORBA is a fair match with a full, clustering J2EE suite. Are there warts? Sure. AWT/Swing comes to mind. The original I/O library was a big weak. However, having a single, easy to reference and use API for TCP/IP and data I/O should not be ignored.
Java wasn't popular because its APIs were perfect. It was popular because the better alternatives to many of its APIs were harder to use, more error-prone, or simply nonexistant.
Java didn't invent the automatic documentation from code generator Javadoc. That concept had been around for a while. But you must be blind if you didn't notice that the practice became commonplace after Java did it. You probably balk at the size of the API library represented at the following URL: http://java.sun.com/j2se/1.5.0/docs/api/
Me? I balk at those languages that lack it.
Hacks
Posted Oct 21, 2005 8:14 UTC (Fri) by micampe (guest, #4384) [Link]
This Java bashing is getting very very boring.
Hack Hackity Hack Hack
Posted Oct 21, 2005 16:51 UTC (Fri) by GreyWizard (subscriber, #1026) [Link]
This Java bashing bashing is getting very boring. Let's post opinions about the discussion itself without addressing the substantive issues at all. That'll liven things up.
Hacks
Posted Oct 21, 2005 15:26 UTC (Fri) by doodaddy (guest, #10649) [Link]
"Someday we will get a language that matches C++'s constructive power and efficiency, without its history or its ponderous build cycle."
Have you ever looked at D? (digitalmars.com/d/comparison.html) My opinion is still open, but they seem very serious. The newsgroups at the site go into pretty heavy detail picking over each feature.
Hacks
Posted Oct 21, 2005 17:34 UTC (Fri) by daledude (guest, #31448) [Link]
I like D. Im not comfortable using it for anything serious is production yet. I would love to see more momentum behind it. It seems like a great middle between C++ and Java.
Hacks
Posted Oct 21, 2005 23:59 UTC (Fri) by ncm (subscriber, #165) [Link]
A "middle between C++ and Java" is a step backwards. D offers some coding conveniences, but it also adopts some of the worst qualities of Java, and, worse, lacks precisely those features that make C++ uniquely useful.
Hacks
Posted Oct 23, 2005 22:41 UTC (Sun) by doodaddy (guest, #10649) [Link]
Can you be specific? It has gc, which you can start now, or turn off for a while. I think I remember you can work without it. It has "layovers" in the form of structs (while 'class' is more like Java.) It has arrays built in (not a class) with "slices." ...
It has been winning in coding shoot outs for speed, I think due to the slices.
I'm always ready to hear some interesting insights to these things as I fancy myself working on languages some day.
P.S. My last job was in C (with some C++) for a 4 million line code base. I finally see some of the light of Java (though I'm still bothered by it). With 20 years and new front lines of coders, the code was very good and yet... impossible to work with. So many programming paradigms, so many utility libraries, so much cross-platofrm ifdef and libraries, so many different ways to use it. So much control of errors, memory, everything. SO MANY "help" MACROS! Ugh! You could stare at a function and have no idea what it was doing. My point is that I can see why Java wanted to remove control of allocation issues, force libraries to be named the same as files and force a hierarchy of library files. Also, I can see why Java tries to have a standard set of cross-platform libraries and remove macros. To keep this on topic a bit, it seems "big systems" do hang themselves with some of these control structures and removing them might be the way to better real-world code.
Hacks
Posted Oct 22, 2005 5:36 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
Good post, some comments:
>> For a little program, any language will do
Well said. I might add that in the case of "small" problems (and more problems are "small" than most people think), other issues, such as using the same language as your coworkers (as long as it is relatively appropriate) often outweigh a pure qualitative assessment.
>> Standard C++, for all its historical baggage, is still the only language
>> that even addresses the problem. A well-crafted C++ library can equal the
>> convenience and (immediate) power of a scripting language without
>> sacrificing performance or maintainability.
...and there are a lot of those libraries. C++ continues to be the language of "choice" for many large apps not just because of performance (I find the perfrommance of PyGtk apps or Eclipse, Jedit etc etc decent in most cases), but because
1. the language is stable,
2. is guided by standards,
3. has one dominant open implementation in gcc/g++ (even if this dominant implementation supports historically non-standard syntax).
I would argue that Java fails (1) as new features and libraries seemed to be tacked on endlessly as the marketing team attempts to repurpose the tool for a new audience (remember the Jini push?)
Clearly Java fails (2), although I don't think an ISO standard is that much of a big deal, not nearly as big a deal as (3). Look at perl or python...do you ever hear about compatibility issues across platforms? Never. This is because they are all addressing one runtime. In the Java world there will always be fragmentation because there will always be coders who will not accept a closed JRE.