Is Java the new Cobol? A good argument can be made that yes, it is. Considering the billions of lines of Cobol code that have been (or still are) in production; that observation should in no way be considered a slur. Java has succeeded in the marketplace (partially) because it is a language ''of'' its time; not one behind the times - or ahead of them.

----

Java is the new COBOL because it's becoming the new de facto standard for enterprise applications. Like COBOL, it's a good language for its time, but there are better ones. Like COBOL, it's bloated with features. Like COBOL, it's being used beyond its original view.

''I think your assertion that Java is the new de facto standard for enterprise apps simply isn't true, and there are better languages available.''

And there's probably an argument against "It's a good language for its time" too :)

''It was a great language for its time, for a C or C++ programmer. For a Lisper or Smalltalker however, it was a bad joke and still is.'' LispIsTheOneTrueReligion!

The point is made in terms of mainstream languages for mainstream programmers. Thus, measuring "better" and "newer", you have:
     Java > C++ > C > Fortran > Cobol
(approximately).

''Fortran is older than Cobol; and Cobol is a far more appropriate language for business applications than Fortran. Especially Fortran of that vintage; FortranNinety might be serviceable; but we've got lots of better things to use these days.''

----

I think you are missing the point. At the time Cobol was created, Lisp already existed.

''They were born pretty much around the same time. However, I think COBOL predates LISP slightly, at least its ancestors.''

Java is a good language in the same way Cobol is a good language (IronyWarning). The point I'm trying to make is that Java is the new de facto language. I'm sure that Lisp or Smalltalk are better than Java in a lot of ways. But when you compare it against Cobol, it's better.

''I wasn't missing the point, I was being sarcastic too! ;)''

(Welcome to JavaVsSmalltalk debate - search for the word 'COBOL' to remain OnTopic)

[While I have no doubts that Lisp or Smalltalk are better than Java in a lot of ways, it is also obvious that Java is better than Lisp or Smalltalk in a lot of other ways.]

''Like what? Other than popularity and mass acceptance, what advantages does Java have over the technically far superior Lisp and Smalltalk?''

Let's not underestimate the importance of "popularity and mass acceptance", but it has other desirable features as well.

Let's start the other way around what advantages does Smalltalk have over Java ? You are comparing apples and oranges here, and claim that apples are "technically far superior".

----

For my money, the most important and fundamental (technical, language-intrinsic) difference between the two is Smalltalk is dynamically typed whereas Java is statically typed. ''Most'' of the technical arguments between the two can be boiled down to this.

In a sense, Java is incomplete - a statically typed language really needs to have GenericPolymorphism to avoid a rats-nest of downcasts everywhere. This feature will show up in Java 3 (JDK 1.5) sometime (along with proper enums and autoboxing, the latter will eliminate most of the moaning about int et al not being an object). As a longtime C++ programmer, the lack of generics/templates is what I miss most about Java. As Smalltalk is dynamically typed, the issue is moot there.

See JavaVsSmalltalk

----

Advantages of Smalltalk over Java (with respect to my own values): Simplicity. Uniformity. Flexibility. Expressiveness. Extensibility. Reflectiveness. And some ones that don't fit as nicely into single words: JavaDoesntTrusMe. JavaDiscouragesAbstractCode (which seems particularly damning to me). (I can say more about any of these things, but JavaVsSmalltalk seems like a better page for that.)

This stuff is apples-and-oranges to the extent that the Java and Smalltalk cultures have different values. For example, a lot of Java people seem to like the fact that Java doesn't trust them. ("I don't want operator overloading - it can be used to write some really hard-to-read code.")

''This is a maintainability issue. "Cobol" apps - implementations of business rules - are hammered on by multiple people over a course of years as business needs and processes change. They are not conceived and implemented in a blinding flash by a small team of geniuses. -- PaulMurray''

