Java's Cover (April 2001)
paulgraham.com
paulgraham.com
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?
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.
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 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).
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.
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.
But the point is that this does not preclude businesses getting value from maintenance-nightmare software.
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.
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.
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. ;-)
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.
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.
No, but it's also not a programming language. Of course, there are languages that use XML as their syntax, and many of these are Truing complete.
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.
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.
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 generally agree and it's ironic too since Java the platform was conceived with embedded programming as the target medium.
http://en.wikipedia.org/wiki/Java_(software_platform)
It wasn't until the very end of the 90's when Enterprise Java came on the scene.
So claim no. 9 was weakly founded in only about 1 year of history prior to the OP article.
I still think of Java more as the SE version than the enterprise version.
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?
There are even comments regarding Java in which is obvious that the commenter doesn't have good knowledge of either Java or the JVM.
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.
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.
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.
Something like Kotlin seems like a good choice to me, if it takes off.
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).
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
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.
[0] http://www.youtube.com/watch?feature=player_detailpage&v...
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.
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.
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.
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.
That may be true, but it is not at all obvious that it is. Do you have some sources to back up that claim?
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.
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.
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
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.
It also helps that it's one of the languages being taught in CS classes.
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.
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.
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.
Still, I'm impressed that you managed to work a Dune metaphor into a Java discussion...
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.
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++.
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.
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()
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();
}
}
}
There is no difference in your python code than the Java code that someone would write:
if(comment.getText().toLowerCase().contains("first post!"))
{
comment.getUser().ban();
}
You just felt the need to unnecessarily obfuscate the code to suit your argument.
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.
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.
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.
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.
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)
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.
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.
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.
http://news.ycombinator.com/item?id=4497691
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.
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.
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).
Apart from the Java language itself, the most common or well-known JVM languages are:
Clojure, a functional Lisp dialect
Groovy, a scripting language
Scala, an object-oriented and functional programming language[1]
Kotlin, statically typed programming language compiled to JVM byte code and JavaScript by Jetbrains
Ceylon, an upcoming programming language and SDK, created by Red Hat
JavaFX Script, a scripting language targeting the Rich Internet Application domain (discontinued 2010)
JRuby, an implementation of Ruby
Jython, an implementation of Python
Rhino, an implementation of JavaScript
AspectJ, an aspect-oriented extension of Java
I would add Gosu, Fortress/JVM, and Beanshell as important. Others were talked about at the recent JVM Language Summit (http://openjdk.java.net/projects/mlvm/jvmlangsummit/agenda.h...).
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.
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).
In the years since, new C# features have diverged sharply from Java's.
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#.
thats because in 10 years, 99.9% of folks out there will be still be dumb
Same story, different times. At least try to provide an argument for your position, instead of "(...) will be still be dumb". Thanks.
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.
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.
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.
Your comment is a fine example of the Dunning-Krueger effect...
Well... I'll probably have to open a restaurant somewhere...
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."
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.
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.
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.
The essay is about hacker's radar, not Java, anyway. Personally I loved his list of other technologies he has ignored.
[1] http://archive.adaic.com/docs/reports/lawlis/m.htm
[2] http://www.thefreelibrary.com/Visual+Basic+Programmers+Journ...
I think that pretty clearly says that (at that time) he didn't think it'd be very popular.
He did:
>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.
See Yegge on the liberal/conservative distinction: https://plus.google.com/110981030061712822816/posts/KaSKeg4v...
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.
> a hunch that it [Java] won't be a very successful language
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.)
Speak for yourself.
Ubiquitous readily available knowledge is power, not elitist hackerism...
So great for big businesses, but poor for hackers wanting to do cool stuff.
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.
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.
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 confess: I love Java. :-)
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
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.
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 "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).
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.
I guess committee did make a decent pick then.
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.
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.
Love the predictions analogy :p
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.
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.
Its support for functional programming is lacking, which is why a lot of people from fp background have a dim view of it.
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 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 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. :)
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.
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.
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".
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 got that one right: none of my colleagues who write Java are that much into it. They just have to.
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.
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.
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!
This is one where I think we're going to have to agree to disagree!
http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...
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'.
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”.