Slashdot Mirror
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."
He knows an interesting set of people, considering that C didn't come up once. Is Linus Torvalds a great hacker? Apparently not because if he was he would have coded the kernel in Perl!!
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...
I find it interesting that on one hand, he says no real hackers want to use Microsoft software, but it's Microsoft that has the number one hacker perk of private offices. So does that mean that no good hackers work at MS or that they rate offices higher than the tools they use?
I mod down all the "free iPod"-sig losers.
Untrue. Checked execeptions and strong typing are two features that Java has over Python, for example, which aid maintainability.
Checked exceptions are up for debate, though personally I think they are nice. Strong typing on the other hand - Python actually has strong typing, it just doesn't have static typing.
A major maintainability point that python is hopefully getting soon is Design by Contract. I blieve there are some packages that let you add it in to Java of course, but it's not in the standard package.
Jedidiah
Craft Beer Programming T-shirts
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.
At one time or another I have been fluent in around 6 or 7 programming languages. Personally, I think nothing comes close to Java if building large, maintainable and networked systems is your goal. As many people have pointed out, Perl and Python are good for small jobs but you'd be insane to architect a really large system on them.
Please define what you mean by "large programs".
I'm sitting in front of a system containing many modules and programs, and between them including over 60,000 lines of Perl. Is that a large system?
It depends on your perspective. If you don't know how to manage a 500 line program, it is insanely large. If you've ever worked on a project in C or Java that runs to a few million lines, then it is pretty small. It becomes larger when you consider that the same functionality would take a lot more lines in Java, C or C++ than it is taking in Perl. More critically, you'd probably need more than 6 developers to maintain and expand it, plus your development cycle would slow down significantly.
Certainly Perl is not the best language for writing a very large system. But for a certain size of project it is a very good language. And that size of project is larger than you'd think.
I , for one, hope to hear echoes of the major points of that article regarding improper programming atmospheres and mismanagement (ill-understanding) of programmers needs. I'm of the opinion that this issue is still a much avoided or unrecognized problem in the work place (please do correct me if I'm wrong about that.) That was probably the best manner in which I've ever heard that topic addressed... although the "langauges of choice" and so on seems to have gotten the most attention.
expletives welcomed
I see you've never worked with a great hacker.
Code written by a great hacker usually doesn't need maintenance because it already does the right thing. If it does need maintenance, it is modular enough that adding new functionality is not an onerous or time-consuming task.
As for debugging and writing tests, a great hacker's code is so clean and so defect free, they don't need to spend a lot of time debugging and writing test cases will simply diminish returns.
That being said, maybe one in a thousand programmers is great hacker. Their rarity and general non-availability explains why the rest of us believe that the maintenance, debugging, and test writing to cope with the badth of our pitiful code is necessary.
That is all.
I have on one occasion worked with a person whose code was so good he didn't need this stuff. He *was* that good. And I doubt I'll get another chance to work with someone *that* good again. That's the difference between an average hacker and a "great" hacker.
And, yes, the code *was* understandable and well-organized enough that it was self-documenting.
That is all.
It has been my experience that Java developers have no problem criticizing Perl without ever having tried it. When shown, they will be amazed by what is already done and in CPAN. They say Perl is slow because it is interpreted and needs to spawn a new process for every page requested on a web server.
On a more personal note, I find that most Java developers are rather boring, unimaginative people. This is one of the reasons this is my last week of work in IT as I strike out on my own.
Java makes the mediocre programmer feel like he's done a lot. When I hear "maintainable" code, what I'm really hearing is that just anybody can do the job. Surely there is some work out there difficult enough that it requires expertise.
Some people believe that they are left brained or right brained. The intelligent people I've met are genius across the board. The tier below them are people that merely applied themselves in one area and happen to be good at something. Programming seems to have both categories of people. One in a thousand is genius, the rest are just people that did a little hard work and can handle a computer.
Don't confuse *implementation* with *creation*. When Graham uses the term hacker, he's talking about people that create where there was nothing. People that bring to life the truly original, not merely the prolific coders that write a lot.
Some people are talking about the right tool for the right job. By the time you get to that point, you are implementing the known. Hacking--as I understand Graham to be talking about it--is about exploring the unkown. Building a site that can build merchant sites as he did, chasing down fraud in your customer service records, inventing the blink tag (sarcasm). Those are the kinds of things he's talking about, not making yet another session bean to pull employee data from the database (and calling it "architecting" doesn't make it any more impressive).
The whole Java mentality (as I've seen it) is that all requirements can be gathered up front. Then it is a simple matter of implementing those requirements. There is no hacking or exploration about it. It should all be scientific. Of course, I've never actually seen a business that ran this way. Businesses have rules that nobody knows about. They won't be captured until they are shaken out by existing code. That is the reality I've seen and I won't believe otherwise until I've seen it (which I won't, see above).
After the failure of a Java project, it is pointed out that the implementation was going fine and it was the fault of the requirements that made it fail. Well, for a language that is robust, maintainable and modular, Java sure is a pain in the ass when requirements are moving around. This is not so with Perl, Python and LISP. This is why many hackers prefer those languages. They are responsive to the person exploring and creating.
PS. I should not be allowed to post after midnight. I'm sure I'm unclear/troll/flamebait/overrated but I'm sympathetic to Graham's views after my dismal experiences.
t
And so on and so forth with insane stereotyping throughout the whole thing. Anyone who actually takes anything said in that thing (or by ESR in general) seriously... are taking the wrong things seriously :)