Sort of ironic that all of his concerns were proven out, yet Java still managed to prove his prediction wrong.
Though his definition of success seems to be "would really good programmers (wizards) ever use this language for sweet projects? If yes, than this language is a success." By that metric I guess he would be correct.
I have to disagree. What about Hadoop, Solr/Lucene, Mahout, etc? Those are pretty sweet projects made in Java and I'd have to argue are pretty successful. I'll admit that I have listed all Apache projects, so would you then argue that Apache has been successful as opposed to Java?
Agreed, there are certainly exceptions to the rule but I don't think anyone would put the level of Java's "hacker acceptance factor" anywhere near Python or Ruby or the like.
What's the "hacker acceptance factor"? Is that "what do 22yo kids writing webapps and shopping for sailboats to buy after their big idea takes off think about this?" I mean, why should I care about that?
Basically for the niche that Java fits in (networked, multi-threaded data-center applications where performance is important), it hits a sweet spot of ease-of-development compared to performance. C++ is a nightmare to code in, comparatively, and the scripting languages are either dog slow, have poor concurrency support or both. YMMV I guess.
What is PG's so-called "hacker radar" if not some analogue to the "hacker acceptance factor" that I tried to allude to?
People think that languages like Python and Ruby are "cooler" somehow than Java - that's all I was trying to get at.
I don't think that I was making any judgments about the validity of that opinion, but I would say that it is fairly pervasive for better or for worse, and for many of the reasons that PG alluded to.
Hasn't been that way for a long time. Early versions had problems, but they've almost all been ironed out, now. Its speed is similar to C++ for most tasks, faster at some and slower at others. The only real speed problem left is boot time for programs, but that's largely a non-issue for programs that are never closed.
I was falling for that rhetoric. then I actually tried to do some high performance computing in Java. After a lot of optimizing (and going to non-idiomatic code), it was only x4 slower than the C code it was replacing. The initial "straightforward, idiomatic" code was x10-x50 slower, and taking x5 more memory (which caused it to be totally unusable, as the C code used 1GB of memory, and the machine only had 2).
The computation was really quite simple, but it had to be done a bajillion times. I suspect part of the reason that it was so slow is that the JIT was not inlining something it obviously should have. However, I was unable to find any tools that would help me figure out if that was the case or what the JIT was actually achieving (consulting with Java experts I know didn't give any insight or link to such tools).
If you're telling yourself that "java is good for hi-performance computing", you aren't really concerned with speed or memory.
It really depends on what you're doing. The quirks of the JVM mean there are a lot of hidden things you can do wrong and tank your performance.. JNI calls that you don't realize you're making, or suboptimal use of objects and creating GC debt. Some of the Java math libraries are randomly slow for certain inputs, as well.
That just puts an emphasis on what I said. If there are a lot of hidden things that can go wrong, then in any non-trivial application some of them do, and Java performance is on the average, horrible.
The bigger problem is that there's no reasonable way of figuring out what the problem might be.
And for the record, said code was a tight loop, created no objects, had the same kind of workload of a sort algorithm; The two nontrivial things about it was that it was accessing multiple simple vectors using the same index (non-idiomatic java), and that one of those vectors was a memory mapped buffer (non-idiomatic java, but essential because of the overuse of memory).
Yeah, funnily enough, over the last 15 years, Java's traversed the full spectrum of hater, from "script kiddie language that's too slow for real men's work like C", to "too much static typing and inflexible for rapid app development like Ruby"
No, hacker doesn't mean "web-startup groupie". Hacker is more the opposite of the mindless corporate drone who's coding just for the paycheck. (Note: this doesn't mean hackers never work in the corporate world.)
Well, sorry if I insulted anyone, but I'd think worrying about the "hacker acceptance factor" of a piece of tech is awfully non-hackerish.
You can write corporate drone type stuff in any language -- and you can write awesome code in any language. Java with a lot of immutability, closures (anonymous classes) and ExecutorServices is like a syntactically weird multi-threaded lisp. Very elegant. The language itself has something like 15 keywords, total.
As the person said upthread, you can look at some horrible 2002 EJB webapps (and I'm sure you can find their equivalents in rails), or you can look at projects like Hadoop, Hbase, Cassandra, etc. In general, static languages are probably a bad idea for webapps or scripting -- that doesn't mean they're the province of drones.
Nobody is "worrying" about the "hacker acceptance factor". It's just a fact that hackers interested in pleasant expressive coding are pretty unlikely to choose Java for their own projects.
The one criticism that I don't agree with is, "The DoD likes it." The DoD is a huge place. Sure, most of it is extremely bureaucratic and planning oriented, but there are a few hacker friendly corners (DARPA, anyone?) here and there.
I also don't agree with his criticism of Ada. Yeah, Ada isn't a good choice if you're building a web app that needs to be out next week. But Ada wasn't ever intended to be used for that sort of software. Ada was designed to build absolutely reliable software. I'd rather have the Space Shuttle's control software written in Ada than Java.
"I'd rather have the Space Shuttle's control software written in Ada than Java."
That's what I was thinking, too. Was Ada really meant for "other people" to use? I wonder how many people involved in the process went on to write Ada afterward?
I don't know the facts, but I would guess that the critical system software writers in the US are a fairly small group, and anyone on that committee knew they would end up writing a lot of Ada afterward.
I doubt it was the same kind of "make a language for the masses" simply because there aren't masses of people capable of writing software for critical systems. I would guess that it had more to do with a mutual pact: programmers have to add extra annotation for interfaces and constraints; but in return they can absolutely rely on those interfaces and constraints because they know that the compiler enforces them.
The DoD doesn't exactly promote a hacker culture in the civilian roles; however, depending on branch of service (e.g most likely not marines) and role (officers and above), there is latitude for creativity.
Of course, anyone who has worked the civilian side of DoD knows how bureaucratic it is, and I think pg is right to say that if DoD likes it, it's probably not a great sign. For instance, you can't submit invoices (you have to use a convoluted procurement application and enter it through a very 90s looking app). There are paperwork mandated by Congress and administrative agencies (GSA). And let's consider the Goliath that is DFAS. They use Oracle. And Oracle Forms.
His other definition of success for languages is "will this language significantly influence languages we will use in several decades". I'm inclined to think Java won't, but it's going to be at least 20 years before we can really test that prediction.
Java's influenced all the languages now built to run on the JVM. Groovy, Scala, Clojure. Not sure if these will be used in several decades, but the fact that there are several already around is a good sign. Not to mention that I can guarantee we will be using Java in several decades.
Who's we? I doubt many hackers will be starting new projects in Java in 20 years. Sure, there will be plenty of legacy code around, just as there's plenty of COBOL around now.
I think Java's influence on Clojure is fairly small, and mostly visible around the places where the Clojure has to interoperate with Java libraries. I'm not sure what to call this - incidental influence, maybe?
There are tons of sweet projects out there written in Java, and there are lots of really really good programmers out there in Java. Just cause you don't know them, or look up the projects, doesn't mean they don't exist.
In "The Hundred-Year Language"[0], PG elaborates on what it is to be a successful programming language, and what he thinks will happen to Java. PG predicts that Java will be an evolutionary dead-end without much influence on future languages, like COBOL[1].
Let's look at what Java has influenced. C# is fairly obvious, but that too is likely a dead-end. I don't (personally) know any good hackers who are excited about C#. Actionscript and PHP seem to have been inspired by Java in their object systems. I don't think either has or will influence future systems, except perhaps as examples of how not to do it. Scala and Clojure show some Java influence, but it's not very strong. That influence is primarily in the form of compromises required for running on the JVM platform, which probably won't be around in its current form in a few decades.
I don't personally know anyone living off of food stamps, but that doesn't mean they're not out there. C# doesn't thrive in exciting spaces, but C# is probably doing more to evangelize FP concepts than anything else in the corporate world. It's also pushing into mixed static/dynamic territory these days.
The "exciting spaces" really is one of the most important issues. Everyone who's ever told me to work in C# or Java is just in it for the money, and willing to goldrush to crappy enterprise-ware. Rather, I like Cocoa as it's the best way to interact with users who love their computers (other than Linux, 'natch.)
But yes, Microsoft is really doing some awesome conceptual stuff.
The only exciting thing I see about C# as a language is that it's dragging the Java programmers a third of the way to ML. What's exciting about the language itself?
The only feature I'm seeing in that list that didn't exist in some other language 10 years or more before it did in C# is LINQ, and I'm only willing to give that one half a point; it's essentially syntactic sugar for the standard functional sequence operations.
Normally I'm not especially enthusiastic about doing another round of java bashing, or another revival of an old (but good) PG article. But there is one last prediction here that has become very relevant in the past few months:
"Its daddy is in a pinch... If Sun runs into trouble, they could drag Java down with them."
Hard not to hear an echo of this prediction from 2001 when reading about Apache's decision to drop out of the JCP.
The coin has two sides. While corporations push (perhaps ignorantly) for Java, I've always been very resistant to Java. Probably ignorantly, due to elitist cultures like HN where anything mainstream is frowned upon. One could say that in the bookshops I visit, the "cover of Java" has been torn up and defaced before even being put on display. I'm ok with that though. I'm as elitist as the next guy.
At, OSCON, the Eclipse "ecosystem guy" (I think it was Donald Smith) had a nice overview of what he was up to, and how he measured "ecosystem strength". It gave me pause, because that was the first thing that really nailed why tech like Java takes off. Productivity, robustness, and niche creation.
I figured I'd just drop a link to it, because it's interesting to compare with "hacker instinct". Java got the ecosystem rolling really quickly; it would be interesting to compare that kind of growth across different tech.
You know, a lot of PG's points are correct, despite Java's success. Java was aimed low - it was pitched as a way to write good enterprise software without expert developers. It is bureaucratic - many times the only way to get the object you want is to submit the proper forms to the object's factory. Suits love Java because Java programs can be described with wall-covering UML diagrams.
The fact that all of these turned out to be reasons for Java's success rather than its failure doesn't undermine the validity of the criticisms.
C++ was built entirely for its creator to use. Depending on how you take that, it could mean that either 1) PG is wrong about C++ and it's an okay language, or 2) PG is wrong about language design in this case and people can design bad languages for themselves.
I think it's the first one- C++ is a solid language for what it's good for, which is very different from what Java or Lisp or Python are good for. C++ and all its techniques (beyond just being a "better C") can be used in place of C perfectly well.
He said "The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp." To me that implies that /the/ good languages were /(most of/all) those/ that were designed for their own creators.
Worse, he said "Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++." He explicitly included C++ in the list of languages designed for other people.
Your comment provided interesting historical context, but I'd be more inclined to consider Mr. Naggum's arguments if he didn't send out another email shortly thereafter calling pg names like 'cretin', "lowlives who could not program in Ada if it would save their lives" and "too randomly wired to accomplish anything useful.
For quite a long time, Java was the only imperative language (most programmers can grok imperative faster than a functional language) with garbage collection, language support for multi-threading, a cross-platform VM, tooling and libraries, "without horrible performance". This has definitely helped it succeed in spite all its ugliness.
Python covers all of that with the exception of multi-threading, and according to an internal memo at Sun linked at the bottom of the article (http://www.archub.org/javamemo.txt), it (at least initially) had comparable performance to Java while using much less memory.
PG's comments seem geared towards Java the language. Part of what has made Java successful isn't the language at all, but the Java platform itself and the class libraries. I'm not sure anyone would describe Java as a clean, beautiful, powerful, language, rather one that is solid and reliable enough to get the job done.
I would say that Java was a successful language initially because it provided capability that C++ didn't, and remains relevant because the JRE is an attractive server-side development platform, and hackers have found ways to get around the language's bureaucratic aspects-- in some cases even outright substituting a language like Clojure or Scala for Java.
So I'd say the 'radar' was fairly accurate, but incomplete because it did not consider technology apart from language design.
"On the hacker radar screen, Perl is as big as Java, or bigger, just on the strength of its own merits."
And 10 years later, I know a bunch of hackers using Java, and not one single person, even former perl junkies, that is using Perl for anything besides "it's a little too much to do this in awk".
I met a few people last month who still use it for larger projects. My reaction was along the lines of, "Really? No, wait, really? REALLY? Nuh-uh."
Unsurprisingly, I suppose, I was told that, since I gave it up as a too much trouble, conventions and patterns have emerged that, when followed, make Perl more scalable (in the sense of being usable in the context of large programs) and maintainable.
People get too hung up on languages. I want to solve problems, and I'll use the best tool for the job. I know Java, I know how to use Java to solve innumerable problems very effectively and efficiently, so I'll use Java.
I actually lost some respect for Paul after reading this collection of thoughts.
"The wrong people like Java"
"No one loves it"
"The language was made for people dumber then the creators"
etc.
Ruby was made to be as elegant as possible. There is nothing wrong with that.
And I don't "love" any language, I "love" solving problems. My passion is not coding, it's delivering, and Java has never let me down yet.
People get too hung up on languages. I want to solve problems, and I'll use the best tool for the job. I know Java, I know how to use Java to solve innumerable problems very effectively and efficiently, so I'll use Java.
So is Java the "best tool" for the job because it's the one you happen to know best?
I am just trying to understand the logic.
In my experience, when people say "best tool for the job", they have a set of very diverse jobs in mind.
It's a good question, and I should say I know Java very well, but I also know plenty of other languages too. I used C++ before the rise of the web, and I also took the time to learn Python, Ruby, and other languages as they came in and out of the fad zone.
My conclusion is based on my experience with learning these languages. I'll pick on ruby since that is the one brought up the most. I built several web sites using Ruby (mainly CRUD stuff) and my conclusion after having built around 5 web sites with Ruby (versus 7-8 at the time with Java) was that Ruby wasn't any faster or better at solving problems then Java. In fact, usually it was worse, multitudes of libraries with poor documentation and in many cases no clear standard. The language syntax was novel, but language syntax isn't a step function in productivity, at least not for me.
So I continued using Java as my main language, and didn't feel like I was missing anything by not using it. I learned a few philosophies which helped my efficiency a bit, including the "convention over configuration" ethos from Ruby/Rails (my Java code generally has zero XML files), but the niche features each language was selling wasn't enough to counterbalance the deficiencies in productivity which came from using them.
And I should say Java may not always be the best tool for every job, but I've worked on a wide variety of problems (scalable web services, high traffic content sites, ecommerce) and in each case Java, the language and the platform, in my opinion - delivers the goods.
I presumed that it was a minor think-o and that c2 meant "the best\most appropriate tool in my toolbox". That's certainly what the rest of the comment seems to imply anyway.
While we're talking about smell, does anyone else think the name "Java" is just ugly?
Good products are lovingly named. Despite Gosling's original name of "Oak," Java was picked at random from a list of words. Even the things that touch Java get ugly names like NetBeans and HotJava.
And then JavaScript is toned down to CoffeeScript by the same people who want nicer looking syntax.
The article seems to be "Java the programming language" oriented. I guess PG is right when it comes to that. However, "Java the platform" is as rock solid as it has ever been which is good since "Java the programming language" doesn't really matter anyway.
Though his definition of success seems to be "would really good programmers (wizards) ever use this language for sweet projects? If yes, than this language is a success." By that metric I guess he would be correct.