Dave Fecak has served as the President and Founder of the Philadelphia Area Java Users' Group since 2000. He is an active blogger on software engineering career topics at http://jobtipsforgeeks.com, and author of Job Tips For GEEKS: The Job Search ebook (http://jobtipsforgeeksbook.com) Professionally, Dave has been a recruiter and consultant for 15 years helping startup and early growth firms to hire software engineers (primarily focused on Java/JVM, Python, Ruby, functional languages, and mobile). Dave is a DZone MVB and is not an employee of DZone and has posted 72 posts at DZone. You can read more from them at their website. View Full User Profile

How Hackers Choose Tools (thoughts on Paul Graham’s 'Java’s Cover')

  • submit to reddit

Recently, a 2001 blog post with the title Java’s Cover written by Paul Graham (of Y Combinator fame) spread across Twitter and was linked by all the other usual tech site suspects.  The piece was about what Graham called ‘hacker’s radar‘, which he describes as the ability of hackers to ‘develop a nose for good (and bad) technology‘.  For his description of hacker’s radar, he decided to cite Java as an example of a technology that smelled bad at the time.  Java’s popularity in 2001 made it a pretty big target for critique.  The title Java’s Cover is a reference to judging a book by the cover, and Graham argued that Java’s cover was a stinker.

Graham admits in the article that he had never written Java and his main exposure was when he ‘glanced over reference books‘, though Graham does have substantial tech credibility as a hacker.  He lists 12 reasons why he didn’t like the look of Java, and mentions that he had a hunch that Java would not be a very ‘successful language‘ (but he ‘may turn out to be mistaken‘).

The commentary on the aforementioned usual suspect sites seems, predictably and unfortunately, to be centered on the accuracy (‘is Java truly successful?’) or inaccuracy (Java is everywhere) of the prediction itself.  I feel it is a much more interesting exercise to take the opportunity to go into the author’s opinions as representative of an advanced technologist, and to see what factors would lead a like-minded and influential technologist to potentially have the same negative reaction to a new tool/language based on relatively non-technical factors.  Every day we read articles that are highly critical of languages, frameworks, design patterns, and anything else you can imagine, and it can be difficult to tell how much experience the author may actually have (or even need) to make such assertions.  When an industry voice writes an opinion on a topic based on the factors listed by Graham, what weight is given to the conclusions by the community?  Graham’s article is somewhat unique in that he was willing to list the ‘smell’ reasons for his suspicion.

Looking at each reason Graham gave individually may give us some insight into how technologists yesterday and today may form opinions about a variety of topics, and whether or not we can use these tests to determine future success.

1. It has been so energetically hyped.

While it is certainly true that excessive hype can be a sign of any potential product’s weakness, that certainly isn’t always the case.  Graham mentions notes that ‘A real standard tends to be already established by the time most people hear about it’.  You will find that almost every technology that is highly criticized has been blessed/cursed with a fair amount of hype, either generated by marketing people with profit motive or evangelists that may have much smaller (or even zero) financial interests.  I’m not sure that hype alone should make technologists wary about a new offering, but people who are naturally skeptical will surely be wary of over-the-top hype efforts.

2. It’s aimed low.

This one seems to have some merit.  In this case Graham is saying that Java is intentionally dumbed down, and that ‘Java’s designers were consciously designing a product for people not as smart as them. 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.

When people create a product/tool for other people to use, they obviously want their audience to be able to learn it, and Graham seems to argue that by ‘aiming low’ and focusing on ease of use you are probably placing unnecessary limitations on the product you are building.  If you were creating based solely on the need to solve specific problems, ease of use would not be as great a factor.

3. It has ulterior motives.

In this case Graham is speaking of Sun’s plan to ‘undermine‘ Microsoft.  We could certainly apply some tests of ulterior motives to several new developments in tech over the past several years, but I’d imagine it would be a difficult task to find similar motives in the overwhelming majority of new products.  This one is probably, in most cases, not applicable.

4. No one loves it.

Ouch!  Every language, every tool, is loved by someone.  Remember all those people in #1 above that make up the hype machine?  Perhaps by saying ‘I’ve never heard anyone say that they loved Java‘, Graham meant that that no one of any influence or importance loves it.  If a product is eschewed by the most widely respected folks in industry, that is a warning sign.  When some thought leaders begin to endorse tools they become viable for others to adopt (see alternative JVM programming language adoption by big firms today).  Some former Java evangelists professing a love for Scala comes to mind.

5. People are forced to use it.