But there are just all sorts of ways in which Java is a really bad implementation of its own values. Even if Java wants to be the new COBOL, it could have been a much ''better'' new COBOL than it is. -- AdamSpitz (not the author of anything else on this page, but I couldn't resist jumping in :)

Not as a fan of Java, but out of curiosity: in what ways is Java "a really bad implementation of its own values"?

Gosling said that Java is a language for the average programmer; it certainly appears to be less dangerous (and cleaner) than C++, so if the point is to hire 10,000 average programmers and give them less-than-enough rope to hang themselves, then Java appears to be a reasonable choice. That's a different question than what language is best for a world class wizard. -- AnonymousDonor

Well, for a whole bunch of fun examples, look at http://www.linux-mag.com/downloads/2003-03/puzzlers/. Try to answer the questions yourself - and no fair peeking at the answers or running the code. :)

I think that fixing these problems would make Java a ''better'' language-for-the-average-programmer. -- AdamSpitz

I think you're right. But most of them are also problems for most other commonly used languages, too, so I don't think any of those are some kind of truly huge indictment of Java. -- AnonymousDonor

If I were a Java programmer with an interest in improving my own productivity, I would be looking to other languages - even unpopular ones - to see if I could find good ideas that fit in with my own values. Especially if the proponents of those languages kept telling me that there was good stuff there.

In fact, that's exactly why I ended up learning Smalltalk... -- AdamSpitz

''Some comment about the "puzzler" link above. It is so disappointing, I was expecting some real subtle points about the language. There you have complains about Java actually implementing floating point numbers according to the IeeeSevenFiftyFour spec! Oh no, an implementation that actually follows a specification! Then boring examples about overriding Object.equals() without overriding hashCode() and then use it in a H''''''ashSet, woe to the programmer that actually '''reads''' the java doc of Object.equals(), which already told you about having to override hashCode(). I stopped wasting time after problem 7, when they think adding 2 character should be the same as adding 2 Strings. Is it too much to expect a developer that actually look at the reference of the functions before he uses it? -- OliverChung''

I'm sorry you feel that way. I think there's stuff to learn in there, even in the ones that you've dismissed as being stupid (and some of the later ones are better, though they do spend way too much time on the numeric stuff). There's a lot of painful stuff in Java that Java programmers have just gotten used to. My favourite part of learning a new language is discovering all the kinds of pain that I hadn't been aware of until they disappeared. (Of course, that can be a bad thing, if you don't have the freedom to change your language or change your language (to steal MartinFowler's line ;).) -- AdamSpitz

There are examples in those puzzles to support both Oliver's and Adam's points. Oliver is right about the IEEE floating point; in fact he understated it, because there is no possible way to make floating point avoid seeming paradoxes such as the A+B=A (A,B != 0.0); this isn't even unique to IEEE floats. To be fair, this was a lead-in to the puzzles rather than a puzzle, but that's a nitpick.

On the other hand some of the puzzles strongly support Adam's position, too. The one that I recall really astonishing me was the one about unsigned long right-shift-assignment on a signed short silently doing back and forth coercions and giving an absurd result. Offhand this seems just plain wrong, wrong, wrong. I think this is an accident that could easily be gracefully phased out the usual way (produce warnings in the next release, produce errors in the release after that, with a flag to force the old behavior for legacy code).

But in general, like I said before, none of them seem like an extreme indictment of Java. Every language has its peculiarities. Scheme folks think it's absurd that Lisp claims to have first class functions, yet they have to be manipulated differently than other values - a problem known since 1960 but still present in Common Lisp. But the workarounds are usually simple enough that people live with it rather than converting in droves to Scheme or some other language. And THAT'S a BIG language defect. 

I'm not a huge Java fan, but I think so far this amounts to praising it with faint damns; surely there are stronger claims against it. --DougMerritt (no longer AnonymousDonor since I got so talkative :-)

If there's no possible way to make floating-point numbers do the thing we want, maybe we shouldn't be using floating-point numbers. ;) What if, say, 3 / 4 gave you an exact Fraction object, rather than an inexact Float? I want Floats to be available, but making them the default seems like PrematureOptimization to me. Same with making 32-bit wrap-around integers the default.

''You seem like perfect candidate for Haskell, my friend. I'd like to point out, the biggest difference and obstacle right now between languages such as Smalltalk and Java is available libraries. And I agree that Java is the new COBOL. Pushed too fast, very unelegant, and lots of mediocre code to be maintained.'' -- FernandoGonzalez

''Sure, and that approach has been adopted in Scheme, for instance, which emphasizes '''exact''' versus '''inexact''' numbers, supports rationals, uses BigNums (indefinite precision) automatically when a small int overflows, etc. The languages which prefer floats to BigNums are those which care more about speed than most other issues. Old issue.''

Like you say, these complaints are pretty minor. The problem is that the major problems with Java are all much more subjective. I think that programming in Java feels crippling and dehumanizing and mind-numbing - but these are all traits that follow directly from the Java philosophy of protecting programmers from themselves.

I think that that kind of philosophy is ultimately self-defeating - but on this page, at least, I'm just accepting it and trying to work within it. So all I can show you are these little concrete examples of unnecessary sharp corners.

I don't think the sharp corners are unrelated or coincidental; I think they're symptoms of complexity. The best way to get rid of the sharp corners isn't to start fixing them all individually - it's to make the language simpler and more uniform. But as soon as you start making the language simpler, you end up making it more powerful too, which goes against the philosophy. ;) -- AdamSpitz

