SIGH Some people are such fashion idiots. We get it. You think Java is like wearing flares. It's unfashionable to you hip idiots.

You're having a blast hacking together your dynamic stuff without a care in the world. You love how you can type 3 less characters and get the same work done! Woo! High five! You have your repl setup so you can edit (and break) your website on the fly. Static typing? who needs it. Lets write our own type checking all over the code.

Meanwhile, people who don't care what is fashionable, are making awesome stuff in whatever language they assess does the job best.

For anyone who hates Java, I'd recommend:

  * Ignore everyone who writes Java commercially.
    *especially* corporates doing their massive TomCat
    beans getter/setter XML over engineered crap.
  * Do NOT use an IDE. You don't need to. It makes you
    output more code, and worse code.
  * Figure out your own concise style, and figure out
    the absolute strengths of Java (There's many).

I know it's ridiculous that at some point programmers may figure out that languages are largely irrelevant, but I hope it happens one day.

Talking of languages "Dying" is also quite ridiculous. Languages are 'alive' as long as people use them. Guess what? If a new JVM is never released, it still solves a massive class of problems.

A good programmer beats a good <language> programmer IMHO.

</rant>

Nothing in this article says anything about "dynamic languages". If anything, the author is in favor of Java. He simply suggests that it takes some of the features from C#, which is a very Java-like language, but hasn't been encumbered by the "Java ecosystem" (which is basically large IT companies that want to outsource everything to India, which is already trained to crank out Java 1.4.)

Static typing? who needs it. Lets write our own type checking all over the code.

You have to write your own type checking in Java, since any value can be either of the declared type or null. You know NullPointerException? That, my friend, is a runtime type error. (C# and Haskell both avoid that.)

Anyway, I could go on and on about language features that Java needs. But Scala implements them, so just look there.

"I know it's ridiculous that at some point programmers may figure out that languages are largely irrelevant, but I hope it happens one day."

One can't "figure out" that which isn't true ;P

As a proponent of language-oriented programming I can only disagree strongly with your statement. Languages are supremely relevant. However it is true that with respect to a specific problem, the expressive difference between almost any two general-purpose languages pales in comparison to the difference between a general-purpose language and a domain-specific language specifically tailored to the task at hand.

In my as-of-yet-unreleased Common Lisp web framework, I have DSLs for:

- HTML ("building", rewriting and outputting) - CSS (building and outputting) - Form validation - Error message specification and customization - Declarative configuration management (loading and dumping, eventually modifying too) - and probably others I'm forgetting at the moment, plus a bunch of others I'm planning to do

I'm sure Java has equivalent stuff, the problem is that their solution has to fit in a rigid mold (object-oriented, java syntax) so there's a lot of cognitive resources wasted in translating back and forth between your mental model of what you want to do and how you must express it in Java.

Would shakespeare have been terrible if he had written everything in french?

Personally, I don't think so.

Uh?... English and French are two general-purpose human languages and I was talking about computer languages, and then mostly about domain-specific ones.

So I guess you completely missed my point.

Would he have done as well in a language that didn't have adjectives or adverbs?

That's not a good comparison. You can do anything in any turing complete language. They're all equally expressive. If the language isn't expressive enough, make it so.

Isn't that contradictory?

If all turing-complete languages are equally expressive, how does adding another feature to a language that's already turing-complete can possibly make it more expressive than it already is? It was turing-complete before the addition and it's just as much turing-complete after the addition.

I'm not really impressed by turing-tarpit-style arguments. There's at least one thing I can do in Common Lisp that I can't in Java: Implementing new syntaxic constructs look exactly like they're part of the language. I won't bore you with a long laundry-list of other similar things.

In fact, you know what? If by the turing-completeness criterion all languages are equally expressive, then the important points of comparison between languages in terms of expressiveness are necessarily matters other than turing-completeness.

Or would you argue that, say, x86 machine-language is just as expressive as say, Java? According to your turing-completeness argument that would seem like a yes. By the way, I do include a certain measure of "productivity" in my use of the word "expressiveness". Do you?

You are exactly right. Turing completeness is irrelevant when comparing languages, because it is a property of both. Turing complete or not, good luck programming your graphics card with Tcl or having boilerplate-free Java. It just isn't possible.

But the way I see it is, "it's not my problem if people want to write boilerplate all day" or that they like Java. Using Java does not take anything away from me, except possibly contributions to the community. (But then, the fanbois are rarely contributors to the community. This is true even for me!)

You will never convince axod that Java would benefit from new features. He is happy to be in a minority here (a "smug Java weenie"), and that happiness is worth more than potential increased productivity.

HN is a weird place for programming discussions. People here seem to think that making a website that people will visit and look at ads on is somehow correlated to code quality. It's not. It's just that you will enjoy making that website more when you aren't manually writing your own delegation functions, or writing "Foo foo = new Foo()".

>> "Or would you argue that, say, x86 machine-language is just as expressive as say, Java? According to your turing-completeness argument that would seem like a yes."

Yes. I absolutely would, and I've written about the same amount of x86 code as I have Java. They are each suited better to different tasks, but they're both just as expressive for me.

It is not just a fashion war, it is about investment of resources. If I would like to program in LISP, but all the big shops insist on Java, I lose.

Static vs Dynamic: I guess both have pros and cons. But even for static types java seems to lose out now.

I'll leave the roid rage against dynamic languages alone for now.

A good programmer beats a good <language> programmer IMHO.

I heartily disagree with this statement. I seriously doubt a good programmer can step into, say, C++ and work as effectively as they might in Java. They don't know how to manage memory well. They won't understand a lot of the nuances with pointers. They won't use a lot of the more subtle syntaxes a "good" C++ programmer will know. The same is true with Java or Python or (and I know this one from a good bit of experience) Ruby.

Knowing your tools well is essential. Being a generalist is great until you actually have to do something.

By "good programmer" I meant one that has experience of a wide variety of programming - memory management, pointers included.

Did you really take the post that personally?

I'm just bored of the endless fashion strutting that goes on recently in programming. I think it's irrelevant and tiring.

If a language solved a problem 5 years ago, it'll solve the same problem today. It won't die unless something else is found that solves the problem in a better way.

Yeah, why bother keeping up with advances in the field? Back in my day, sonny, we used our Java 1.4, and that's the way we likes it. Any new ideas should be immediately rejected as "fashion strutting", especially new ideas that have been successfully implemented in other languages for decades.

Let's start with Java's object system, and add state and implementation to interfaces. This way you can write something like:

   role Eq {
       requires 'equal_to';

       method not_equal_to($a: $b) { return !$a->equal_to($b) }
   }

The technique of composing classes from parts has recently been popularized by Smalltalk, Perl 6, Perl 5 (Moose), and Scala. (Scala's implementation is intentionally limited for some reason; look to Moose for the most reliable implementation that people actually use for Real Work.)

If you want to do this in Java, you would have to create a class like:

   class NotEq {
      private Eq a;

      method not_equal_to(b) { !a.equals(b)  }
   }

   class Foo implements Eq {
      private NotEq neq;

      Foo() { neq = new NotEq(this) }

      method equal_to(b) { ... }

      method not_equal_to(b) {
          neq.not_equal_to(b)
      }
   }

This is a lot of code to write, which is why people just cut-n-paste instead.

Also, Java is not merely 5 years behind, so it is worthwhile to look back farther to find ideas that Java could embrace. Java would do well to steal a sane object system like CLOS or Moose; it could really eliminate a lot of boilerplate. (One thing I think is annoying about Java is how much work the constructor has to do. In Lisp and Perl, I never write my own constructors, the object system does it for me. This means that things can be composed without the programmer having to know every detail, including which position each attribute initializer should be in.)

Anyway, if you really think Java is the state of the art, you should look around a bit more. Yes, it's silly that people want to do their own type checking in "dynamic languages", but that's not why they use them -- it's all the other features that they want. The lack of static type checking is an unfortunate overreaction to C and C++.

Soviet tanks were not exactly 'state of the art' either, but they worked pretty good. What's 'hot' doesn't automatically qualify to solve things for the longer term, in fact being 'hot' is a fantastic reason to stay clear of a technology, because if it is in fashion this year it could very well be out of fashion next year.

Yeah, except many of these ideas have been production-tested for 25+ years.

Remember that Java is the language that introduced garbage collection to the world. Before Java, it was basically an untested academic thing that Lisp machines did. Why be liberal with such a radical new idea and conservative with things that let you implement programs the same way you do now but with less typing? It makes very little sense.

Garbage collection is a massive gain. Far less code, and less bugs. No brainer decision there.

Typing a few less characters on boiler plate doesn't buy you anything, unless you're a slow/lazy programmer.

Typing "public static class" is boring, yes. But it's irrelevant. It can't contain bugs, so getting rid of that doesn't buy you anything at all.

Less typing != less bugs (When the code is compiled, statically typed, etc).

There is absolutely no reason to duplicate code in Java, and if you're copy/paste coding, it's not the languages fault, it's yours.

"""Typing a few less characters on boiler plate doesn't buy you anything, unless you're a slow/lazy programmer"""

Must be nice to have an infinitely large short term memory.

Not to mention that I have never said a thing about things like "public static void". I specifically mentioned the object system above and how much manual easy-to-get-wrong code is required simply to make things that have an equals method also have a "not equals" method.

Sometimes I wonder why I bother arguing with axod. Wait, I always wonder that...

Come on. How often do you really need an equals method in your classes? It's not a big deal. (No, I'm not one of those people who insist on writing equals/hashcode/toString on everything even when it's not being used).

I wonder why I try to bring sanity to these sorts of discussions also :/

The example is an example. For "not equals" you might as well just write not, then equals.

But amazingly, sometimes code more complicated than that needs to be reused

I wonder why I try to bring sanity to these sorts of discussions also :/

When did you do that? You seem to bring a lot of emotion, very few technical arguments, and a lot of words like "fashion".

Since Java lacks generics, there are many kinds of code which require duplicate code in Java. Specifically, every place where you would use generics in another language (Templates in C++, or TypeClasses in Haskell, for instance).

Java definitely supports generics as of 1.5 - did you mean that it doesn't support generics to the extent of C++? Most basic uses (containers) are identical between the languages, and while Java doesn't allow compile-time "duck typing" that C++ does, you can fake it by using the "? extends SomeInterface" syntax.

Java supports type erasure, which it idiosyncratically calls "generics", even though it does not allow generic programming. A generic function in a language with actual generics can work generically, on more than one type. A "generic" function in Java can work on exactly one type, namely the type which the "generic" type becomes after type erasure.

You can use "? extends SomeInterface" only if you write SomeInterface wrappers for every type which you want to use "generically." This is boilerplate relative to most other languages.

Personally, I find this boilerplate equivalent to the comments one has to write documenting the requirements of the type, with the added benefit of readable error messages when you pass the wrong type. In other words, I find:

  // T here is a type that must support these two operations:
  //   bool froznit();
  //   void frobnob(Foo* foo);
  template <class T> class Frozner { ... }

And

  public interface SomeStupidName {
    public bool froznit();
    public void frobnob(Foo foo);
  }
  public class Frozner<? extends SomeStupidName> { ... }

To be just as much work to type.

I think that has to do a lot with Java's heritage.

What they were shooting for seems to have been something that combines the syntax of C and some of C++ for easy access to a large pool of existing programmers but without those 'scary pointers', and the memory leak issues associated with bad programming habits in C and C++.

>> "Anyway, if you really think Java is the state of the art, you should look around a bit more."

Thanks for proving my point. My point is, It doesn't have to be "State of the art" (fashionable). It has to work.

You don't make sense again.

I do use C. For classes of problems that are appropriate - kernel/low level stuff.

For several things though, the lack of gc'd memory management, buffer overflows etc is a good reason not to use C.

It sounds like you truly identify yourself as a "<language> programmer" rather than a "programmer" :/

I am more interested in writing good programs than "just getting something done". That means using tools with the appropriate level of expressiveness, of which Java and C are neither.

Ask me which of Common Lisp, Haskell, and Perl I prefer, then call me a "<language> programmer". Remember, in the other threads, I am advocating combinations of features that do not currently exist in any programming language. I may be a "<language> programmer", I guess, but that <language> does not actually exist. Meta...

(You are the one who thinks that every feature that Java has is essential for programming, and every feature it's missing is <some cynical weasel-words here>. That is indicative of seeing the world through Java-colored glasses.)

FWIW, I've written far more non Java code than I've written Java code, so I wouldn't say I have "Java-colored glasses") ;)

I've also never said that Java is better than <insert other language here> without qualifying what it is better for.

When did you qualify what it is better for? (Better than what?)

I don't disagree with anything you've said, but the author of the post made the same point - languages don't die unless they are completely replaced. The author thinks that Java may live on for decades.

He has taken the unfortunate, but popular, definition of a dead programming language: one which has stopped evolving. Of course, such a language is no more dead than sharks.

Although I will agree with you in general about Java, I have to say that problems/challenges change, therefore you need new specific languages or automation tools for the job.

In my point of view Java is just the tool to create new domain specific languages that solve these new problems.

But, general languages that just make just a bit shorter or less verbose (as everyone who likes to dismiss Java uses quite often), to create a class won't do it for me to change language/platform.

What tools does Java have for creating domain specific languages?

I'll pretend you're asking in earnest: Depending on the need, you have a bevy of parser-generators to choose from. My favorite is SableCC.

Or, if you want something lightweight where you effectively have a DSL without creating an actual language, look towards static imports + fluent interfaces + builder pattern:

http://blog.centuryminds.com/2007/10/java-static-imports-flu...

domain specific languages == libraries.

You make some libraries, functions that do shit. Then call them. That way other people can still read the code, and help.

It's like GOSUB but better!

Welcome to the bimonthly "Is Java dead ? Can it be saved ? Using Java, brain-dead ?" ad-infinitum . The reality is quite prosaic , does Java work for you ? This can also be re-phrased as Are you looking for a stable,robust language with tons of libraries + tools and lots of "developers" ? If yes, then consider Java.

If no, then look elsewhere , may be even at one of the languages running on the JVM. End of.

That's not what this article is.

Why bother reading when you can make a cynical comment instead, though?

I did read the inflammatory headline and the complete article and that was my takeaway from it.

You of course are welcome to your opinion.

I find it interesting that the article mentions the "new" operator, since this particular language quirk has been a source of minor fascination to me. Presumably it was added to make Java look more like C++, even though many other parts of the language are quite different. The "new" operator is the only language feature I can think of that has no purpose other than appearance, and that comes at the cost of making the language just that little bit worse.

These comments by Guy Steele

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

on the LL-1 list seem to shed light on why Java has a hardwired "new".

Aha, interesting. So they were worried about having a specific operator for heap allocation.

It doesn't sound like a particularly clever design decision, because even very early on Java had static "newInstance" methods which rather seem to defeat the point. But I can see the reasoning behind it now, even if that reasoning wasn't very well thought through.

This is all irrelevant because most Java programmers now program in XML anyway. Except they like to think it's not programming, but "configuration".

I don't know why you were downmodded, that's an accurate description of most AOP shops. 10,000-line, version controlled "config files" are not unusual.

The fact Java can be used like that, is irrelevant to the merits of the language.

Mibbit backend is about 20k LOC, and 72 lines of xml to get ant to do something useful.

But it's not code, so it doesn't need testing or documentation. Think of the time savings!

Version controlled if you're lucky too!

Uh oh, the Java downmod trolls are here.

I wonder how many accounts axod has created simply to mod down every post in "Java is not perfect" threads.

And I'll do the same in a few years time when this place is overrun with "Ruby is dead!", "Why Python is dead", "Is erlang the next COBOL" articles.

"Why Python is dead" was posted yesterday. ("No changes for three years.")

C# and Java may look similar, but they have drastically different ecosystems. C# can evolve much faster because Microsoft can drop their support of older versions and make them practically inviable. MS customers are used to the cycle and have learned to expect it. The large corporations that adopt Java, on the other hand, don't expect and don't want the language to change. They have hundreds of millions of dollars invested in code, and they won't let any vendor tell them it's obsolete.

I think projects like Clojure are showing that the Java platform isn't necessarily about the Java language anymore, that the runtime and the class library can be used to great effect while getting passed Sun's unwillingness to evolve the language.

When was the last time Sun updated the bytecode format? I seem to remember it has been quite a while, like 1.3. I don't know, I haven't been steeped in Java for the last 3 years.

It appears it was round about the time of JRE1.5. Actually, that was the last major runtime update, that doesn't mean the bytecode format changed, though obviously how the runtime reacts to the bytecode is a significant consideration when developing a new language. Anyway, it doesn't seem like the JRE is a largely moving target.

The strange thing is that even though Java is very much backwards compatible, big vendors behave as if every new version would break everything.

I've had to move heaven and earth for an upgrade from 1.4.1 to 1.4.2 when Java 6 was just around the corner, and I hear that there are still many teams using Java 1.4.

It's funny how an article about Java the language comes up and almost every single comment here is attacking either the article or the language. Like it or not, Java is one of the most popular languages, so there are going to be a lot of people who want to improve it to make it more usable.

As the article said, Microsoft has proven with C# that you can take a language and evolve it over time for the better. If Java the language wants to be viable and keep up with what programmers want from a language, then it's going to have to release an update with changes like the ones outlined in the article. I think the article hit the nail on the head with some of Java's biggest problems (though not all). These changes would make it so that Java could be used in the way a lot of people want to use it.

Funny that this article praises C#'s generics over Java's type erasures, when Rich Hickey specifically cited the latter, and the convenience it creates for dynamic languages, as a reason for choosing the JVM over the CLR for his implementation of Clojure.

again, please don't upvote question headlines. cowardly journalism, easily abused, insubstantial stories. just don't do it.

Agree. Flag it instead.

That's an excellent article, thanks Fogus!

Not only does it level some valid criticism, it also proposes (for the most part, omitting 'new' would break too much code) workable solutions.

I think that both sides of the argument are valid but I am more inclined to believe that keeping the language stable at least over the short term may be the better strategy.

Java thrives in environments where stability is a prime concern and Sun's commitment to maintaining backwards compatibility would inspire confidence.

The new languages that are being developed to run on the jvm reduces the need for Java to evolve as rapidly as some would like. If it is proven that these new languages solve problems better than java then it's only a matter of time before developers make the switch.

At this point when it's obvious what features are really desired then it Sun/Oracle may decide that adding those features to the Java language are appropriate.

In this way the new jvm languages sort of act like a research lab to test out new ideas to see which work better.

Java has some serious shortcomings that require you to write lots more code than actually necessary, to reduce that would be really really neat.

On top of that I can see one immediate benefit in implementing some of these, which is that to my eyes all java persistence layers are kludges, simply because of the way the language is structured.

This could make writing such software a lot easier and more reliable.

"Can Java Be Saved?"

Hopefully not. :)

Why hopefully not ? Java has it's uses.

I'm no 'fan' of the platform, but like any other programming language you can write anything in it, it simply has a 'niche' where it is a good tool when properly applied.

And what is this niche?

Software written for large corporations with a medium to high turnover in their staff where quality of programmer is less a factor than long-term maintainability of the project is.

As weird as it sounds, in that world java's lack of 'neat constructs' and tendency to solve things using 'boilerplate' is actually an asset, for the same reason that COBOL used to be an asset.

I've inherited a bunch of java code about 10 months ago now, so I've been more or less forced to come to terms with it, and even if I can't get over how tremendously kludgy it feels I would have a hard time getting this kind of performance out of other platforms on the exact same hardware.

Call it grudging admiration, I personally would have never thought that you could do this and more with Java before being forced to get in to it.

There isn't a day though that I don't curse the language designers for making me go the long way around on just about anything that I could do in half the code (or less) in pretty much any other language that I have under my belt with the exception of assembler.

At this point in time, my main gripes with java are verbosity and an absolutely terribly kludgy feel to the interface with other parts of the library, it feels like wearing a straightjacket.

And it is exactly for that reason why enterprise types much really love it, my 'creativity' is limited to the point where anybody else facing the same problem would probably write more or less the same code.

Since joining this project I've basically just been busy condensing code and removing 1000's of lines of boilerplate by replacing it with the appropriate abstractions.

And by doing that I'm doing two things, I'm making the work marginally more interesting, secondly the other guy working on the project is slowly starting to see that cut&paste is not the way to go.

But that's my 'toolmakers' hat that I'm wearing, I'm pretty sure the that people that lead this project would rather have me work on 'features' because that is more productive in their eyes, my kind of 'productivity' will start paying off in the longer term.

Time will tell how it is all goes, for now my conclusion is that it is probably not the language that is 100% at fault, it is likely in large part attributable to the people that use it and promote it. And it will be a long time before I will be one of them, if ever.

If you've ever used UCSD-P with the dreaded P-code then you know roughly what I feel like about this job :)

This is just crying over spilt milk, isn't it?

Java got to be the COBOL of the 21st Century because of the boilerplate & etc, not despite it.

Immoral MegaCorporations like Java because they can segment large jobs and have armies of drones work on the small segments. Immoral MegaCorporations don't innately like productivity, they innately like Control Over Employees.

Uhh... it's not immoral to want manageable code. If any piece of code would depend on the programmer who wrote it, or require somebody in the top 10% then I'm sorry to say, but a lot less software would be written. It's not a perfect world, but I tend to value a workable compromise over an unworkable ideal.

If you're going to implicitly say that Java code is more "manageable" than alternatives, then you're going to have to provide citations, or at least meaningful stories of your experience.

The most important purpose of higher-level programming languages is to remove accidental complexities.

I can give you dozens of examples where Java fails to do that ... as opposed to other languages, some of them mainstream. Some examples ... nullable references, checked exceptions (which are a class of their own), no compile-time code contracts (the type-system is way too weak), concurrency based on shared state and mutexes, public/protected instance variables (with a god-awful getters/setters convention), no real closures (an anonymous class instantiation only captures final locals), no multi-dispatching (this could take care of half of all possible Java-related gotchas, at least), no pattern-matching operator (switch doesn't count). And the list can go on and on.

I've also worked on "big" code-bases written in Java. Some Java open-source libraries are truly beautiful, but these particular projects were not. On one of them it took one whole month to fix a bug that escaped us because of all the layers and all the boilerplate that was executing. This particular bug only happened like once a month, and debugging multi-threading Java code is a nightmare (I guess it could be worse).

Sorry, but this argument doesn't fly. I work in a Perl shop and not all programmers here are in "the top 10%" (I don't think either of us are). But with enough training and clear code-conventions (many of them coming from our community) ... our code base is quite manageable.

PS: I don't have anything against Java or Java programmers. I actually like it because of the available tools, libraries and because of the JVM, which is state-of-the-art.

> Java got to be the COBOL of the 21st Century

Java won. It wanted to become the Enterprise language. Initial concerns over speed have mostly been addressed with JIT compilers. Java = COBOL.

Java is so firmly entrenched in the Fortune 500 enterprises.

Because Java won, stuff like Grails (Groovy + Java) has a much better chance of getting corporate adoption than Ruby on Rails.

Having worked in corporate environments for a long time, people risk their jobs when they push (relatively) new technology (like Spring, over J2EE).