Java Bandwagon

you have switched to Java from some other language, and
you've done no OOP, OOD or OOA before and either don't see the point or can't be bothered.

For extra marks:

Those cute applets are the motivating force behind your choice to adopt java.

"I can write fortran in any language" - except this time it's Java.

Sure java has the potential to make good projects better, but you can't expect java to transform a bodge-job into a good project.

In short, Java is a great language, but there is a lot of hype and excitement from folks who don't understand WhyJavaIsGreat. Without understanding the whys involved, projects will lack meaningful direction and fail; faith will be lost; a tide of Java is stupid will rise.

There's no question that blind faith is bad, but how do you reason with people who are on the bandwagon?

[Substantial highly informed (LanguagePissingMatch) content moved to JavaVsCpp and JavaVsSmalltalk.]

For all of you on the JavaBandwagon and proponents of "Sun can do no wrong", you may want to read: http://www.internetwk.com/lead/lead010500-1.htm entitled "Licensees To Sun: Let Go Of Java Or We Will Walk." Notable quotes: Senior executives from IBM, Hewlett-Packard, Microsoft and other vendors are in secret negotiations to wrest control of the Java specification from Sun Microsystems.

According to sources involved in those discussions, the vendors are growing so impatient with Sun's half-hearted efforts to standardize Java that they're considering forming a special interest group that would establish an independent Java standard.

The group - which unites longtime Java enemies IBM and Microsoft - will first offer to work with Sun, the creator of Java, but is prepared to move forward without Sun's blessing, the sources said.

And this from IBM, Java's biggest backer: IBM, the largest Java developer, has made its displeasure known as Sun has reneged on plans to hand over Java to standards groups.

"IBM would like to see Sun live up to its commitments to standardize the language specification," said John Swainson, general manager for application and integration middleware at IBM.

In addition, IBM is unhappy with Sun's approach to licensing Java, despite Sun's lifting of royalties for applications that use Java 2 Standard Edition (J2SE), the core Java technology for PCs and workgroup servers.

For example, Sun continues to negotiate licensing/royalty terms for Java 2 Enterprise Edition (J2EE), used to create more complex multitier applications, and Java 2 Micro Edition (J2ME), used for applications in consumer electronics and embedded systems.

Several Java licensees argue that Sun should hand over the technology to an independent standards body, principally because the Java specs consist of intellectual property from multiple companies.

"Over 80 percent of the APIs [in J2EE] came from IBM," Swainson said. "Sun has taken the name J2EE and applied it as a brand, which they control. This is not a game we're going to play."

Sun's refusal to standardize Java is indicative of its true proprietary stance. -- sg

I now call Java "SmalltalkMinusMinus".

It is absolutely true that I am many times more productive when coding in Java than in C++. So what? In my experience, the productivity of any developer using C++ approaches zero (in the limit), and so virtually any tool is superior, including SAP, Excel, VisualBasic, C, Pascal, ObjectiveC, and a host of others. I therefore view the observation that Java is a better tool than C++, in most situations, tantamount to observing that the sun is likely to rise in the east tomorrow; true, but containing very little information.

I use Smalltalk because I can do with ease and robustness things I shudder to even contemplate in Java. Yes, of course much of the functionality is in the environment, instead of the language. That is the entire point! If it is in the language, then (like Java and C++) it becomes impossible to fix.

I have hard-copy of the Smalltalk-80 environment as it existed in 1985 or so. It contains better support for file I/O, sockets, TCP-IP packets, and process scheduling than anything I've seen since. I grant you that we have learned enough about UI since then that the GUI classes have an archaic, crinkly feel to them when read with 2000 eyes.

Let me offer this example: I just finished releasing a distributed application, written in VisualWorks 2.52 - from about 1995 - that is in daily use by hundreds of scientists. It is still in VW252 because 90% of our platforms are Mac's, and VisualWorks is the only Smalltalk that effectively supports the Mac. Our system supports Smalltalk clients running on Mac's, PC's, and multiple flavors of Unix.

Can someone please cite a similar application built from a competing platform? Which platform can support all three environments today? Which platform supported all three platforms five years ago? Which platform could, today, run code that easily coexists with code that is 3, 5, or in some cases 10 or 20 years old?

I agree we must choose the right tool for each job. I have found jobs for which Perl is the best tool (for me), others for which Excel is the best, and some for which C is a win. Since the inception of C++, I have not yet found a problem for which it was a better tool, for me, than Smalltalk. The same is true for Java.

