> 9. It's designed for large organizations. Large organizations have different aims from hackers.
This is where I think pg's bias steered him wrong. Hackers tend not to like Java (although that is less the case now with the JVM ecosystem being what it is), but hackers do not solely determine the success of technology. Furthermore, the type of hacker that pg is interested in—the lisper, the 10Xer, the startup founder—are in limited supply. Certainly they wield more influence per capita, but they still need critical mass to form a stable community around an open source platform in order to compete with large organizations. If you're looking to build a product or a small scale project, by all means find yourself a Grade-A hacker.
If you want to make the next ubiquitous programming platform though, there are other qualities that are necessary. Consensus building is probably the most important skill that large organizations have that hackers will struggle with at scale. If you have a ton of management and mediocre programmers, it's easier to at least get them moving in the same direction, and they'll be more tolerant of the foibles of a designed-by-committee language. Sun had the perfect storm of strong technical talent to design a solid language, but also the large organization effects to market a new platform to enterprise decision makers.
In a way I think pg's smell test might be more valid for an earlier era. He underestimated the influence of the mediocre programming armies, probably because back in the old days there weren't as many and they weren't as mediocre. This is just speculation on my part, but I have to imagine that the quality of the average programmer as declined over time as the numbers and appearance as a recognized career path have increased. I mean how many people were programmers in the 70s because they're parents thought that's what they should go to school for?
Something perhaps worth pointing out: modern tooling (issue tracking, source control, automated tests, continuous integration, etc.) make it easier and easier to extract productive work from mediocre developers, even at scale. One of the things it has taken me the longest to understand in my career is that you can build incredible things with sufficient effort, even if everything at every level is done half-assed.
One of the things it has taken me the longest to understand in my career is that you can build incredible things with sufficient effort, even if everything at every level is done half-assed.
You can, but those "incredible things" have a shit lifespan and they die at unpredictable times, and it costs enormous amounts of money to fix or replace them (in part, because business requirements devolve into the "make it work exactly like the old system" style of project that makes good hackers leave and consultants ask for $50,000-per-week budgets-- in part, because they recognize the unpleasantness of the work and need to hire a team to do it; anyone savvy is going to find a way to collect the benefits while managing rather than doing that kind of work).
Mediocre programmers generate write-only code and systems that work well on launch but start to shake shortly after, like American cars in the 1980s.
Here's another thing. You can get seriously good (1.6+) engineers to maintain Postgres or the Linux kernel, because even though the work is hard and painful (and in the OS world, often gratis) it's an opportunity to learn from excellent (2.0+) programmers who built the thing. What were their concerns, and why'd they solve the problem this way? It's a learning process. But no one good is going to maintain the complexity sprawl generated by mediocre programmers for a typical programmer salary. The market rate for a good engineer to do that kind of work is $500-1500 per hour (because there's no career benefit to the work). Pay less and you'll deal with rapid turnover and evaporative cooling (i.e. the good leave and the bad stay). Or, the typical corporate solution is to put powerless junior programmers (who are not competent enough to maintain a system that is falling apart faster than they can fix it) on that type of work, which prolongs the death spiral only slightly.
I voted you back up because I don't think it deserves the downvote, but here's the thing: mediocrity exists and it gets things done. For you and I who do not wish to tolerate mediocrity our only option is to find work environments that suit our tastes, but we're not going to stop the machine through our indignation.
Plus, even if a company rejects mediocrity in its DNA, a non-technical organization is most likely going to have structural issues that will drive out good programmers anyway. It's possible for a non-technical organization to learn to value and retain good programmers, but there are many factors that need to come together, and statistically I think the majority will never figure it out.
Finally, there's an amazing thing about code is that once it works, it can continue to work in the exact same fashion indefinitely as long as nothing changes. From experience we both know that it's much better to do things right so that you have a maintainable and flexible system that can grow with an organization, but that is not a strict requirement for code to generate value in the short to medium time frames that most companies operate. Just because code is completely unmaintainable, and the cost of comparably trivial maintenance becomes exorbitant, doesn't mean that it doesn't have real business value. We privileged alpha programmers have the luxury of avoiding jobs that have to deal with this, but it's out there and it's a huge proportion of production code (I'd wager it's the majority). In the grand scheme of things it's all good though, nothing lasts forever anyway. Bad code could be one more thing that hastens the demise of an atrophying company, or it could be quietly deleted and replaced by newer systems once it's outlived its usefulness.
there's an amazing thing about code is that once it works, it can continue to work in the exact same fashion indefinitely as long as nothing changes
No business stays the same. All systems have to change, either due to evolving business needs or because the data inside them are growing. The first means bad code getting changed, generally at incredibly high cost. The second puts stress on critical points in the bad code, generally causing unexpected and intermittent failures.
A pleasing fantasy, but a fantasy nonetheless. The world runs on software these days. Everything around you has software in it, at every level: firmware, micro-code, operating system, drivers, server, client, network, etc. And the vast majority of it was written by mediocre programmers. There's simply too much production code in the world for it to be any other way.
Yes, mediocre programmers create mediocre code, and they have a harder time maintaining that code, but they still manage. Often times they have the advantage of money, resources, and people. With enough devs and a reasonable process it is possible to "polish a turd" into something that is functional and feature rich, even if it has a great many flaws.
This is the scary realization that most devs, including myself, have a hard time accepting. The software that your bank runs on? Yeah, that was written by hundreds of devs and if you interviewed each one you would probably only recommend hiring a tiny handful. The firmware your hard disk runs on? Same deal. Also your car's EFI module, your cable modem, your DVR, etc.
I was thinking on this a bit today and I realized that we're actually a little bit better off in the software world, since good software can be copied infinitely. So well written operating system kernels, server applications, libraries, etc. can have a huge impact on the overall software landscape, regardless of how few people contributed code.
But even so, there is still far too much code out there which is the culmination of mountains of mediocrity. It is rather frightening to think about, considering that everything these days relies on software.
You're arguing that the median quality output of programmers isn't raised by good practices, good tools and good management by using examples that feature poor practices, poor tools, and poor management.
Some questions to consider:
Practices: Is the output of the median programmer raised or lowered when all code is reviewed by a senior programmer?
Tools: Is the output of the median programmer raised or lowered when the language includes memory management?
Management: Does management that insists on quality output and backs it up with time or resources raise or lower the the output of the median programmer?
I feel like I miscommunicated and we're talking past each other, so let me try to fix that.
I guess I was reflexively reacting to a certain culture that tolerates mediocrity. Yes, tools are important. Code review, source control (Git, not that Perforce monstrosity), and continuous integration are necessary. For every level of programmer, such tools are necessary, but they shouldn't be used as an excuse to keep trying to nail 100 mediocre programmers together and make them build something. It still won't work.
Modern tools should be used because even great programmers have lapses into mediocrity or even stupidity. Version control has saved my ass on multiple occasions. I would, frankly, just assume that every decent programmer is going to insist on using a version control system.
Practices: I agree with you that code review is beneficial-- necessary, even. It's not enough, sadly.
Tools: Usually, tooling wars end up involving the command-line-vs-GUI debate, so I'll address that and ignore the others for now. IDEs are a double-edged sword. Use them when they make you more productive, but if I can tell that your code was written using an IDE, that's bad on you. I like Google's read-only IDE. IDEs are indispensable for certain types of forensic work but IDE-dependence is just awful.
Management: ok, I agree with you here. Managers who insist on quality and are willing to pay for it are a godsend (and also rare).
I think that that's a fascinating look at it, and yet, I think that the success of small startups, and the ever-shrinking tech company has been a vilification, of sorts. You look at Facebook, and it has been a much smaller company than Google (the most successful company on the map right now, that uses Java widely). Twitter (where that Clojure guy Nathan Marz went) is even smaller than Facebook. Is it possible that language/management choices have had an effect on this? I certainly think so.
I think the verdict should still be out on Java, because I think that the success of Java is dependent on two confluent economic factors.
(1) there's a lot of people who want nice stable jobs, but aren't really pg's type of hackers per se, and
(2) "management" oriented people tend to have big pockets in our present economic environment
But if we remember from economics, competitive markets tend to drive the cost down to the minimum cost of production. You can deploy vast amounts of capital to build a large organization that hires Java programmers, but is it possible to seed lots of small teams hacking in more productive languages, and is it possible for them to create more software that more people are interested in using? Heck, is it possible to use that model to just develop features that bigger organizations might buy out, instead of developing them in-house with the aforementioned armies? I dunno, but it seems like something worth exploring. ;-)
Agreed, that is the reason for my parenthetical. Hackers can love anything useful, and they can find use in anything, and Java with its current ecosystem is incredibly useful.
That said, the nature of Java is not as exciting to hackers in general as more powerful languages like Lisp or Haskell or SmallTalk.
I was going to say almost exactly the same thing. The items that he listed are certainly detrimental from a startup perspective, but for a big company I think that they are actually arguments in favor of Java. Unfortunately for Paul Graham, and his prediction, the big companies have had more say in adoption than the startups. I agree with you. In hindsight, it makes perfect sense. But, it wouldn't necessarily have been obvious at the time.
Personally, I dislike the language wars. I think that a good developer should be able to write good software with the tools available. Arguing the opposite always smacked of the "silver bullet" to me.
In the end, all languages are Turing complete, but there is still a difference. It is similar to woodwork (from the small dabbling I've done in woodworking): good tools make you faster and can produce better output. You can produce the same quality, but it takes a whole lot more effort.
But more important than the tools you choose (Makita vs DeWalt, Chevy vs Ford), getting to know them is far more important. And that's where the language wars seem to fail: the recognition that a guy with 15 years of good Java experience will code circles around that <insert your language here> beginner.
XML is not Turing complete, nor are most configuration file formats. Yet these are used to provide significant behavior. They are are programs. Programs are data. Data are programs.
> I think that a good developer should be able to write good software with the tools available.
While that's true, it would be hard for me to consider someone a good developer if they, given the choice, chose poor or inappropriate tools for a job.
Sure, if you have the choice. But that's were the Hacker News startup culture and the enterprise development culture diverge. In a small startup you can dictate the tools. In an enterprise company you may not have any say in the matter. You can either complain endlessly about it (and boy howdy are people willing to complain endlessly) or you can do your job to the best of your ability with the tools available.
I understand where you're coming from though. I just think that you need to know a lot of context about the developer in question before you dismiss him/her over their tool choices. You need to know why they used those tools and how well they learned them.
But what it really comes down to is how fast the developer can learn something new. I'm fairly confident that I understand enough about programming language concepts to be up and running with a new language in a few days. I might not know the API (if one is provided) but I will probably be able to contribute to the team pretty quickly.
It is very interesting and worth pointing out that in the beginning of the essay says
So, just in case it does any good, let me clarify that I'm not writing here about Java (which I have never used) but about hacker's radar (which I have thought about a lot).
Most of the comments here on HN have been about Java and not about hackers' radars. This is not necessarily bad but it is interesting. I've seen lots of examples of this politics but not on a topic about technology. Does the topic of programming languages have the same sort of emotional sensitivity that politics does?
Coming from a Perl and C++ background, Java was great because the designers dared to remove so many features from the language. In that sense, it made the efforts of the coders stand out more than the features of the language. This is an important message to an up-and-coming hacker.
That said, Java is far from an ideal language. It lacks many features and is somewhat clunky.
It does do a few things right, though. It hits a sweet spot being both simplistic and fast. By choosing a single packaging, developers could use all features everywhere, and start to rely on them. I think it certainly gave a boost to concurrent programming. IMO, Java also drove the acceptance of GC:ed languages.
Now that Java has stagnated, I think that it is time for many old Javaites to abandon ship and transition to new languages. Perhaps it's best to let Java be. Leave it as a historical language that had its glory days. Perhaps someone will admire it for what it's designers dared to do. Perhaps for what it did for the community. Or perhaps new up-and-coming coders can look in those old code-bases and see some retro-style simplistic beauty.
Thanks to Android I've been writing a ton of Java code lately and, with a good IDE, it's not really that bad.
It should steal a few tricks from C# though. If it adopted the var keyword and real lambdas, and something like LINQ, it would actually be a fairly pleasant language to work with.
I think you captured the essence very nicely there: Java is the not-really-that-bad language.
It's not very powerful and it lacks many useful features.
On the other hand, you can do almost anything with it eventually and it's simple enough that stupid syntax mistakes are relatively rare in Java code.
It's a solid tool for a journeyman, and a crude instrument for a master. But most people are never going to be masters, and most of those who will be one day aren't masters yet.
It's hard to love, I agree, but if you were designing something like Android from scratch now what language would you choose? I'm having a hard time thinking of reasonable alternatives. In the long run I'd like to see something like Go or Kotlin become options but really they're too left field right now.
Javascript would be an obvious choice for anything centered around creating UIs. Palm-now-HP's nice WebOS platform is essentially a recent direct competitor to Android and did that.
I really don't think a dynamically typed language is desirable as the primary development language for a mobile platform. Static typing is just too useful and makes it a lot easier to optimize too. Java is still quite a bit faster than JS.
Something like Kotlin seems like a good choice to me, if it takes off.
Java can do pretty much anything that any other language can do.
Sure. That's part of my point. But just because languages are computationally equivalent (cf. Turing), that doesn't mean one is as powerful/expressive as another. I can get things done a lot faster in Python than in Whitespace.
The boilerplate in Java is a huge drag on everyday coding, and Java has weak support for (among many other things) working with functions, text manipulation, and in some cases even basic arithemetic. You can make things work eventually, but sometimes the effort required and volume of resulting junk code is prohibitive for otherwise useful programming techniques. That's an asset if and only if the people on your team aren't up to using those techniques anyway (and can't easily become so).
From what I've seen the last I tried Java, there's another thing as well.
Java APIs are way more clunky than C#
In C# they're usually done in a natural way, in Java you have all this Rube Goldberg machinery to do something simple.
And if you try to tell me "they are much more flexible" I'll call BS because I never seen something that could be done in Java (except trivial limitations) that couldn't be done in C# or Python or something else, probably in an easier way
> In C# they're usually done in a natural way, in Java you have all this Rube Goldberg machinery to do something simple.
I've done my share of C# and Java, and while it looks like true at first, you then notice some dark corners, and before you know it you're looking at System.Configuration or something in Reflector because of some oddball. The next minute you notice you're actually surrounded by dark corners, and the more light you pour on it, the more the maze reveals its complexity.
Those may be fine languages for some people, but for me both feel like some terribly grinding noise in my head, similar to Pyramid Head's blade[0]. Not being dismissive, this is just my "radar" lighting up in some (painful) way.
I have to say, yes, sometimes there are such issues. I remember some localization function having these problems.
But then again, difficulty should be staged, the most common cases should be the easiest, and yes, even if you're doing something off-beat you should avoid going into dark corners.
There's the utterly retarded getter/setter convention, which while it's the most trivial thing must have wasted billions of programmer-hours by now. More generally I think the existence of a bunch of autogenerated java code (WSDL etc.) has lead many java programmers to write APIs that look like they were autogenerated, for consistency, rather than writing APIs that are actually nice to use.
That's a little unfair. The "Type getX(); setX(Type t);" convention to define a "property" dates from 1997, long before anyone was autogenerating Java code. And frankly at the time it was a revelation. People who were used to writing junk like CORBA IDL suddenly saw this "beans" API using "reflection" to detect this stuff automatically, with no assistance from the programmer except adhering to a simple convention. Really, this looked amazing at the time.
But obviously it's been improved. Managed runtimes (and especially more dynamic ones like Python or Ruby or Javascript) have become the norm. The idea of inspecting the metadata of an objectat runtime is no longer so strange. So when C# or Ruby decided to implement the same kind of property interface they felt comfortable taking a few more risks.
Also, the zeitgeist has moved and values different things than it did in the 90's. At the time, clarity seemed like a valuable goal (especially in comparison to C++), so Java preferred a write-it-out-longhand style where types lived in com.domain.subdomain.module.submodule.MyClass namespaces and all the APIs were multiWordCamelCase() things. And this was intentional, and believe it or not people liked it this way. The advent of Rails and DRY (re-)popularized the idea of a "terse" API, so Java's more verbose stuff looks clunky and "bad" to modern eyes in a way that it didn't.
Basically, don't hate on Java. It was good in its day. And it sits in a more important place in history than I think you give it credit for.
Yeah that's the other thing I forgot to mention that Java should steal from C#. In my own code I often just use public members but even with auto-generation in the IDE the getter/setter thing is gross.
I like Java - and I say this as someone who mostly used Python for the last 10 years (I learned other languages for fun, but did most "productive" work in Python).
My main issue with Java a decade ago was all the bloat in the framework. Want to write a Web application? Just use J2EE and write a few factory factories. Or use the "lightweight" Spring alternative, that allows you to write plenty of XML code.
This bloat got much better during the recent years and a number of sane frameworks have evolved. Want to write a Web service? Use Dropwizward. A Web application? There's the Play framework.
Java as a language is pretty nice. Yes - it has its warts, but the language is relatively simple to understand and isn't missing too many important features (Lambdas would be nice). In addition the type system really helps a lot when having larger codebases. Yes - it's not perfect (type erasure, ...), but it mostly does its job.
"Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp."
Dazzling argumentative prowess. If I wrote that, I'd be called a troll and downvoted for senseless flaming.
Historically people making baseless judgements like that have been proven to be wrong.
I suppose it depends on your perspective. Obviously many orders of magnitude more useful code has been written in COBOL and C++ than in Smalltalk and Lisp. If the designers of COBOL and C++ set out to make languages that other people could use, then they succeeded spectacularly.
11 years ago pg's audience was much smaller, internet culture was blunter, a good flame war was appreciated, and the term troll wasn't bandied about quite as freely.
No, he's right. Now, Java is not such a terrible language. On a 1-to-10 scale, it's a solid 5. (5.01? Can I make that joke?) It's unpleasant and verbose, but the early Java community had real language designers, and even some heavyweights, behind it (including Odersky, designer of Scala) and believe me, they've made more good decisions than bad ones. (Language design is hard, yo.) They got Unicode right in a time where expert language designers had their heads in the sand on that one (UTF-16 is annoying, but it's a hell of a lot better than byte arrays and strings living in the same type.) However, Java was inevitably hijacked by the "commodity programmer" culture where businessmen make decisions based on risk-limiting amid mediocrity rather than clearing barriers and allowing excellence (as well as a few non-starters, cf. Paul Graham's notion of "Black Swan Farming") to shine. It's not a fun language to use, and the community that has grown up around it since its inception has shown bad taste (J2EE, Maven, Eclipse). But for a period of about a decade, Java was the best (if not only) choice for a variety of problems.
Also, Java managed to succeed in the enterprise by feasting on Cobol's corpse, but it built up a Detroit: a good-enough but unattractive infrastructure that thrives when people have solid economic reasons to care about it, then is abandoned rapidly when the context changes.
Groovy, Scala, and Clojure came out of an interesting insight: there's some stuff in the JVM ecosystem that's too valuable to abandon just because the Java language is (albeit slowly) dying. It'll be interesting to see how these languages evolve in the next 15 years. Clojure is (IMO) the best Lisp, and Scala is exciting as well... but there's a lot of cultural legacy to deal with (there's plenty of bad Scala code being written by recently-promoted Java programmers; most of them will improve massively as they get a hang of the language, I hope.) Step 1 is to either improve or fire the FactoryFactory crowd in its entirety.
Java got unicode horribly, horribly wrong; assuming everything will be in the BMP is like assuming everything will be ascii, only harder to spot in testing.
It got some things right; threading (even ten years on Java has a more reliable thread model than tcl/perl/python/ruby), strong typing (not much use day-to-day, but incredibly valuable for building extensible libraries that can nevertheless be evolved without breaking existing code), maven.
I think it achieved the enormous success it has mostly by being a conservative, incremental improvement over C++ and Cobol. A lot of things introduced in later versions of java were things other languages had been doing for years, but an unwillingness to adopt unproven techniques is the best thing about java. I don't think it even is the best choice for any given problem - it's just that in a real world of mediocrity and turnover, java makes it possible to produce reliable, boring code with minimal risk.
The unicode consortium got unicode wrong, not java. At the time Java was created, there only was a BMP and Unicode had a purely 16-bit design. Therefore, it was perfectly reasonable for java to assume a 16-bit char. Unicode was later extended to support more than 2^16 characters, but that was after java was created, hence the need for UCS-2/UTF-16
Other languages which strongly value backwards compatibility and were created around the same time have the same issue - e.g.: C#/.NET, i believe python as well
Java got some basics very, very wrong. First-class object iteration, list comprehension, string manipulation...either these features are nonexistent or feature brutal syntax bordering on the hideous C++ container class verbosity.
I think the introduction of lambdas will ease the pain with the first two. That is, we can add weak syntactic support for first-class iteration and list comprehensions -- both are monadic features, and though Java can't express a general monad, it can bolt the monadic features on as a design pattern. So none of it will be pretty, but it'll be better than the current situation.
I'll say it ... I love Java (and I'd been hacking in a for a couple years when PG wrote his article).
I came from an embedded systems background and treated the JVM as my machine. I read and understood the JVM specification, and then the language specification. By that time it wasn't any different to me than writing for a uP or uC. At that time, Java was a fast-growing eco-system and our JUG met twice a month to keep up.
While this was happening, I knew a lot of people like PG who did judge the book by its cover (and there were parts of the cover I didn't like). Don't be so hard on him as he admitted he never cracked it open.
Out of curiousity, have any of the YC start-ups used Java? I'm curious whether he's still biased against it. (We can count JVM languages for half points).
PG explicitly states in the essay that it's not that much on Java itself but rather on the way hackers judge technologies (the "hacker radar" in his expression).
And these are not quite predictions but statements on how Java is (or was then back in 2001) perceived.
And I think, IMHO, a substantial part of the Java success today should be attributed to the JVM, not so much to Java, the language. Clojure/Scala/etc. are kind of clues for this.
No hard numbers, but I'm sure most Java implementations are still running Java the language. IMHO Java's success today is more because of corporate inertia than anything else. Kinda like how COBOL still has users in this day and age.
It also helps that it's one of the languages being taught in CS classes.
I work in a very large company that has primarily Java for web apps and back end processes in COBOL/Mainframe environments. I've been steering things towards Groovy or Ruby for new projects, largely using productivity as the justification. Top push backs from upper management have been:
1) Universities we recruit from teach Java & most prospective employees already know Java
2) Costs of retraining workforce
3) They don't understand those langs can be utilized with our current JVM ecosystem
I feel pretty much all those reasons are specious and really shouldn't be holding things back. We've got a foothold established with success of some smaller projects using Groovy and Ruby to "prove" their viability. I'd like to try Scala next to see how it would fit for some of our other projects.
TLDR: At least one large company is making efforts to evolve beyond just Java in the JVM.
"IMHO Java's success today is more because of corporate inertia than anything else."
I don't think so. Java as a platform is a lot easier to manage than most other platforms, including Ruby and Python. Jars, in my experience, are much easier to deal with than Gems. Java has a set of advantages that aren't really replicated elsewhere. It's garbage collected and portable, but executes much faster than other garbage collected and portable languages.
Java and the JVM ecosystem strike me as very much like the programmers "Golden Path". That is (for those not familiar with Dune), Java represents a sort of "forced peace". Yes, things work. Yes, tools are available. Yes, there is decent, even good, documentation.
No...nobody's happy about it. But then Java also bred the JVM, and today we have "the Scattering" (another Dune reference), where hackers, honest-to-goodness hackers, have spread out from this forced peace to build a new world. One that, while it will not be as peaceful as the uniform world of Java, will ensure that the JVM remains relevant long into the future.
I always thought the Golden Path referred to the continuing fate of the human race and continued after Leto's death, not referring just to his forced peace.
Still, I'm impressed that you managed to work a Dune metaphor into a Java discussion...
I don't think that Steve Yegge quite got his conservative-liberal categorization right, but I think he was on to something. And you're a flaming liberal. As another flaming liberal, I completely agree with what you said. But I am weird about trying to see things through other people's eyes, and I can see why others might not agree. Particularly if they are towards the conservative end of the scale.
For those who don't remember offhand what Steve Yegge said, https://plus.google.com/114613808538621741268/posts/fnhfBGry... gives you how I would draw the distinction. Basically conservatives are willing to put up with ceremony to get benefit. And liberals avoid ceremony.
My categorization of pg is because his top desires for code seem to be that it works acceptably well, is short, was fast to write, and is easy to change. None of these goals are compatible with having much excess ceremony.
I don't think it has much to do with the liberal-conservative distinction. I'm at the conservative end (Clojure, Haskell) and prefer a lot of liberal languages over Java.
The languages that you just named are in the case where Steve Yegge and I would disagree about categorizations. Steve looked at them, looked at the kinds of guarantees that they provide, and concluded "conservative". I look at them, and notice that people using those languages don't actually go through a lot of ceremony to get those benefits. Thus they can attract people who by my definition might be anywhere in the political spectrum.
My guess would be that you don't like having a lot of excess ceremony. If so, you'd be a liberal by my definition, and would prefer liberal languages over Java.
You're in a better position than I am to say whether that shoe fits, or whether you think that my attempted categorization criteria is entirely bunk. Either way, I'd appreciate feedback because I'm always trying to improve the ways that I understand the world.
I can see good reasons for every position on Steve Yegge's spectrum. But i have a way harder time seeing a good reason to be conservative on your spectrum. Which makes IMO Steve Yegge's spectrum better for value neutral discussions.
To me your response justifies the way I look at the world. The whole point of seeing things as "software politics" is to try to divide developers up into groups who each thinks that they are so obviously right that no justification is needed, and think that the others are so obviously wrong that you don't even know where you'd begin a discussion. And once you know what pressure point divides them, then you can actually try to start a productive discussion.
Speaking personally, I would die in an organization like that. I can look at it, see what's at stake, can accept that they are doing the right thing for their problem. But I am very glad that I can find things to do where the cost of smoking out the very last bug in my software is not as important as the profit from making the next thing that I'm going to make.
When human lives or expensive equipment are at stake then it makes sense to be software conservative by your definition.
But for these kinds of requirements Java is way to lenient.
I have been developing Java since 1996. I have a written a lot of Java so I'm probably a pretty strong example of a Java developer. I'm an above average developer (and that might be generous) but not much of a hacker.
So let's get to it.
Is Java clean and beautiful? Sure, it's easy to read and just about anyone who has read any other language can figure out what's going on.
Is Java powerful? You can do just about whatever you want with it. Early on it was pretty tough to get to the native level but that has become less of an issue over the years. It still doesn't do graphics all that well so it's never been a great option for game development.
Do people love programming it? Programming is tedious work and good languages help reduce the tedium. I'm not sure Java reduces the tedium enough, it may even increase it. But this is what makes it cleaner than other other languages. Sometimes the tedium that it doesn't reduce is how others can come in and know what I was thinking then I developed it. However, POJOs with getters and setters are tedium no one explicitly needs.
I'm currently working on a new project (in Java) that I found I was building more classes than I felt I needed. A lot of getters and setters, object managers for each object, DAOs for each object, and each object itself. All that before anything even makes it into or out of a database. I thought if it would be easier in any other language and the answer was yes, but only temporarily. Once this boilerplate stuff is done I would have a very robust application that is easy to refactor if necessary and just about anyone can add to it will little trouble.
That said, I've been meaning to try out scala and python. I tried ruby but found it a little too young (but that was a couple years ago). I also said I'm not much of a hacker so I tend to spend my free time doing things other than development. I'll probably get around to learning those languages right after I learn to play the piano and can speak fluent German.
>Is Java clean and beautiful? Sure, it's easy to read and just about anyone who has read any other language can figure out what's going on.
Easy to read? What? Let me do a simple comparison. Let's say there's a site, ycombinator.com, that wants to ban anyone who posts "First post!" on a story. Here is what the python code would look like:
if "first post!" in comment.text.lower():
comment.user.ban()
Here's what the Java code would look like:
public static void class PostPunisher extends PostHandler raises Exception {
public void PostPostHook(Comment comment) {
if (comment.text.to_string().to_lowercase().contains_substring("first post!")) {
comment.User.Banner.execute();
}
}
}
Well, I left off a few factory factories there, but you get the picture.
Java doesn't require a class, it doesn't require a method, it doesn't require a factory. There is literally zero difference between the python example and my Java example except the syntax between the languages.
You just felt the need to unnecessarily obfuscate the code to suit your argument.
I believe my last post clearly showed that I disagree.
There is no 'boilerplate' required with Java. Anyone can obfuscate Java, or any language, and make code that is overly and unnecessarily complicated. Some do it because they don't know better. Some, like yourself, just do it to be an ass.
I wasn't doing it to be an ass. Even if you are allowed to manipulate the class function you're dealing with (and so spare new classes), most java code does look like the example I gave: lots of verbiage, having to create special classes (including [verb]-er classes). Very, very unpleasant to read, and not big on beauty either.
One of the reasons that I really like the Groovy language as an alternative to Java is that it's features often save you typing (for example getters/setters on a POJO) but still allow you to get in and override the default behavior. So it increase productivity, and reduces pain without reducing the expressiveness.
It has fewer keywords than almost any other language, and the overwhelming majority of its library is written in pure Java.
It has warts, like the way closures are broken, and the lack of map-literals, some native syntax map stuff would be nice too. Functional programming with lambdas, etc is in fact possible (and awesome, passing around Callables through java's excellent concurrency libraries is quite elegant once you get past the ugly syntax).
Most importantly, it's IMO one of the best languages for team projects, the verbosity that people lament turns into a huge asset when you're reading other people's code. The interface system they have isn't quite as good as Go's but it allows really powerful abstractions as long as you don't go down blind alleys of implementation inheritance from your OO 101 freshman year.
That said, the JVM aside, Go seems to address all of its sweet spots a little bit better. Their only lack is some sort of generics and I'm pretty sure that they've delayed implementing it precisely because of Java's ugly edge cases in generic usage.
And if you're talking about EJB or any other enterprise monstrosity, sure, that sucks and is the exact opposite of 'clean and beautiful'. Or performant or any other positive adjective.
Really, it just isn't. I spent about a decade starting around when this essay was published writing Java. There are some obvious analogs between Java's design and the industries it's found a stronghold in. It's a language about prioritizing risk aversion, and thrives in organizations obsessed with the same.
If you were to design a programming language inspired by a large government bureaucracy that has much more machinery in place to not get fired or sued than it does to get work done, I imagine it would look a lot like Java.
As such, Java is a very useful tool for allowing large teams of average or even below-average programmers to produce serviceable products.
Of course that statement is terrible flame-bait, so let me be clear: That's not all Java is good for, and I'm not describing all Java programmers. Not by a long shot. I'm also honestly describing this as an asset to Java, and in my opinion the asset that's most responsible for the success it's enjoyed.
As a programming language for building things, Java is probably the worst example I can think of among languages and platforms that have experienced any popularity over the last decade or so. The amount of scaffolding required to express an idea is staggeringly off-balanced, and points at Java's primary concern: to avoid problems. Reading a Java program is an exercise in trying to extract what the programmer intended a program to do, while laboriously reading through all of the more-obvious things that the programmer intended the program NOT to do.
These things come in the form of a lot of ideas that aren't at all bad on their own, but coalesce into a symphony of painful excess on the axis of generalizations, exception handling, type declaration, contract validation, and data conversion.
A colleague of mine (who programmed embedded C) once reviewed a large Java commit of mine and commented that it seemed like 90% of my code was spent handling exceptions or converting data from one type to another. He was right, and though this is likely to be debated.. it's not because I was a bad Java programmer, it's because I was a good one.
In over a decade I think I met only one person that I think felt especially expressive in Java, and even he wouldn't use it for lots of everyday things that it made particularly painful (dealing with the filesystem or building web applications come to mind).
My personal opinion is that most people who say they love programming in Java love programming and either haven't invested in an alternative enough to know better, or find the particulars of a programming language a rounding error in the calculus of what they enjoy about programming.
I was in the first category, and God bless folks in the second. I envy them.
I don't think Java is beautiful, and would give it an average rating on being clean, but having worked on projects with both small & large teams in multiple languages, I think its one of the best languages for large teams. Its also much easier to assimilate new team members in a large Java project compared to other languages[1], primarily because of static typing and inferencing capabilities that modern IDEs provide. I suspect this is why Google uses it extensively.
For my personal tinkering, I prefer Ruby and love its meta-programming. But I wouldn't use it for a project if the team size is going to exceed 10. Writing Ruby like you write Java will work but doesn't count since the advantages of Ruby are wasted.
[1] Try diving into the source code for Rails/Django compared to a large, well-written Java project (the only ones I can think of right now are Google-internal, sorry)
I spent some time with Java this summer after several years of Perl, Python, and Common Lisp. I found Java - like Common Lisp - designed with obvious care. It had a clean design which was even, in a strange and minimalist way, beautiful. What it wasn't was powerful.
I thought it took a lot of shoveling code to get anything done, and that was fairly unpleasant to deal with.
I think that if I was starting a greenfield project for a 5+ year codebase which would have to be fairly reliable, cross-platform, and not a Lisp, I would have to choose Java and build my own frameworks for abstractions.
I'll certainly take it over Haskell any day. And Perl, or Lisp. And I love static typing. The ugliness comes from the myriad frameworks that have sprung up for it(metaprogramming in XML, good god).
Very true. Most of the hate for java is actually because of the frameworks. But Play framework has made java web application development fun again. Also I find static typing very useful for large projects. Even though I go to python for small programs (file handling, quick database insert), I still go to java for large projects. What I miss in java is the succinctness of python(like list comprehension). But I still don't want to loose static typing. I thought scala was the answer. But I was not impressed when I tried it.
I like Python too, the dynamic type system and performance hit are the only things that might discourage me from using it for a big project. Go might be worth checking out, it's supposed to give you things like first class functions in a compiled language.
That's the really interesting bit--it isn't. Most of your points are mostly correct. But that doesn't stop its being popular.
This shouldn't surprise people either; sitcoms, junk food and package tours are also very popular. More generally, quality is very rarely positively and consistently correlated with popularity. And yet, in the sphere of programming languages and operating systems, it seems people assume that it does correlate.
Please don't base your choice of technology exclusively off what most people use.
If anything, it was more popular; in 2001, Java was the "modern" mainstream choice for backend in financials and enterprise L.O.B. applications, where today it's simply the incumbent choice. People forget that Rails was a primarily a reaction to J2EE's hegemony over "professional" (to use the closest word I can think of to describe the concept) web backend development.
A significant fraction of our enterprise clients today are entertaining a new "modern" platform to supplant Java, like Clojure (in finance) or Scala (in startups). Maybe it's not occurring to people that Clojure, Scala, and even Groovy weren't options in 2001. It was Java, C#, or PHP, or Perl, or C/C++.
let me point to a comment made by PG yesterday when asked by thaumaturgy what it's like to have your every written (or spoken!) word analyzed by a bunch of people?
It's pretty grim. I think that's one of the reasons I write fewer essays now. After I wrote this one, I had to go back and armor it by pre-empting anything I could imagine anyone willfully misunderstanding to use as a weapon in comment threads. The whole of footnote 1 is such armor for example. I essentially anticipated all the "No, what I said was" type comments I'd have had to make on HN and just included them in the essay.
It's a uniquely bad combination to both write essays and run a forum. It's like having comments enabled on your blog whether you want them or not.
Maybe we should be discussing the future of finance, crowdsourced funding, new programming paradigms or some other interesting forward looking stuff instead of spending our time looking backwards trying to poke holes in an essay written more than ten years ago.
While I usually agree, in this case I found it a very interesting. pg is a very influential figure in many business circles, but for a lot of people on HN, pg is a very influential hacker, who has thought a lot about hacking and the software creation business, and has very graciously let us look into those thoughts. From that lens, this is a very interesting article.
I personally think this article makes great predictions. Obviously, Java has since become an incredibly popular language. But I still think there are many people (including me!) who have the same beliefs about Java as are shown in the article. Many people consider it a much more "business-y" or "bureacratic" language than, say, Python/Ruby or many others.
pg never said Java would be unpopular. He dismissed it much as he dismissed Cobol and Visual Basic. In 1990 Cobol was the most popular programming language in the world [1]. And in 2000 Visual Basic was the most popular programming language in the world [2].
The essay is about hacker's radar, not Java, anyway. Personally I loved his list of other technologies he has ignored.
From the article: "So far, Java seems like a stinker to me. I've never written a Java program, never more than glanced over reference books about it, but I have a hunch that it won't be a very successful language."
I think that pretty clearly says that (at that time) he didn't think it'd be very popular.
So, you think popularity is success? I think that when Paul says "success", he means "winning" in an old sense that "those who adopt X have a better chance at winning" whatever it is. Just because the language is widely used doesn't mean it's contributing to the success of the adopters.
So how would you propose measuring "contributing to the success of the adopters" ? It seems that there is no way to either prove or disprove the statement hence any statement about the "success" of a language could be claimed as valid/true.
>So far, Java seems like a stinker to me. I've never written a Java program, never more than glanced over reference books about it, but I have a hunch that it won't be a very successful language.
I could go through and dispute his points one by one in traditional internet style but to do so would be to miss the fundamental difference in viewpoint. A piece of art can be considered aesthetically unsuccessful while still being a massive commercial hit.
The liberal hacker will generally consider Java (if not the JVM) a failure.
The conservative software developer will generally consider Java (and the JVM) massively successful.
So if PG was considering the market success of this "stinker" then no, his prediction was clearly a failure. But if you consider the aesthetic success? Well, Java certainly isn't cool in certain circles.
Personally I like Java and consider it successful - but I don't think PG's article is prima facie a prophetic failure.
Java was an incredibly popular language in 2001. I had been using it in commercial apps for four years. It was around 2001 that I was managing a development team and was introduced to Python. About that time, I also began to realize how expensive Java development was and how many more interesting ideas were happening in other languages.
While it was clear Java was popular, it was also clear it was stagnating under the beurocracy and the weight of its corporate champions (small changes and backwards compatible at all costs). It also became clear that there weren't going to be many repeats of Java's initial ideas.
On the insights, I probably give Java more credit for than pg would because they pretty much all exist in lisp, but Joy packaged them for "easy" consumption. Arguably, the most important was the JVM and the notion that bits didn't need to run on the metal directly. This was well known to the lisp and smalltalk communities but shunned more generally, but Java made it acceptable across the computing ecosystem to run in a VM. This really opened doors for languages like Python and Ruby. It would be interesting to know if they would have been as popular without Java and it's corporate marketing machine telling developers VM are good.
I am not disputing the fact that the idea of virtual machines was popularized for a new generation of developers by Java. However it goes back commercially a lot farther than I think you, or most software developers, realize.
IBM started shipping mainframes where everything ran inside of a virtual machine 40 years ago this year with VM/370. Its purpose was to emulate previous IBM hardware running a previous IBM operating system. People today are able to run applications written in the 60s mainframes without change in part because the radical changes in underlying hardware have been hidden from them by layers of virtual machines.
Of course there are many predecessors. After all Lisp has been running in a virtual machine ever since the first one, in 1957. But IBM is the first instance that I know about where a company shipped machines to paying commercial customers that wanted to run software inside of a virtual machine.
1. "Haha, what an idiot. He said Java will die and now it is still there, hahahaha." (obviously, an contrived example). This would be an useless "discussion". We wouldn't learn anything from it.
2. "Well, as he writes in the essay: predictions are hard. Let us check which predictions did hold and which didn't." - This discussion could provide useful lessons for the future.
I hope for the second, but fear the first. In a few hours we will know the answer.
As I mentioned elsewhere, most of pg's observations still hold in 2012. But, he clearly missed the implication, as you mentioned in point 1. I believe Java is still going strong precisely because of the attributes he regards as weaknesses (that it appeals to suits and programmers in suits; that large businesses like to use it; that its syntax doesn't try to be revolutionary)
Based on this, I will boldly make the following prediction: in 10 years' time, the most popular languages will still be some variant of Java and C#.
> Based on this, I will boldly make the following prediction: in 10 years' time, the most popular languages will still be some variant of Java and C#.
Your conclusion may very well come to pass. This reminds me of another article, Beating the Averages, in which pg writes: "And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg."
1980 "You use C? You suck. Real programmers use Assembler."
1990 "You use C++? You suck. Real programmers use C."
2000 "You use Java? You suck. Real programmers use C++."
20xx "You use ...? You suck. Real programmers use ..."
Same story, different times.
At least try to provide an argument for your position, instead of "(...) will be still be dumb". Thanks.
Intelligence (at least IQ-measured intelligence) is normally distributed with 100 at the median. Some people equate "dumb" with "dumber than them". If such a person is 1 or 2 standard deviations above the median (as I'd assume the population of HN is), then most people could be considered "dumb".
Before the assembly line, workers had to be skilled, had to really understand what they were building and how and why all its pieces fit together. With the advent of the assembly line, workers were only required to learn one specific, usually very simple, skill. That made them cheaper to train and cheaper to replace and made the outcome of their work less important to the end product. That also made them easier to manage by people who were not skilled artisans, giving rise to the "generic" manager, who only needs to know how to manage. Java is a very good "assembly line language" and it's no coincidence it's popular with businesses that don't value elegant code as much as code that gets the job done cheaply.
I'm not saying it's impossible to write elegant Java code. I'm only saying it's cheap to write business-y Java code and that accounts for a substantial part of its popularity.
At the other end of spectrum, you have projects like GNU/Hurd, which are extremely idealistic and hence barely ever ship. The accounts department is not going to like it very much when you tell them your new Lisp DSL variant with metaprogramming is delayed for half a year due to technical difficulties in getting it right. The VP/Director/Team Lead(and whoever else okayed Lisp) will get a pink slip and the replacement(s) will build the application in Java.
Even if it works, good luck finding any Lisp hackers to hire in your local area. Who is 'dumb' and 'smart' in this scenario? Is it just IQ levels that matter? What about getting the job done quickly and cheaply which is very important to the business? Do you get a big competitive advantage over your rivals by having your accounting system run on elegant Lisp vs. Java or PHP?
We techies, especially academics tend to carried away easily and want functional or otherwise idealistic languages replace other 'dumb' languages, but the corporate world works in a very different way. Throwing around phrases like dumb, and IQ levels actually degrades the argument to 'we are superior than them' and nothing else. Characterizing people trying to be practical and put food on the table and take care of their families as 'dumb' is just douchebaggery.
> With the advent of the assembly line, workers were only required to learn one specific, usually very simple, skill.
I think a lot of the benefits came from automation. An artisan working alone cannot afford the machine tools and jigs to accelerate his work. The assembly line is actually about the centralization of capital and economies of scale, not the deskilling of the workers. In fact, modern First World manufacturing suceeds by firing as many unskilled workers as possible and replacing them with engineers and skilled technicians.
I would say that Java shops value elegant code very highly—in the tools and frameworks and OSes. The front line Java coders are business software's version of sheet metal and rivets.
Paul Graham's meaning of "is dead" is "has stopped producing exciting ideas". He declared Microsoft dead in the mid-2000s. He wasn't saying "no one uses Microsoft products" or "Microsoft is out of business" (both demonstrably false) but that it was an evolutionary dead end. So far, he's been proven right. If Microsoft ever becomes a company worth caring about, it will be a different Microsoft from what it is now (cf. the parable about never stepping in the same river twice).
He was wrong if his prediction were taken to apply to the JVM ecosystem, because Groovy and Scala and Clojure happened, but he was right about Java-the-language (it has limited uses, but you should be using at least Groovy if not Scala or Clojure for modern JVM development) and undeniably dead-on about Java-the-culture (which is the only thing he claimed the ability to evaluate, having admitted not using the language ever).
Have you used any of these languages? The Wikipedia list is overly simple at best.
The common thing that these all share is easy access to the world of Java code, much of which is very well written. The Java standard libraries are well-written and well-documented. There are plenty of high quality open source projects covering almost anything you need.
I am most familiar with Groovy and it is much more than a simple scripting language. It spans the continuum from scripting to full-on enterprise-level stuff. It adds all of the functional features we love to Java, language support for maps, makes it easy to create DSLs for specific purposes, etc.
I do not know nearly as much about the other languages, but almost all of these are in production use. I would recommend many of them.
Scala and Clojure seem to have gotten a definite traction. Just from reputation alone, I'd choose Clojure for a JVM greenfield project if I was asked to do such a project.
>Paul Graham's meaning of "is dead" is "has stopped producing exciting ideas"
Not really, he came up with his prediction:
"I have a hunch that it won't be a very successful language"
Java not just took off like a rocket, but .NET/C# (which built on top of Java) has encountered even more success, so much that companies collectively pay billions a year for Windows Server 2003/IIS/SQL Server while Apache/Tomcat/Php/MySql/PostGres/Ruby are free. You can say Microsoft takes most of the profit in the web server and server OS market (like how people say Apple takes 80% of the profit in the phone market).
How do you consider .NET and C# built on top of Java? They're certainly designed a direct competitor, with C# + .NET built to check every box that Java + JVM does, but most of the things in common between the two weren't new in Java.
In the years since, new C# features have diverged sharply from Java's.
There's nothing bad about being wrong sometimes. On the contrary, it's a good thing, it shows that it is very difficult to have a very accurate view of the future, no matter how much of an expert you think you are or other people think you are. That's the same kind of thing as the time capsule of the sci-fi writers that was unveiled recently: most of them had a very false vision of the future, because there are simply too many variables that make it impossible to compute.
I don't think what mixmax (or pg) was saying really had much to do with "being wrong" but more "being analyzed by people who already have a bone to pick". The result is that you find yourself not wanting to say anything at all. Alternatively, when you do, trying to be very very very clear about exactly what you are saying as it will give someone else "a weapon in comment threads" that won't just be used against you once, but might come up again eleven years later: the same statements, which causes a kind of ludicrous level of hedging and difficulty (as people might have understood it in context at the time without problem, but will anyone appreciate it eleven years later? in this "discussion", for example, pg has already had to remind some people that Java was already a quite popular language in 2001, and thereby that it still being popular now does not contradict much of what he was saying).
> a hunch that it [Java] won't be a very successful language
He lists COBOL as a bad language - but it's been very successful. So I think he's not really writing about "success", but about what hackers like. Interpreted this way, he's accurate: hackers don't like Java.
Businesses like investments that keep returning value - for languages, that means compatibility and portability. Hackers like to change things - expressiveness and power. Java code from years ago still works; it's also portable across machines and OSes. In contrast, ruby broke my simple toy code, after just a few months, in a minor point-release. Similarly, I believe there are many incompatible versions of lisp, and many hackers write their own libraries rather than reuse, so there's little standardisation. Different things are valued.
So I agree with pg's theme that if businesses like it, hackers won't. (There's some factual inaccuracies in the rest, but that wasn't his point.)
I'm probably going to get flamed for this but I think even for it's time, it's wrong on a few accounts and it stinks of elitism and an "I am better than thou" attitude rather than a discussion on relative merits or the preface which was slapped on to change the context. It sounds like it's written by someone who's comfortable status quo is threatened.
Ubiquitous readily available knowledge is power, not elitist hackerism...
I've always felt that it's a language designed to help eliminate the worst of programming, which has the side-effect of limiting some of the best programming.
So great for big businesses, but poor for hackers wanting to do cool stuff.
First off I must say that I like reading about past predictions. It can provide insights into how well current predictions may pan out in the future.
It interesting that all the points made 11 years ago can still be made today, with the exceptions of #1("It has been so energetically hyped") and #8("It's pseudo-hip"). I guess it's true that the more things change, the more they stay the same.
That's one I hadn't read, although sadly I agree with much of it. As one of the people who worked on the 'LiveOak' project which was the final, and presumptively last gasp, of Java before Sun 'redeployed' all of us, there was this really modest view of what the language was. And then it was released and folks started saying "Gee if people deliver programs in the browser, and Sun owns the language/environment of the browser, they are going to freeze Microsoft right out of the market, brilliant!"
Except nobody who was actually a part of the Java group said that, they said "Gee you can push a chemical molecule viewer to the browser at the same time you push a model, that will let you publish stuff without having to wait for browsers to 'catch up'"
Sun corporate had their own ideas though, and seeing it as a way to 'attack Microsoft' (which looked pretty unassailable in 1995) and a lot of other people were feeling the same way, and the language got hijacked. That was a sad thing indeed. I feel sorry for the developers who create a technology that is perceived as the way to 'kill Apple' or 'kill Google' since it will be very popular and ultimately corrupted by those who would seek to use it in that role. I have the misfortune of having worked on something which Sun tried to kill Microsoft with and Oracle tried to damage Google with. 2 for 2, yuck.
So if you can separate the language from the politics, there is a lot to like, it has been influential in a number of positive ways. But the taint on the language from the politics will be its most enduring legacy I suspect.
"No one loves it. C, Perl, Python, Smalltalk, and Lisp programmers love their languages. I've never heard anyone say that they loved Java."
I love Java. I loved Smalltalk until 1996, then I read Java White Paper and VM Specification and I fell in love with Java and I am still loving it more than any other programming language. I programmed in Basic, Assembler, Pascal, Oberon, C, C++, Smalltalk, Perl, PHP, Python, Ruby (on Rails) and used many technologies. Smalltalk was my love from 1992 until 1996...
I could write a lot about why do I love Java. If somebody is interested, I can explain...
"People are forced to use it. ... if the technology was good, they'd have used it voluntarily."
I am using it voluntarily for all my projects more than 15 years now. I even migrated all my programs from other languages to Java... I am regularly checking new programming languages - recently I tried out Dart and Go - and I still can not find a better programming language for me... Java is still Nr. 1!
I built a new programming language in scheme, wrote a compiler in C, map reduces in C++. I hate struts, hibernate and all shitty enterprise frameworks but I can proudly say that I love Java. I have used it for Speech synthesis, Image processing, Machine Learning, NLP and of-course Search. It's awesome.
Java is horrible for prototyping, it's designed for large environments where management of complexity (through interfaces and some level of top down design) is desirable.
It's not a hacker language.
PG makes a very good point though - that today's teenagers (hackers?) are tomorrows CEOs. But not everyone can be above average, not every CEO can be of a technology company, and eventually those CEOs need to hire average programmers to do basic enterprise information systems work.
Scala on the JVM with play framework is looking pretty agile these days too
The only prediction he made is that he would personally not like to program in it and that he could safely ignore it. I think that prediction has come true. He ignored it and that had no detrimental effect on him. Not ignoring it would probably not have had a benefit.
He didn't say that Java will die, that some people won't benefit from it, that useful things won't be made from it.
It's way too large for some good not to come out of it.
I've become really fond of Groovy during the last weeks. It's compatible with the huge number of existing Java code but more terse. Also its defaults seem more pragmatic, e.g., "==" comparing Strings by value or implicit setters/getters.
And version 2 promises Java like performance (and type checks) for statically compiled code.
Another thought just struck me - a friend was relaying his thoughts on Java/JVM vs other languages. Again, related to pg's wrappers, the core thought was "Java as a language was more designed for the computer than a developer. Something like perl was more designed for a developer rather than the computer". The point was more expository than that, but that's stuck with me. Static languages in general seem to be that way, whereas dynamic langs (perl, ruby, php, etc), will make operations much simpler for a dev to implement, even at the expense of speed/clarity to the underlying os/vm. Perhaps there's more nuance here that I'm missing, or perhaps this 'wrapper' fits inside one of pg's wrappers already?
Scala is statically typed, runs on the JVM, and yet feels very much like writing Ruby or Python to me. The only time you have to add typing in the codes is where I would usually add it anyway in a dynamic language, via comments or stereotypically-named function arguments.
Android uses java not because it has been decided by the hackers but because of a top-down decision from a big organization. It made strategic and economic sense for them.
All big organizations love java and most programmers are not hacker geniuses, they just want to pay the rent. So most programmers(in number) use java or C#.
I use Java a lot, but is so bloated, slow and "I'm sorry, Dave. I'm afraid I can't do that." But it brought VMs to the table and that was a good contribution as it is really useful for some applications. Now that you could do that on C or C++ with LLVM but is easier on java.
For a simple proof of concept I will use java, or python, when I 'm serious I will use c, c++ or obj c.
Java might appear to be more successful than the (2001) article suggests, but it is geared towards java "the language." Its not a great language, but has found itself at the right place at the right time to address certain technical concerns (a "better" C++ at a time alternatives were being sought, concurrency with the rise of multi-core processing).
Java "the platform" (the JVM) has been a bigger focus in recent days especially with additional language support (JRuby, Jython, Clojure, Groovy, Scala). This support has been expanded in each recent release and seems to be the basis for the majority of the articles that appear on HN (or at least that I notice).
Having developed in Java for years, I agree with some of the points which PG has predicted 11yrs ago!
That said, using Java is sort of a insurance policy.
1. It's easy to find developers. _Sometimes_ easier to outsource modules.
2. It's usually hard to make mistakes in Java (you can screw up, if you want to) - mainly due to great tooling and excellent time-tested frameworks which help a tonne.
3. Has good complementary languages (Scala, Groovy, JRuby..), which interop well with other frameworks at large.
3. JVM does black-magic for you.
Indeed this as an interesting topic; however, I think that many missed the point of the essay altogether. He wasn't saying that Java is a horrible language just that it's not viewed favorably by "hackers". I think that he is probably right but I didn't know he spoke for hackers everywhere. Java is just another tool in the box that almost everyone has to use at some point. Is it ideal? No. Is it perfect? Nope. Is it fun to write software with? Sometimes. I spend most of my days writing Python code with either Django or Pyramid and also have problems with it from time to time. Though I consider Python my "favorite" language it's far from perfect! All languages/platforms have their problems and tradeoffs and there is little you can do about it other than create your own.
Just because Java is not viewed favorably by some random sample of hackers that pg may or may not know doesn't mean it's not an effective language. Hell, I think C and C++ are both horrible but I have to use them sometimes and while its not ideal for me it is what it is. If you wanna get paid, you'll use what you have to. (Joel Spolsky cover your eyes) I went to a Java school to computer science [GASP!] and it was fine. I already knew how to code so it was just a formality for me; however now that I'm looking at Android development I'm glad that I learned some Java along the way. A hacker is a hacker no matter what language they use and most programmers are not good enough to be called hackers anyway.
Predictions are very much like arses; everyone has them and they usually stink.
Exactly. All this talk about mediocre programmers use java and good programmers use "new cool hipster" languages is just a very biased statement.
There are hackers in every language and there are mediocre programmers in every language.
I've seen more mediocre programmers wanting to learn the new hipster languages than java. In 10 years from now these same languages will be on the java spot, and the cycle will continue.
But it does amuse me how so many people think they are better programmers because they use language X or Y.
Okay, I think I fit the "hacker" name (whatever that is) as well as anyone.
And for my next project, easily the most ambitious I've undertaken, I'm working on the JVM.
If you'd asked me three years ago if I'd ever write Java code, the answer would be no.
I don't really write Java though – I'm mostly using Scala, along with a couple of libraries that were written in Java, that I patch (e.g. Cassandra).
Point is, hackers are choosing the JVM today, whether its Scala, Clojure, Groovy, or JRuby, Jython, and the like. And having Java in the mix, from my perspective, is not at all bad. It means there's tonnes of relatively usable libraries out there, that are easy to tweak without breaking things, that have had plenty of time to bake.
The Java classloader mechanism is kind of nasty when it's paired with application servers, but consider on its own, it's allowing us to do live rollouts of new applications written in Scala without restarting the JVM. (We don't use an application server, we effectively wrote our own.)
Akka is like Erlang-light, and paired with Scala, makes the kinds of things people are wanting to do with Node.js (which I ported to Solaris, along with v8) easier, faster, and safer.
tl;dr Hackers are starting to choose the JVM, and the modern languages built on top of it (Scala, Groovy, Clojure) and the huge base of existing Java libs is making that possible -- just like the huge base of C/C++ libs made choosing Python, Ruby, or Perl reasonable a decade ago.
So why is it unsuccessful? Sure inside the browser its a piece of crap, but in terms of usage and the number of OSes and embedded processors it runs on, its surpassed probably only by C.
In 2001 Java had much broader ambitions than the (large) niches it has found itself in. Java's zeitgeist definition of success back then was creating a "anything and a JVM running Java" software monoculture even more extensive than C's.
"Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp."
They might not be the most beautiful languages ever invented, but they power a great deal of real-world applications. If people managed to write useful software with those, I consider that a success.
On the other hand, I probably never used or depended on any software written in Smalltalk in my life.
I actually like Java very much and am tremendously productive with it. It's a simple language and simplicity helps in many areas. It got many things right. It has a comprehensive standard library. Threading is excellent. Performance is excellent. Typing is helpful.
Its support for functional programming is lacking, which is why a lot of people from fp background have a dim view of it.
I love C++ and I know guys who love Java. And they are great systems programmers. I have nothing against Java the language (I do dislike the focus on OOP), but do have issues with JVMs (I prefer real machines rather than virtual ones), however, I would not say that no one loves Java. It has a place and is useful, and is appreciated, by many.
It's never been a loved language, but there it is, pretty much all over the place so many years later. I wouldn't have guessed that either!
I'd be more interested in reading on well-rehearsed, current predictions about Java. Many enterprises are starting to consider (mostly JVM-based) alternatives these days.
> I'd be more interested in reading on well-rehearsed, current predictions about Java.
I predict Java-the-language will stick around for at least another decade, if not for the huge enterprise codebases and the years invested in Java training, it would be because of Android. The biggest mobile platform of the moment is Android, and it's completely focussed on Java (whether that's a good thing is a whole different discussion).
Without Android, I think Java-the-language would fade very quickly, because IMO you can't possible assert the language is better in any way, for any kind of purpose, compared to the many alternatives. It's archaic, verbose, unnecessarily restrictive, misses most of the more modern language features, or bolted them on like ugly warts, it is not a very good RAD language because you need so much boilerplate, etc. In my experience (I've written about 100k lines of Java, many multiples of that in C, C++, Delphi, Python, Objective-C and PHP), Java is without doubt the least pleasant language to write.
As for Java-the-platform, I think that part of Java will not go away quickly. The JVM is actually very good, and the Java JDK frameworks are extensive, well-documented and well-known. New languages on top of the JVM, that allow leveraging the JDK frameworks will remain very popular for a long time, for good reasons.
I remember java from 1998/99, and by 2001 was getting the 'you should do java' routine from some colleagues. "why?" "there's so many jobs out there for it - it must be better!" That seems very much like another 'wrapper' pg is talking about.
I remember my immediate reaction was "there may be more jobs because it's takes twice as many people to write similar code as many other languages". In some ways I still feel that. The open source ecosystem around the JVM now does allow a much different level of productivity than the JVM offered in 1998. However, when I have to drop down to just plain-old-java, I'm reminded of how verbose and clunky the language is. When using the JVM, I'm typically on Groovy using some great Apache libs and such, both of which tend to shield the clunk away. :)
Personally I don't think the accuracy or inaccuracy (both are debatable) of the opinion is that interesting, and I've run a Java Users Group for over 12 years. I felt the article is much more interesting as a look inside a hacker's head as to what non-technical factors influence his/her opinions (and ultimately decisions) about a technology. I wrote a blog post breaking down his reasoning for the 'stink' and how those are/aren't applicable to today's software landscape. http://jobtipsforgeeks.com/2012/09/11/howhackerschoosetools/http://news.ycombinator.com/item?id=4510455 to discuss on HN
I'm not sure I find much to quibble with in the essay. In fact I find it almost prescient. Having worked with Java in an enterprise setting for over 12 years almost everything in that essay rings true. As we are acutely aware the enterprise beast moves to a very different beat - namely the vendors looking to make their numbers for the year. You're an IBM shop or a Microsoft shop. The decision's been made for you. And there's nothing wrong with that. As someone else pointed out, you're buying tooling, support and in the case of IBM - hardware. It is the almost the COBOL of this generation.
I don't think he's wrong in any sense of the word when he wrote it. From the opening he's very forward about his "hacker radar".
From a hacker perspective, Java is typically a poor choice. But it didn't succeed on hacker merits so much as it did on sponsorship and forward pushing from business types. Any competent programmer who has been in the field for long enough sees Java's issues and strengths and can judge it impartially but I'd be hard off to find a single one that felt it was the "best" language by any means.
Like or dislike Java, it has changed and transformed enterprise software fundamentally and remains one of the top used languages in the world.
And I thought it would happen the way it did.
Python was already around back then in 1994, but nobody cared because Java had Duke and was being pushed as the new idiom for everything networked.
Hacker's radar is a valuable instinct, but when a reputable commercial entity acts as a wise custodian, behind a technology with technical merit, effort can easily trigger and accelerate grass root adoption.
Back in school days I learned about programming paradigms, programming language technologies and cutting edge research on programming languages. I learned Java and also Haskell. Most of my class mates including all the teachers knew this that any industry grade language needs to provide multi-paradigm support out of box or it'll die.
If a species is not adaptable to its environment, it'll die. And Java is one of those species.
Why's this ancient text from the canon of Graham getting resubmitted? So we can all have a good laugh? So the readers of this site can have a big argument over the definition of "success"? "Sure Java sees a lot of use by clueless corporations, but teh haxors disdain it, therefore it's a failure!" Incidentally, Google can be added to the list of big dummies who use Java.
Right premises wrong conclusion. Most of the things PG says about Java are true but his conclusion that it wont be successful is completely wrong. Java is not a darling of hackers for all the reasons he has mentioned but it is embraced by large organizations for the very same reasons PG mentions which means there is huge market of job for Java coders if not hackers.
These predictions are correct, for the values of popularity and world pg and HN deal with. Startups.
The thing not cleary stated (or possibly understood) is that "large organizations" far out strip startups in number of employees, amount of code written, advertising budgets. And Java is very popular in "large organizations".
I wholeheartedly agree with him - I wish I had read this essay in 2001, I wish every Java developer, especially whose who were live in US, had read it. There was nothing wrong of Java in 2001, but, you should have caught the smell of corporate, protocol, committee, process, outsourcing, offshoring ...
"I have a hunch that it won't be a very successful"
As a general case, the first thing which struck me when rereading this essay was the way in which Graham's writing style (and his draft readers' editing) has improved. Today, a similarly structured essay would clearly answer the question, "Successful how?"
I think he has a lot of good points. I think if they would finally stop teaching Java in CS and other IT-related educations and Android would get proper support for other languages, Java(language) would slowly fade away.
While this rings true after all these years, had it not been for Java those of us living in the midwest would have either had to move away or spend the intervening years coding in VB6.
Learnt Java at university and swore off it as soon as I finished my course. Had a day job writing Perl software and it has been much better. The only effect though is that I have been put off Object Orientated code to, I find that and Java too verbose and non-transparent enough to hack or maintain quickly.
We're a north and south pole ... I swore off Perl in 1996 or so and spend my day job coding in Java. I find that Perl is too obfuscated and inconsistent to write solid, maintainable code.
This is one where I think we're going to have to agree to disagree!
The verbose and non-transparent nature of Java should not deter you from learning and using object orientated programming in other environments, especially since these concepts had already been explored decades before Java existed.
Object orientated programming is a good thing when it is done right, and horrible when it's done wrong, just like anything.
If your not doing functional programming and your not doing object orientated programming (they are both different types of OOP) then your not growing as a programmer, and this will come back to bite you much worse than any verbose Java code ever could.
I'm not at all a fan of Java personally and I too think its way more verbose and complicated than things need to be, but OOP != Java.
The only OOP I have really looked into since, was PHP frameworks like Zend Framework and I didn't find it made life easier for me.
I do make use of classes in Perl and PHP when they are presented in modules. I just don't choose to structure my work in objects.
I am using javascript as a functional language when in use with node.js or with firebase for example.
I just break my work up in simple functions which I use and re-use to do anything I need.
In regards to not developing as a programmer, of course if you have a style you will get better at it, but I find I grow better by learning more variety of skills, e.g properly securing password data with bcrypt, or playing stripes CTF2 to see where the vulnerabilities exist in software. As examples, I think there is more value in becoming a widely skilled and capable hacker, than an coding [style] guru.
Completely understand where you are coming from, knowledge is power after all!
I just don't understand how your going to get that knowledge if you avoid large areas of importance in every language you come across. Avoiding prototypes and closures in JavaScript means that there is a HUGE area of functional object orientated programming that you have no idea about, which means there is a number of languages you are never truly going to get your head around, including JavaScript, not a good position for a widely skilled hacker to be in, and creeping errors like this can really mess with your future prospects.
In my case this huge area of functional object orientated programming ended up becoming my career, after many years of being a jack of all trades master of none php and python developer.
I don't agree with a lot of the mainstream opinions around OOP myself, and I feel that functional programming has lots of merit in its own right, so maybe you should consider looking more into functional programming if you don't like the typical OOP MVC approach. If nothing else it will open up your mind to the many different ways that OOP can be implemented and might remove some of the fear or hate around OOP. :-)
I guess what I am saying is that, in many ways programming IS OOP, if only because of the sheer number of modern languages out there that have OOP design concepts within, by actively avoiding OOP you are actively avoiding learning some really important stuff that will help you learn many other key languages and programming concepts in the future.
Don't make the mistakes of letting your opinions around any given language, influence your opinions on any other language.
Next time you come across something OOP related please consider what I have said and don't fall into the same trap that so many other programmers fall into. You will be doing you and your future self a great favour!
Java-the-language filled a need for some time, and there's a lot of value staked on the JVM, but Java-the-culture needs to die, and the sooner the better.
I don't why you are being downvoted, you have excellent point in your post.
Having made to work like a donkey in the mill migrating large code bases in Mega corps, I felt the post was a template biography of every engineer like me.
Besides I see no end to 'Java Shop Politics' any time soon. Like somebody else on this thread- 'Java is basically a Insurance policy'.
Fantastic article, and a perfect candidate for HN readers.
C++ exists because someone had a fever dream in which these two classes of vehicles got mixed up and thought, “I’m going to put wings on a fucking tank”.
This is where I think pg's bias steered him wrong. Hackers tend not to like Java (although that is less the case now with the JVM ecosystem being what it is), but hackers do not solely determine the success of technology. Furthermore, the type of hacker that pg is interested in—the lisper, the 10Xer, the startup founder—are in limited supply. Certainly they wield more influence per capita, but they still need critical mass to form a stable community around an open source platform in order to compete with large organizations. If you're looking to build a product or a small scale project, by all means find yourself a Grade-A hacker.
If you want to make the next ubiquitous programming platform though, there are other qualities that are necessary. Consensus building is probably the most important skill that large organizations have that hackers will struggle with at scale. If you have a ton of management and mediocre programmers, it's easier to at least get them moving in the same direction, and they'll be more tolerant of the foibles of a designed-by-committee language. Sun had the perfect storm of strong technical talent to design a solid language, but also the large organization effects to market a new platform to enterprise decision makers.
In a way I think pg's smell test might be more valid for an earlier era. He underestimated the influence of the mediocre programming armies, probably because back in the old days there weren't as many and they weren't as mediocre. This is just speculation on my part, but I have to imagine that the quality of the average programmer as declined over time as the numbers and appearance as a recognized career path have increased. I mean how many people were programmers in the 70s because they're parents thought that's what they should go to school for?