Being told that you have to use a tool does not make it questionable, but in Graham’s brief description he infers that the anecdotal evidence includes smart people that would have used the tool voluntarily if it were good.  This is probably better said as ‘Outside forces with potentially differing objectives force technologists to use it against the techie’s own better judgement.’  It’s hard to argue with that.

6. It has too many cooks.

This one is quite interesting, especially with the changes that have occurred in the industry since 2001 and the emergence of open source as a dominant player in the market.  Graham went on to write that ‘the best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.

Issues with the JCP over the years have been written about ad nauseam.  But what would Graham make of other open source developments over the years?  I imagine the rebuttal would be that only the highest level members of an open source project are truly the ‘cooks’ he refers to, with the rest of the members merely relegated to chopping and slicing.  Maybe not.  Being suspicious of multiple decision-makers pandering to multiple masters would be natural, and warranted.

7. It’s bureaucratic.

In this case Graham is referring to the language structure itself and not the leadership.  This can be perhaps lumped into #2 It’s aimed low although not in every instance.  If a language is ‘aimed low’, you might expect that the designers would try and limit the types of mistakes users could make (see #9 as well).

8. It’s pseudo-hip.

Interesting perspective.  I’d argue it was hip.  Graham continued, ‘Sun now pretends that Java is a grassroots, open-source language effort like Perl or Python. This one just happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company.

I couldn’t help but notice the words Graham uses to critique Java in 2001 are very similar to how Democrats paint the modern day Tea Party (an observation on the language, not a political statement).  The real meat of this criticism seems to be that the product is controlled by a large organization, which per Graham would by default make it ‘clunky’, but posing as a much more community-friendly and open option.  I’m guessing this element of Graham’s opinion would have been amplified dramatically after the Oracle acquisition.  Would hackers feel differently if a big company tool wore the corporate badge proudly?

9. It’s designed for large organizations.

Graham specifies that Java was designed to limit large teams of mediocre programmers from causing damage.  This seems very much like reasons #2 It’s aimed low and #7 It’s bureaucratic above.  This is probably more accurately categorized as ‘designed for mediocre programmers‘.  I would assume that any advanced technologist would probably be less interested in a tool that seems to be created for a lesser engineer.  Graham wants only languages for big boys and girls, and most advanced and even intermediate hackers would probably agree.

10. The wrong people like it.

Graham lists the wrong people as ‘suits’ tuned into the hype from #1, big company programmers from #9, and college kids looking to get a job.  He feels that all three of these groups change their minds regularly.  I’d say the college kids of 2012 appear to be interested in newer technologies (Ruby, Python, functional programming, mobile) that are probably not the core of their curriculum (Java), and in 2001 they were also interested in newer technologies (Java) that were also not the focus of their education (C/C++).  Does the interest of college grads in Ruby and Python make those tools the wrong tools, or do today’s college grads have a bit more of a sophisticated hacker palate?  What do the suits and big company programmers love today?  Tools with ample talent supply, maybe?

11. Its daddy is in a pinch.

Java’s OLD daddy was, but Java’s new daddy buys islands!  But this isn’t about Java.  The financial standing of the steward of a language or product is certainly a valid consideration to make when evaluating the future viability regarding use in developing a product.  But who would be deemed the daddy of open source tools?  Individual project owners perhaps?  The vendor ecosystem that supports them?  The landscape has changed enough since 2001 that this criticism might be less of a factor now.

12. The DoD likes it.

Guilt by association, and Graham calls DoD culture the ‘opposite‘ of hacker culture.  In some recent discussions about Java and alternative JVM languages, I’ve seen this discrimination used in reverse, where Java supporters claim that the use of the alternative JVM languages by start-ups is a strike against using the alternative options.  The argument is that start-ups are all run by kids and cowboys, so any choices they make can’t be grounded in solid technical judgment.  Interesting how two groups, who both probably feel they are above-average technologists, can come up with opposite interpretations.


If you made it to the very bottom of Graham’s post, there is a link to an article called Trevor Re: Java’s Cover, which refers to comments by Trevor Blackwell (also a YC partner) about the post.  Blackwell classifies programmers as either ‘brilliant hackers‘ or ‘corporate drones‘ with most tools being written for the drones, so hackers need to know the smell tests to decipher quickly which tools are meant for the hacker and which were designed for the drones.  Of course, very few of the people Blackwell calls drones probably feel they are in that camp, which just complicates the issues even more.