While I agree with the sentiments about tool choice, my experience has been that usually this right-tool-for-the-right-job mantra is generally just a rationalization for I-like-what-I-like-and-leave-me-alone. By all of the methodology metrics I can think of, Smalltalk and Lisp have blown away the C++ family (including Java) for decades. I've also witnessed our technical community steadfastly ignore these results. So can we please give up the fiction that this is anything more than personal opinion? Except, of course, my own comments about the superiority of Smalltalk - these being merely descriptive statements of objective fact *smile*.

I also agree with RalphJohnson's observation that technical superiority has only coincidental relationship to market success. My SONY SL-5800 Betamax player, from 1979, still outperforms any VHS player available at any price if you care about slow-motion, still frame, variable-speed playback, tape wear, and image quality. So what? Sony lost the marketing war, and the Smalltalk community made the same mistakes 10 years later. The Macintosh, in 1984, was a more usable platform for a single user than a Win95 environment from 10 years later. The NexT platform was head and shoulders above its competition in technical quality, by virtually any measure. So what?

I believe that we are still in the birth-pangs of genuine computer science. Our children will find our arguments about C++, Java, and Smalltalk amusingly quaint. yes! - see SecondGenerationProgrammer

And I still think Java is SmalltalkMinusMinus.

-- TomStambaugh

Smalltalk's dead; move on. Productivity gains in Smalltalk are in your imagination. What good are productivity gains when you can only deploy it on a client. If you need a tool to write great software, then switch to VB. -- CarlParziale

While SmallTalk may or may not be dead, its ideas certainly aren't! Java advocates don't know what they're missing if they think it's in our imagination. Java's nice, C# is nicer, they are both slowly converging on Smalltalk's feature set. When both languages have a decent meta protocol, blocks/lexical closures, and first class functions then we'll be able to compare on a somewhat even footing. Until then... Smalltalk is still very useful on a day to day basis because it's not too hard to translate some of that great code into C syntax and use it in your own projects. Smalltalk is an inspiration to any OO programmer who takes the time to actually look at it. -- RamonLeon

Java is a language with C-like syntax (forget Smalltalk), powered by a garbage collector AND a hotspot compiler out-of-the-box (forget every other language), and includes a huge library of useful and relatively cross-platform functionality (forget C/C++ where you always have to hunt for various "engines" and integrate them by hand or roll your own).e

I think the bigest problem with Java is not the Language. It's fine for use user land apps. The problem is the idea of "write once, run anywhere." It's a great marketing idea and a subset of that is of limited use in web apps. The problem is that you end up with an app that has zero optimizations and affordances to the target environment. The latest mistake is all of the ports of java to PDAs (PalmOs), cell phones and the like. These environments REQUIRE native environment interfaces to have a quality user experances. Pouring a java UI on top of the existing UI makes limited platforms more limited. Java with a class framework tied to the target environment would be great. So would real compilers. A virtualized to the lowest common denominator makes a wreck out of an other wise productive language. -- ScottElliott

Java is an example of DoTheSimplestThingThatCouldPossiblyWork gone horribly wrong. The idea was to make an object-oriented language that was (a) safe, (b) felt like C++, and (c) object oriented, and then bundle it into massive do-everything library and VM. It does exactly that, and nothing more. Expressiveness was never a goal, and as such had to be duct-taped onto the language after the fact. Expressiveness wasn't marketable - safety, familiarity, and OOP was. The explicit typing of pre-1.5 Java manages to be the worst of both worlds, requiring the annoying verbosity of C while still having to sabotage the compile-time benefits through the null-hole and the lack of generics/templates. I'm of the opinion that it is impossible to write good (pre-generic) C#/Java code without a code generator - otherwise you'll either have to ignore OnceAndOnlyOnce or type safety. Even generics aren't the catch-all.

Imho, C++ is inherently a far more expressive (though overcomplicated) language than Java, the problem is that (a) the C++ standard libraries are not usability-oriented and are far too small when compared to Java. If there was a mainstream, free, well-marketed win32/*nix compatible C++ compiler that came with a set of GUI libraries, easy reference counting, etc. and threw warnings at developers who abused the unsafe capabilities of the language without the proper compilation flags, I dare say Java would've had a much worse time taking hold.

Consider when you complain about C++ what it really is that you're complaining about - is it the language, or the frustration of the libraries?

CategoryJava