''I'm not sure that's inherent. Sometimes you get power from simplicity, but only from a rare, deep kind of simplicity, not from every kind of simplicity. BASIC is simple, but in a bad way.''

''Java eliminates pointers and storage management in the name of making it a simpler language for the average programmer. Those are both reasonable choices for that purpose. It enforces use of classes, which is arguable but at least a reasonable choice. It forbids operator overloading, which is wrong for people who need to add new numeric types, but again reasonable to keep average programmers from cutting themselves. It eliminates the C preprocessor for good reasons, although they forgot to cover all the bases there. It's a reasonable starting place for the average programmer -- but yes, it still has ugly warts.''

''If you want simplicity '''and'''power for the non-average programmer, you're no doubt aware of the usual choices....Scheme/Lisp, Smalltalk, Haskell, Objective-C for systems programming, etc. -- DougMerritt''
----

Exactly, Smalltalk and Lisp are for programmers who know what they're doing. They have full meta capabilities, closures, first class functions, metaclasses, multimethods, etc., all while remaining simple in syntax. Java chose the other route, complex syntax with fewer features and none of those advanced capabilities. It's much more than dynamic vs static typing, it's about putting the programmer in charge vs handcuffing him. There are things that can be done in those languages that Java simple can't do without writing an interpreter for those languages, which would be kind of stupid.

''Though it does exist see JayScheme''

Related: BondageAndDisciplineLanguage - Java may be the type of language that keeps bad programmers from making too big a mess instead of helping good programmers be more productive.

----