I feel that Graham’s article is interesting as a time capsule to compare how hackers thought about new tools in 2001 and how they may come to conclusions about languages today.  As an investor, I’m sure some of the same smell tests Graham listed would apply to how he evaluates start-ups for potential funding.  Whether Graham was right or wrong about Java doesn’t matter at all, but getting a glimpse into his thought process then is quite valuable.

How would the current batch of popular and emerging technologies fair today, using Graham’s microscope?

Published at DZone with permission of Dave Fecak, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Jonathan Fisher replied on Wed, 2012/09/12 - 10:56am

1) It's been energetically hyped by the Apple and Rails crowds.
2) It's aimed low. Low low low. It's taught to newbs.
3) It has ulterior motives. Just see "Why's Poignant guide to Ruby." Clearly, a bacon lover ostracizing vegetarians.
4) No one Loves it. Well python programmers tout their whitespace loving OO-sortof mess as far superior
5) People are forced to use it. Ever try suggesting that a Ruby shop with performance problems switch to a fast, widely accepted language like Java? Hiss and sneers....
6) It has too many cooks. Ruby was originally designed by a single brilliant man. Now, it's being developed by former PHP developers ( I made that up).
7) It's bureaucratic. The Ruby community is discovering they may need a language specification in order to encourage multiple runtime implementations.
8) It’s pseudo-hip. Holy crap, Ruby is über hip. Ruby _DEFINES_ what a hip language should be.
9) It's designed for large organizations. What the hell does this mean? How do you design a language for a small organization?
10) The wrong people like it. This could only be more true in the Python community, but this is about Ruby. People don't know why the like Ruby, other than they like it. This is totally worth poking fun at them for. Sometimes. The problem is that have an influx of noobs pushing veterans and the smart people out (likely to more advanced languages like Scala/Haskell/Erlang).
11) What?
I hope everyone realizes that the above post was satire. The truth is, the Original Post is complete crap and should be treated as such. The arguments are baseless and so generalized, and as I half-seriously showed, they can be applied to any language.
If you want a serious language discussion about Java, watch this presentation from a _real Engineer_ at Urban Airship:  http://www.infoq.com/presentations/Java-next

Dave Fecak replied on Wed, 2012/09/12 - 11:17am in response to: Jonathan Fisher

@Jonathan - I was hoping that my article might draw some people to make comparisons to some popular tech of the current day (waiting for Node comments).  I agree that some of the 12 tests PG points out are a bit of a stretch (not sure I'd go as far as to call them baseless).  Most of your points are pretty spot on though, at least as far as some stereotyping goes of the Ruby community. 

You do half-seriously prove his point, but I disagree that you could do it convincingly for 'any' language.  Could you half-seriously make the same comments as appropriately about Python, Perl, or say Scala or Clojure?  Perhaps.  As I mentioned in my article, my purpose was to look at what relatively non-technical criteria a serious and respected engineer used 10 years ago to 'evaluate' a technology with a smell test, and I think others are doing the same thing today.  The criteria he lists are certainly not a thorough examination, but he felt strongly enough at the time based on these somewhat innocent criteria to dismiss a language that went on to become the #1 for a long time.  Thanks for the comments.

Jonathan Fisher replied on Wed, 2012/09/12 - 11:28am in response to: Dave Fecak


I can't take his article seriously at all, because it's 95% conjecture, straw man arguments, and misdirection. He sells this to the reader under a guise of neutrality, but the bias is revealed in his tone. People that pride themselves in scientific reasoning (aka Engineers/Hackers) shouldn't succumb to tactics of politicians.

Try watching the video presentation I linked to. While it is (mostly) 'pro-Java', It covers actual arguments, criticisms, and problems facing the Java community.

Dave Fecak replied on Wed, 2012/09/12 - 12:07pm

@Jonathan - I don't think either of us would argue that a good deal of what he wrote about Java was true in 2001, but we probably agree that they were not necessarily good reasons to question Java's validity or worthiness.  Points 1, 6, 8, 11, and 12 are accurate, but again, is that enough to judge a language or platform?  One can't say that he didn't at least appear to have some ulterior motives and bias himself, as he announced in 01 that he was working on his Lisp dialect Arc. Maybe he would say he wasn't designing Arc with adoption in mind (I haven't read about his goals with Arc).  


Again, I was much less interested in his conclusion or opinions about Java. What I found valuable was the test he used, and I was hoping to hear from other engineers (influential or not) about how they make somewhat quick judgments based on traits that are no entirely technical. Do others look at marketing, who is using, whether government is using, finances of the owner/steward, etc.  

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.