Paul Graham On 'Great Hackers'
dcgrigsby writes "Always interesting, if not unbiased, Paul Graham has published a new article on 'Great Hackers', discussing why Perl and Python are apparently better than Java, on why Microsoft developers get offices, and a host of other sure-to-be-controversial stuff."
Second, and I'll probably be modded as troll for this, but all the programmers I know who like perl are sysadmin types who don't know better. Popularity isn't a much better measure of "goodness" in the open-source world than it is anywhere else.
Graham may make some good points but he's SO far out in left field on others that his credibility is shot as far as I'm concerned.
Is suited to people who simply want to write large bodies of maintainable code. It's not intended for small hacks, nor is it intended for being close-to-the-metal.
The idea that one must automatically be a crap programmer because one likes Java is an egotistical and obnoxious point of view. I happen to like Python and C and C++ as well as Java, and I use all of those on occassion, but Java is no less a suitable and appropriate language to use for some tasks as any of those other languages.
I'm sorry, but Graham's dismissive attitude towards Java is evidence of extreme arrogance.
Now I would classify myself as a hacker, but cant play a musical instrument (CD player isn't a musical instrument right?) and sci-fi gives me a softie. Dig guns though.
IMHO a good/great hacker must be prepared to go where he wants to with confidence. Don't just take on everyone else's mindset (if you do what the other 6 billion people are doing you're not going to do anything worthwhile). In short, scratch your own itch.
Engineering is the art of compromise.
Slashdot... where lifting something directly out of the article, making the punctuation worse, and asking if the original author mentioned it is modded +5 insightful.
Dear God, I'm beginning to see parallels between this place and our political system. I need a drink...
~Tirinal
The Wright Bros. sued nearly everyone in sight for patent infringement, which is the main reason the center of aero-technology moved from America to Europe in less than a decade.
By the time of WWI America was put in the position of having to license aeroplane and engine technologies from England and France.
I think you should find a better example.
KFG
When he starts comparing languages or, to be more specific, makes the blanket statement that better hackers like Python over Perl I am reminded of the fact that the best hackers actually use OCAML and Objective-C.
"No they don't", you cry, "the best hackers user Assembly and Visual Basic".
"No, you're a fucking moron", someone else pipes up, "the best hackers use Pascal and COBOL."
"No, you are a fuckwit," a voice from the back of the croud screams, "Fortran and Algol are the languages of the best hackers".
"Quiet you fools," an elderly guru from the wings yells out, "I happen to know that the best hackers use Perl when they aren't dictating their programs to their secretaries to be outsourced to Taiwan to be compiled into Haskell"
"Shows what you know old man", a kid in the front row sneers, "the l33t hax0rs use Lisp and C++".
Well anyway, it looks like this might go on for a while, please enjoy the other comments while we try and work this out...
Waltz, nymph, for quick jigs vex Bud.
I consider myself to be somewhat of a seasoned hacker. I do hours of pretty intense C programming (Linux kernel code) on a daily basis. I feel that I have mastered the C programming language. Sit me down with any project written in C, and I will be able to (at least syntactically) figure out exactly what's going on with just a glance. I feel absolutely confident in my ability to easily slam through any task in C, without having to resort to any reference guides or manuals.
Now that I've established myself as a cocky elitist bastard to the Slashdot crowd (or do I just fit in now?), I would like to make one thing clear: I hate C.
I hate memory corruption (a.k.a. segmentation faults for the rest of the world). I hate explicit types and declarations. I hate casts. I hate memory management (kalloc, kfree - a.k.a. malloc, free for those alien folks off in userspace). I hate iterators. I hate list structures assembled with pointers. I hate pointers for that matter. All that C really does for me is provide me with activation records during function calls (okay, and cross-platform compatibility). The only thing I like about C is the fact that you can compile it and it's fast.
I hate Java. I hate class cast exceptions. I hate null pointer references. I hate virtual machines. And I still hate iterators.
I hate Perl. I hate interpreters. I hate pathetic attempts at object oriented behavior.
I hate Python. I hate C++. I hate PHP. They all suck, all for (more or less) the same reason: run-time errors.
Enter Objective Caml. More likely than not, when you've got your O'caml program compiling, it just works. No run-time errors, like memory corruption, nonsense casts, class cast exceptions, or null pointer references. You can compile it down to native code, and it runs just as fast as C in many (if not most) cases. There is a complete standard library with pretty much everything you would ever want. There are hooks into GTK and Mysql, among other C libraries. You have real objects, done in a halfway decent manner. Persistent data, by default, exists in a structure (like a list or a type), as it should. Functions are first-class citizens. Iterative structures are possible, but usually not required. Tail-end recursion introduces no stack overhead. Algorithms implemented in O'caml just look elegant, like lambda calculus expressions.
The problem, of course, is that it will take me several more years before I get to be as efficient in O'Caml as I am currently in C. And anyone who comes in after me to maintain the code will probably know C much better than O'Caml. This means that for any userspace projects that I do at work, it's gotta be in C. I can get by in C, because I am a very disciplined coder, and I know all the quirks and tricks to developing and maintaining good C code. Occasionally, I will get a nightmare mystery segfault in a very large project, and I will curse C and yern for O'Caml, but I must persist.
At the end of the day, my own Open Source projects that I do on nights and on weekends are in Ruby (if they are web apps) and O'Caml (otherwise). This doesn't necessarily mean that O'Caml is the best language for any given project (mainly do the competency of the employees, current and future, with regards to O'Caml). Maybe in about a year or so, after writing a few Open Source projects in O'Caml on my own time, I will feel confident enough to suggest I use it for a project at work. Even then, it will be a hard sell, despite the fact that it is superior to C in almost every way.
So my point, if I have one, would probably be that true hackers like to experiment with esoteric languages that the rest of the world knows little about. The shear number of programmers out there who know C and Java present a significant barrier to entry for elegant languages like O'Caml. I suppose that getting the academic types to emphasize languages that solve many of the problems that have plagued computer languages for the last 30 years might begin to help with the situation. Until then, I'll be firing up gdb...
He's right. You guys are so personally offended you can't see the forest for the trees.
/. crowd. In your opinion, who's the most likely hacker?
He's talking about hackers here, kids. Not 90% of the
a. sysadmin
b. java developer
c. janitor
Personally, I'm voting for (a). (A) because most sysadmins deal with perl, lots of unix systems, they know *nix inside and out.
Java guys are out of the question, they're too wrapped up in their baby blankets sucking their thumbs to realize they are not _in_ the group we're speaking of.
Janitors, well, it's possible, but probably not common.
I'm a sysadmin, and I user perl all day long. Sometimes at night, when a brute force ssh attack comes along. I need to know which exploits are out there, I'm constantly trying to break my system. I'm constantly learning about the newest buffer overflows in solaris. I am intimately aware of memory space in the kernel. I don't live in a Java Dream World (tm). I don't have all day long to dream of how, if java were tangible matter, it'd be able to cure world hunger. I'm too busy living in the Real World(tm).
In conclusion, while it's uncommon to have good hackers know they're good, it's a lot more common to have a bunch of wanna-bes think they are "the hackers".
If you look at what a good joiner uses, you'll note that he has a large set of tools, and picks the right one. There is no advantage in trying to turn wood on a lathe with a screwdriver - that's the job of a chisel.
A similar thing applies with computational work. If you truely know what you are doing, you'll use the right tool for the job. If your wanting to accumulate a large set of facts, and then do some comparisons across that set of facts, that's a job for Prolog. No matter that C, or Java, or Perl, or whatever, is more popular. They are just a poor fit to the task, which would mean you'd need to write a predicate logic packeage in them, to get them to work.
Look at tools like FFTW. It's written in OCaml, and C. Two different languages, each used seperatly, to play to thier strengths. OCaml does tree parsing, and optimising of an abstract syntax tree. C code does the numerical heavy lifing. That's choosing the right (rather, a good, there is a pluraity of good tools for that) tool for the job. Trying to do the abstract syntax tree parsing in C, or the numerical heavy lifting in OCaml is just stupid - you'll end up with something that's nowhere near as good.
Try writing an OS kernel in Perl.
'Favourite language' is something that's not a good metric. I've solved problems (and that's what it's all about) using 50 lines of C feeding 100 lines of Fortran feeding 50 lines of Perl producing Postscript that compiled to the desired diagrams, because that's what suited the problem domains best.
Claiming that 'good hackers like language X' misses the whole point. Good hackers will use the best tool for the job.
Also, Graham seems to be conviently ignoring the 'can this be understood three years down the line' aspect. There is no point in having code that you can't maintain. That's where Java comes in - it's got a blend of power and syntactic salt help keep things maintainable. Asserting that maintainabilty isn't relevant just strikes me as something that's, well, immature.
Perl is a language only its mother could love. And some people who've never coded in Lisp. Python is a much nicer language of course.
But it's a scripting language.
By which I mean: on most modern benchmarks I've run, it's well over fifteen times slower than Java. Than Java!
Java's got lots of faults. But it has one very good feature: it's rapidly getting faster (as is its evil stepsister, C#) This is largely due to design decisions in the languages which traded off some late binding and dynamic typing for efficiency. Python doesn't make those promises, and as a result it's stuck in the must-check-almost-everything-at-runtime-land of old (pre-Common)Lisps.
Hackers coding only in Python. Gimme a break. What we're largely seeing is *script* hackers coding in Python. cgi-bin. shell crap. webbots. It's where Python shines. But there's an awfully big collection of code projects that need to straddle the speed of C++ and the dynamicism (to some degree) of higher-level languages. And there's a lot of hacking opportunity there. Java does that region very well, thank you.
Software maintenance is the single largest portion of the software life cycle. (IMHO)
So, why would I as chief programmer or system architect on a software project (that has a budget) allow pieces of the of software system to be built with languages that the 'common' programmer doesn't know? Sure, you could spend money training all the 'lesser' programmers in Python and/or PERL but, why waste the money? There are perfectly good languages that are defacto standard, provide loads of functionality, development tools, and are known by the 'so-called common' programmer. Every language has its pros and cons. So, if Java's weakness is uber-hackers don't like to use it than PERL's and Python's is maintainability. :) )
(However, I think author might be poking the tiger with comments like: "Of all the great programmers I can think of, I know of only one who would voluntarily program in Java." And we all feel right into that trap... I know I did.
Also, the single most important resource on a software project is people (again IMHO). Typical development scenario: New contract has been acquired. So, you as the "boss" hired 10 developers for the new project. One of which falls in the author's super-elite hacker class. The project's initial system delivery goes as smooth as glass cause the 'brains' of the operation (or the 1% as the author calls it) did majority of the work. Well, shortly after the initial delivery the hacker decides the project is now boring, the system was delivered and he or she is now looking for a new challenge. He or she now leaves the program and/or company. Now, there is a serious issue. Since the hacker did 90% of the work, now 90% of the core knowledge of how to maintain the system has left as well. (And I don't care who you are. Jesus himself couldn't write software that is perfect the first time. Bugs are always present and requirements can and do change. And Jesus also can microwave a burrito so hot he himself couldn't eat it!)
Given the author's profile of the hacker- Quiet, anti-social and loves his/her corner office with the door locked (which is a BS stereo-type)probably also didn't bother to pass any knowledge on to anyone else on the project. So, tell me again why this person was 'the most valuable thing' to us and the delivered system?
I personally love working with people are technically sharp but, also like working with other people and sharing info. I have caught myself being sort of elitist when I was the technical authority on something. But what does that gain you? Nothing in my experience. You want to be respected by your peers and co-workers? Share with them your knowledge not just lines of code (be it byte-code or interpreted scripts).
We are blind to the Worlds within us
waiting to be born...
"It was really interesting until he pointed out that great hackers work differently than I do, at which point it became clear that he is a moron."
I know there have been flame wars about using the word "hacker" for years, and I certainly don't want to start another one. I don't care if people use the term as a pejorative or a badge of honor. I don't care if it means a computer criminal or software developer. I don't care if it means white hat or black hat. That's a debate best left back in 1985.
;) But I don't think this view represents the majority of developers; it may not even represent the majority of open source developers. The hacker/craftsman camp is a small minority.
But having said that, I think it's time we retire the word "hacker". The reason I think this is because the use of this word, which is supposed to be so positive: the curious, problem-solving tinkerer, isn't really that positive anymore. I'm talking about hackers as craftsmen (another word the author uses in the article). Defining software development as a craft harkens back to a an age when the industry was young and still defining itself. An age when the industry was hidden behind equipment in a backoffice or university machine room populated by bright-but-eccentric pioneers. A time when the industry, and its pioneers, didn't know what its Best Practices were. Those days are over.
Today, the industry has matured in many ways. Today, projects, and the organizations that manage them, don't want a tinkerer who will sit in the backoffice and figure stuff out. They want well-rounded individuals who can gather and interpret requirements, communicate with their team, and develop elegant, well-designed solutions using best practices. They want Software Engineers and Software Architects.
There is still a camp out there that is resisting this change. They still believe in the craftsman lifestyle, and they still code with emacs (oops, another flame war!
The author makes the point that some developers are so much more productive than their peers because of how they use technology, but does he realize that those productive developers are not hackers/craftsmen pecking out PHP or perl in their emacs session? They are Software Engineers using latest-generation tools and languages, design patterns and best practices, object-oriented techniques and integration technologies like message queues, not to mention web services and remoting. And incidently, they're still employable.
----
"Oh, bother," said Pooh, as he hid Piglet's mangled corpse.