The "putting the programmer in charge" argument, I thought, had been discredited a while ago. C/C++ bigots have been making '''that''' argument for years. While Smalltalk and Lisp differ from C/C++ in that it ain't anywhere near as easy to shoot your foot off, this line of argument confirms the suspicions of many that these languages are intended for ThreeStarProgrammer''''''s. HaHaOnlySerious

And like it or not... on any project of any reasonable size, it will be next to impossible to staff it completely with wizards.

''Fortunately, one to two wizards are all that is needed, they'll outwork an entire team or regular programmers. Adding more programmers does not increase productivity.''

[Depends on the project. One or two wizards can accomplish quite a bit; but for many projects even that won't suffice. More than one or two wizards is quite hard to come by. Plus, you're misquoting BrooksLaw - adding programmers to a project which is '''late''' often makes it '''more late'''. Adequately staffing a large project at the beginning, on the other hand, most certainly does increase team productivity.]

["One or two wizards are all that is needed" seems like a rather difficult statement to justify. For all of PaulGraham's hemming and hawing about "beating the averages" (http://www.paulgraham.com/avg.html). If Smalltalk or Lisp or whatever is better COBOL than Java, why are there so few commercial successes based on that principle?]

* The problem with being wizard-dependent is maintenance staffing. Even if you find two wizards for the original coding, you may not find a continuous supply maintenance coder(s) who is also a wizard and likes the language used. Biz thus has to often cater to the lowest-common-denominator.

Regarding the security model of Java - the language is designed to securely run untrusted code. And it does so reasonably well - more so than anything else I've seen out there.

(Last I checked, Smalltalk doesn't have true first-class functions, BTW - it doesn't have true independent functions at all. Of course, a block closure comes close - or any stateless object that implements some form of the "value" message - but you can do the same thing with Java.)

''Having [] for blocks allowing idiomatic use of literal object's with lexical scope is equal to first class functions, and no, Java doesn't do this. Anonymous classes have severe restrictions(final variables only ''[that's incorrect]'') and a horrible syntax that prevents ease of use in the way [] does for Smalltalk. It's not about TuringComplete, it's about SyntacticSugar, which is all languages are in the first place. It's a huge difference!''

You are definitely blowing it out of proportions. Make whatever local variables and parameter final and be done with it. For the minor inconvenience of typing an extra
  new BaseType {
      methodName() {
      // ...
     }}
you get the benefit of defining object closures, which are more general than functional closures. 

''Let me show you why that little syntax matters so much.. collect all managers from a collection and delete them''

   //Smalltalkish syntax
   aCollection Select: [:each | each isManager] Do: [:each | each delete].

   //Javaish syntax with same style using anonymous object version of a block
   aCollection.Select(new Is''''''Block{boolean Value(object each){return each.isManager();}}).Do(new Eval''''''Block{void Value(object each){each.delete();}});
''The difference between ''

  [each:|code...]
''and ''

  new Block{void Value(object each){code....;}}
''is more than enough to make sure it's a rarely used idiom. If it isn't easy, it won't be used very often. [] make the use of blocks trivial, and so they get used far more often, in Java, it'd be a pain in the ass, so higher order programming is rarely done, it's easier just to keep rewriting loops everywhere.''

Agreed. But there are better ways to write that in Java ''plus libraries''. It's still bigger pain in the ass than Smalltalk (or Ruby or any of a number or languages) but it's not that hard to make a reasonable functor library in Java. Frankly when I work with Functor libraries in Java, I find my code reads more like a declarative language than like Smalltalk or Ruby: I'll define a few functor sub-types or instances and then set up chain of them for some purpose.

For what is worth Java's major limitation in writing functional code is the inability to partially apply functions, which makes it less obvious for developers how to structure code around function values, but this is also a feature of SmallTalk.

''Java's major limitation in writing functional code is that it'd drive you nuts with all the extra typing since it doesn't recognize functions as first class objects and doesn't support true lexical closures... only a half-assed version of it. Java isn't suited for functional programming. CSharp is far better suited, at least it has delegates and will soon have anonymous functions with true lexical scope with a simplified syntax of delegate{} or delegate(each){} allowing much more Smalltalk like code.''

----

Lots of talk, talk, talk, which I really don't care for. It has to be backed up by the real deal which is software. Too little software has been written in SmallTalk, and too little of that is publicly available to warrant such nonsensical claims like Smalltalk gives you freedom while Java handcuffs you therefore Smalltalk is "clearly" technically superior. Let me make a personal comparison VisualAge was written in Smalltalk, it was exceptionally slow when all the features were loaded (anyone here worked with the Enterrprise Edition), and quite a few times it crashed. I liked it though. However it had towards ten years of history in the Smalltalk code base coming from VisualAge for Smalltalk. The eclipse team did a marvelous job of writing, well, Eclipse, in their dreadful bondage and discipline, blah blah blah, language called Java. Eclipse is clearly superiors, and I hardly manage to crash it - I did in its first versions, but the last one, I was thoroughly unable to crash it. Not to mention the tons of open source and commercial plugins available for Eclipse.

The first time I tried Squeak on 533Mhz processor, back in 2000 it was so unbelievably slow, high memory consumption, with ugly UI and everything, and it did manage to crash quite often. For a comparison, I've seen quite a few IDE-like extensions for Emacs. Boy are they user unfriendly, and they are more like toys then serious IDEs. What else can you say, try the demo webserver coming with DrScheme under a stress load tool, see how you can crash it in no time or bring it to a halt. Even DrScheme itself, it's so cool for toying and following a 101 course, but so awfully bad as a professional IDE. Similar things can be commented about the explosion of server-oriented or middleware open-source frameworks in Java. Java did produce an open-source flurry of collaboration. So did C and C++. Smalltalk and Lisp pale in comparison.

So in theory they are so superior, but if the theory is not confirmed by practice, one should go back and rewrite the theory.

''They are superior, it's a fact.''

Please get your facts straight. And drop down from your cheap condescending tone.

''There's nothing condescending about stating a fact. I'm not a Lisper or Smalltalker, but I've studied them enough to see that they are technically superior languages. They can do more than other languages with less effort and less code and they can do things other languages can't do at all. In my book that is superior. I'm a CSharper, so Java feels very comfortable to me, but at least I can admit other languages are technically superior to what I use. Java may be more popular and have better tool support, but popularity doesn't equal better. Feature to feature, Java, C#, VB, C++, etc... all lose to SmallTalk and Lisp. I'm not trying to be condescending I promise, I just like talking about this stuff.''

["Superior" for what purpose? HorsesForCourses.]

''However, due to lack of popularity they don't get serious development attention and thus aren't tooled out like Java. Were they to get the attention of Java, those issues would be overcome in no time.''

Talk is cheap.

''They remain toys because ordinary developers don't understand them.''

We are so smaaaaaart and the plebeians don't understand our super smart concepts. Now, really, you've got to be kidding. You may be smart but you have so very litle to actually show for it, which doesn't make you so smart, after all.

''Listen, I'm not saying I'm smarter, I'm saying most developers don't get Lisp/Smalltalk, which is true.''

And the implication is: because they are dumb. Which is false.

''Smalltalkers and Lispers are Smug for a reason, they've watched an entire industry continually re-invent stuff they've had for years and pretend it was brand new. That's got to be hard to swallow for them, they should be smug.''

But they're not the only smugs on the planet.

''Yet all languages are still playing catch up to Lisp and Smalltalk and have been for years. At some point in the near future, people will begin to realize this as more and more languages take on Lisp/Smalltalk features.''

Lisp/Smalltalk lack static typing. So to begin with, it is an apples to oranges comparison. Smalltalk was almost an absolute no for open-source because it lacked any decent freely available implementation. However Lisp had good quality implementations for at least as long as Java did. Its lack of appeal to open source development might have something to do with its language qualities (among which the lack of static typing)?

''They don't lack static typing, they've moved beyond it.''

This is simply BS. They were both designed, when TypeTheory was nowhere near what it is now, the rest is tradition and LanguagePissingMatch. Very smart GrandMasterProgrammer''''''s designed modern languages with static typing (Ml, Haskell, OCaml, Clean and a few others), so it is a matter of personality, preferences and software engineering tradeoffs. As far as the engineering part goes '''only results count''' as a measure of good engineering. And as far as the results go, again, Java, C, C++ have a lot to show for it.

''Staticly typed programs are a subset of dynamicy typed programs.''

This is nonsense. They are isomorphic. Try this exercise: write a Scheme interpreter in ML, then try to translate very fast programs from Scheme to ML. Go figure.

''Dynamic typing is more powerful and more flexible.''

Allegedly.

''Lisp was killed by its weird syntax and Smalltalk because of its lack of a free implementation at that time. Java won because Sun gave it away, it was available, so it won. None of this has anything to do with their technical merits.''

Or so the story goes. When you scratch beneath the surface, trivial explanations of complex phenomena are always wrong. '(Especially this one.)' There will always be a case that market merits are technical merits, and vice-versa market failures will lead to technical failures.

''Does this mean that, as Ml, Haskell, OCaml, Clean and a few others are also market failures they are also technical failures even though they have advanced static typing systems and were designed by "Very smart Ghrand Master Programmers"?''

Not at all. All of them were developed as part of research projects, and to my knowledge nobody has put significant effort and money into their commercialization. For their purpose, they are wildly successful.

''Fair enough, though Clean at least has (Hilt) a commercial implementation (that's as many as Lisp, unless Hilt is not significant, you would have to take it up with them). Of course Microsoft is rumoured to be fond of Haskell. If sharp smalltalk or s# become commercially successful on the CLR would that mean that smalltalk is not technically inferior after all? It will be fun to watch a language's technical merit rise and fall with a manufacturer's commercial success;; perhaps we should have annual league tables of technical competence ("Haskell is degrading technically, it's down two places on last year and has been overtaken by Python and PHP..." The idea that technical merit is the only factor is silly, social and economic factors will always play a significant role in the success of a technology. -- TomAyerst''
----
DotNet digression moved to CommonLanguageRuntime
----
Programming languages, like nearly everything else, do not exist in a vacuum. You have to evaluate them in context, and consider both the intended application and the (software engineering) economics of the time. A language that makes perfect sense in one era may seem completely brain-dead to another. No surprise there.

(Given that the languages discussed on this page are frequently deployed in "business applications", we can simplify the discussion by ignoring other key application areas, such as mission-critical, deeply-embedded, or high-performance computing. Nobody in their right mind would consider using Java, Cobol, or Smalltalk in any of these, so the point is moot. Lisp, maybe.)

It is often said that SmalltalkLanguage and LispLanguage are both ahead of their time. And I agree. This is one reason why both failed to gain widespread acceptance in the programming community - they were ''ahead'' of their time.

The SmugSmalltalkWeenie''''''s occasionally put forth the opinion that AlanKay and his team, alone among his peers in language design, were noble visionaries - and imply that the other language designers of that era were cave-dwelling troglodytes for working on "inferior" stuff such as Cobol, Algol and its derivatives (up to and including C, C++, Java, C#), Pascal and its derivatives, etc. Nonsense. Other language designers (from NicklausWirth to BjarneStroustrup) were working on languages appropriate for the engineering economics of the time - when CPU cycles and memory were considerably more expensive than they are now. (Program complexity was much smaller, and programmers, while expensive, were less so than nowadays). AlanKay was given the opportunity to work on stuff that probably wouldn't be marketable for ''years'', and which made little sense for practical applications ''at the time''.

History, and MooresLaw, have since made AlanKay look quite prescient. The economics of today are that CPU cycles and memory are cheap; applications are much more complicated, and programmers are even more expensive. Were SunMicrosystems to have developed Smalltalk instead of Java, I have little doubt that Smalltalk would now be the ''de facto'' standard for business applications (other than what was peddled by MS for Windows shops).

But in 1980, Smalltalk was really only useful for prototyping/research applications - and that association has given it baggage that it seems to carry to this day. (Ditto for Lisp and ArtificialIntelligence). Speed (or lack thereof) was fatal for the language in many applications - the overhead of dynamic type-checking for many operations, the pain of running a GarbageCollector in a low-memory environment (garbage collectors are MUCH more efficient if the size of available memory is at least twice the size of the application's code and dataset), and the overhead of a virtual machine all made Smalltalk a non-starter for much production code. When Smalltalk could be used, it was (and still is) beautiful.

Not to mention Smalltalk's need for a rather advanced display subsystem; at a time when most of the machines to be found in the enterprise were BigIron mainframes and/or minicomputers, with GreenScreen text-only terminals. How are you going to run Smalltalk on that? PeeCee''''''s were just starting to show up (but expensive and widely viewed as toys, unfit for any serious work), and the numerous 8-bit micros out there were ignored by the programming community. The Mac might have been a good fit for Smalltalk, but Apple decided it was better to steal from XeroxCorporation than buy. :)

What will we be programming in ten years hence? Might be Java, might be Python, might be Ruby, might be Something''''''DotNet, might be something else. It might even be called "Smalltalk" or "Lisp". It probably will look more like either of these languages than Java, C++, etc. do today. It will probably borrow quite a bit from the functional languages of today - which it might also be said are "ahead of their time".

But it probably won't be something that is available today.

It is probably more accurate to say Java is the new PL/I, another dead IBM language. PL/I's claim to fame was it was this incredibly huge, feature-rich, bloated language with a ton of libraries. You could program anything in it, but it got so huge it was useless. Features keep getting added to Java. Now with Java 8, Oracle wants it to be a full-on functional language as well and have added more bloat to it. Time to let Grandpa Java retire and make room for the new. But keep the virtual machine and the useful libraries. Use scaIa or python or whatever as the coding language. Though I have to say the concept of both interpreting ad compiling code does not seem ecocomIcal with respect to time.
----
CategoryJava