Paul Graham: Hackers and Painters 435
larsberg writes "Another wonderful article from Paul Graham on hackers, their lifestyle, and their tools. It's entitled "Hackers and Painters", and provides a great description of how the great hackers write code. The article is definitely worth a read, especially for those who have an inkling that any field that has to place the word "Science" in its name probably isn't really a science after all."
Wait... (Score:5, Funny)
Re:Wait... (Score:4, Interesting)
Re:Wait... (Score:4, Funny)
Re:Wait... (Score:3, Funny)
Re:Wait... (Score:3, Insightful)
The data streams in and out of the processor dont count? The output on your screen doesn't count?
Your testable hypotheses?
I think I can make an O(log(n)) algorithm to do blah blah. I think that malloc algorithm A will improve throughput 30% over algorithm B.
Your experimental data?
No data in computers, that's for sure.
Your replicable results?
Nope. No way to copy a computer program. Good point.
Blurring the lines (Score:3, Insightful)
Safecracking is an "art" too.
I guess it depends on your inital reaction to the term hacker. It should be someone who hacks code, vs. a cracker that willfully circumvents security measures and breaks into a network. Unfortunately, you need to consider the source of the quote to get at the real meaning.
Re:Blurring the lines (Score:2)
Re:Blurring the lines (Score:2, Informative)
If you find a copy of the Jargon File before ES-"raving lunatic"-R took it over, you'll see that it defines hacker to mean "one who breaks into systems" without any sort of warning about incorrectness. It is only when ESR took over that suddenly this became "strongly deprecated".
I can't remember whether that version even had an entry for cracker in it. But don't take that as an implied assertion that it didn't.
Re:Blurring the lines (Score:3, Insightful)
Every time I read a newspaper on any topic I know something about, I find more errors than facts. I don't expect them to understand technical areas that reporters never learn. But I catch them misquoting sources, misspelling names and getting people's jobs titles wrong when all the correct information is available on a company web site within easy cut-and-paste range. I wouldn't take a newspaper as the final answer on any subject.
Re:Blurring the lines (Score:3, Informative)
mathematics is an art too... (Score:5, Interesting)
You can do computer science, and you will get a bullet proof system, but it takes a hell of a long time. People arn't that good at science, that why we created computers. code-breaking and missile targeting and the nuke.
Re:mathematics is an art too... (Score:3, Interesting)
I spent over 10 years as a sysprog, and never questioned the term "Computer Science" for a moment until 2 years ago when I changed focus and went back to school to study biotechnology. Suddenly, I was faced with the "Scientific Method (tm)" that every other snotty-nosed nerd has had to cope with for the last x^y years, and it was quite a comedown.
The scientific method, however, is a beautiful
Re:Blurring the lines (Score:2)
In a sense, that's the same thing that a cracker does. He tries to take a big black box, and carefully poke & prod. Not so much that he alerts the owners. And then when he is confident he knows how the black box works, then he cracks it open and gets the riches.
Re:Blurring the lines (Score:3, Interesting)
--trb
In case of Slashdotting (it's already a bit slow) (Score:5, Informative)
(This essay is derived from a guest lecture at Harvard, which incorporated an earlier talk at Northeastern.)
When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work-- that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.
Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I've known, hackers and painters are among the most alike.
What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They're not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.
I've never liked the term "computer science." The main reason I don't like it is that there's no such thing. Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia. At one end you have people who are really mathematicians, but call what they're doing computer science so they can get DARPA grants. In the middle you have people working on something like the natural history of computers-- studying the behavior of algorithms for routing data through networks, for example. And then at the other extreme you have the hackers, who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters. It's as if mathematicians, physicists, and architects all had to be in the same department.
Sometimes what the hackers do is called "software engineering," but this term is just as misleading. Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it's there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.
What and how should not be kept too separate. You're asking for trouble if you try to decide what to do without understanding how to do it. But hacking can certainly be more than just deciding how to implement some spec. At its best, it's creating the spec-- though it turns out the best way to do that is to implement it.
Perhaps one day "computer science" will, like Yugoslavia, get broken up into its component parts. That might be a good thing. Especially if it meant independence for my native land, hacking.
Bundling all these different types of work together in one department may be convenient administratively, but it's confusing intellectually. That's the other reason I don't like the name "computer science." Arguably the people in the middle are doing something like an experimental science. But the people at either end, the hackers and the mathematicians, are not actually doing science.
The mathematicians don't seem bothered by this. They happily set to work proving theorems like the other mathematicians over in the math department, and probably soon stop noticing that the building they work in says ``computer science'' on the outside. But for the hackers this label is a problem. If what they're doing is called science, it makes them feel they ought to be acting scientific. So instead of doing what they really want to do, which is to design beautiful software, hackers in universities and research labs feel they ought to be writing research papers.
In the best case, the papers are just a formality. Hackers write cool software, and then write a paper about it, and the paper becomes a proxy for the achievement represented by the software. But often this mismatch causes problems. It's easy to drift away from building beautiful things toward building ugly things that make m
Re:In case of Slashdotting (it's already a bit slo (Score:2)
hackers and painters? (Score:3, Funny)
I highly doubt Picasso, Rembrandt or Cézanne strutted around saying "H3y d00dz, ch3ck 0u7 7h3 l337 p41n71ng5 1 h4x0r3d t0g37h3r l457 n1gh7! ph34r m3!
Re:hackers and painters? (Score:5, Insightful)
Re:hackers and painters? (Score:3, Insightful)
just because the media coopted the term to mean script-kiddies and crackers doesn't mean the original meaning is lost to the old school.
PG, whatever else you can say about him, is an old school lisp hacker. This can be confusing to people who are too young or uninformed, but I can see why P.G. holds onto the original meaning.
So you hate it when people use the term hacker in its original meaning? How do you think they feel about people using the new bast
Re:hackers and painters? (Score:3, Informative)
Re:hackers and painters? (Score:5, Insightful)
Is it just me? (Score:2, Insightful)
Just my ten cents. Your milage may vary.
Re:Is it just me? (Score:4, Funny)
At least he finished with a well thought out and carefully researched conclusion.
That changes my perceptions completely
Re:Is it just me? (Score:3, Insightful)
Many of the best programmers I know are wont to draw up proofs and diagrams on paper before sitting down to code. Then as they evolve their code they do tests, draw more conclusions, and figure out what needs to change next.
If they went as far as to document that whole cycle, they would be 80% of the way to a research paper.
It's an art, but so is writing elegant, easy-to-understand proofs. It's an ar
Re:Is it just me? (Score:3, Insightful)
Would you consider any of these people to be scientists or engineers? Does the fact that their art is useful have any bearing on that question? Does the deterministic nature of gravity and paint make them empirical investigators? The average architect probably knows a lot m
Re:Is it just me? (Score:5, Insightful)
He's not referring to all programming as "hacking". In fact, the article mentions how most of the programmers in the corporate world do jobs that have absolutely nothing to do with his concept of hacking. Hacking has a heavy dose of design on it. In fact, Graham argues that design happens to be more important than the actual implementation, it just happens that the implementation gets done as you design.
On most cases, coding to a design, instead of coding to user specs, restricts the task so much that there is little chance of creativity. That's not Hacking at all. On the other hand, desigining a +100,000 LOC complex, flexible system, designing it's data structures and object relationships, is so much more complex than "grunt coding" that I think it is way closer to architecture than it is to building a brick wall.
If you belive that all design/code is more like building a house than paiting it's just because you've not seen a truly brilliant, innovative design yet. I hope you're lucky enough to see one, or better yet, create one.
Re:Is it just me? (Score:2)
Re:Is it just me? (Score:5, Insightful)
If you really want to pick an analogy, I'd pick carpentry. Not finish carpentry, as that's too artistic on the scale, but rather functional carpentry. For instance, a carpenter with no real experience and no tools can build a table out of what they find lying around. Some tables have four different legs of four different sizes, one's attached by childrens paste, and another with a high strength steel bolt. See most OSS packages for the coding analogue. A better carpenter has a few tools and makes a better structure, giving a more functional table. Better programs stand up well provided you embrace their rigid design criteria. A master carpenter might the best looking table and design it such that he could come back and add drawers later or replace it with a bigger top or taller legs.
Carpentry, like software, is mostly about figuring out what pieces you'll need and how to piece them together. That's the essence of engineering. Those who study traditional engineering disciplines often scoff at the idea of software engineering because it violates the traditional way of doing the engineering before construction. That hasn't always been the case, and even today some software is developed by traditional engineering techniques. That's not an invalid way to do it, although it is more expensive. Software engineers are embracing the engineer-on-the-fly paradigm, and that's a new idea that nobody really knows how to teach.
In carpentry as in software, the engineering and fabrication are distinct and separable. I wouldn't consider it unlikely that in the future software architecture (engineering) will be done by a different group of people than the coding (fabrication). This is starting to show up now with many companies doing their architecture in UML and then sending it overseas for actual implementation.
This has run way longer than I wanted, so I'll stop here.. Just a few thoughts on a slow morning.
Re:Is it just me? (Score:3, Funny)
Does this mean I should stop printing reports on canvas?
Re:Is it just me? (Score:3, Insightful)
I've spent the majority of my (admittedly short) career turning DARPA grants into math-envious papers, just as the author described.
A couple of years ago, I did step back and wonder if what I was doing was really science. I didn't seem to fit the idealized notion of a scientist that I learned about in high school:
He's Got Some Very Valid Points (Score:3, Insightful)
Introspection is not unwarranted in our field. Many things he said in his article were true. I view hacking and programming as two very different things. The way I see it, a Programmer is a code monkey who implements management's vision of how the software should be 40 hours a week and then has nothing to do with computer
Not just you... (Score:3, Interesting)
To wit:
He espouses how important it is to keep the design fluid and to change it midstream as necessary, even being fast and loose with data types. While that may indulge the hacker in being creative, it also wreaks havoc on one conveniently omitted aspect of software: maintainability. Rare indeed is the code that is written and never touched ageain. I'm sure someone can toss in statistics about what percent o
Re:Is it just me? (Score:3, Informative)
Hacker: writes code, likes to write neat code, usually of a functional nature
Cracker: breaks into systems.
I know, I know...the media long ago hijacked the term 'hacker' to refer to both sets of activities. The article in question uses the correct definition of the term though.
Re: (Score:2, Funny)
Re:Other CS Names Were Considered (Score:2)
I thought engineers drive trains?
So I would think a Computer Engineer is someone who operated a computer.
Because I can operate a computer so I am a Computer Engineer.
Cool and I studied Computer Science.
The converse (Score:2, Funny)
Would you like Van Gogh to work on your teeth?
Re:The converse (Score:3, Funny)
he's more of a plastic surgeon, actually.
leave your teeth to Ecsher.
Re:The converse (Score:2)
As a learned Sandwich Artist,I cannot tell you how much I agree with this statement.
Stupid leechy hygenists- always trying to make themselves look more cultured at the expense of the prestige of the Sandwich Artist designation!
grumble...grmble..gr.
I am like a painter (Score:4, Funny)
Re:I am like a painter (Score:2)
Yep (Score:5, Informative)
One commonality I've seen so far is that you just have to jump in and do what you can before anyone can help you. Posting questions like "how do I write an OS?" or "how do I draw such-and-such?" will yield theory but not get you far. On your first tries it's going to look like a bunch of scribbles (or spaghetti code that is far from compilable), but you have to put something down for others to critique. And of course coding and art both take tons of practice time. This goes along with just trying and not worrying about the results. If I didn't code unless I was sure each line was perfectly bug free.. well, that's impossible.
I've been working on realistic and anime-style people. Humans are the most rewarding subjects and also one of the hardest to draw, but I wouldn't want to draw anything else. For anyone else wanting to start in this direction, I recommend the PolyKarbon BBS [ezboard.com]. There are some amazingly talented people there that are very helpful. This site with anatomy books [fineart.sk] is a good reference. If you have more helpful links, like a newsgroup for new artists (I haven't found any that are good), please post them.
Re:Yep (Score:2, Informative)
And here are some on drawing game art:
And if you want to pick up an inexpensive book to get started, this one [amazon.com] is great. I've seen it in both Borders and Barnes and Noble for ten bucks. I've heard over and over that you can't start out drawing anime-style people, because copying a style that is already a he
Re:Yep (Score:2)
The second is here [tesco.net]. It's Paul Wilkinson's tutorial on lifelike portraits - with an especially good section on proper s
The Art of Computer Programming (Score:5, Insightful)
Art and science are probably closer than most people believe. Leonardo da Vinci painted some of the most astounding scenes ever painted; yet, he also studied science, literature, and the Christian bible. Many mathematicians would say that math is an art, heck there are probably some artists that believe art is a science.
Knuth [stanford.edu] says that computer programming is an art, but I dare you to read his books and claim they are devoid of science.
In short... It's all depends on the application.
Re:The Art of Computer Programming (Score:3, Insightful)
I used to be a "software engineer" ... (Score:3, Funny)
Re:I used to be a "software engineer" ... (Score:2)
You're not going to laid laid, anyway.
.SHITE (Score:2, Troll)
I've been told that Microsoft discourages employees from contributing to open-source projects, even in their spare time. But so many of the best hackers work on open-source projects now that the main effect of this policy may be to ensure that they won't be able to hire any first-rate programmers.
but should surely read:
the main effect of this policy may be to ensure that they still won't be able to hire any first-rate programmers.
Re:.SHITE (Score:2)
they'd be fired, or even worse, assigned to the IIS security team
Re:.SHITE (Score:2)
Different lands (Score:2)
Lots of universities have computer science departments as well as information systems (or some variation of that term) departments. Like theoretical vs. applied mathematics or physics, the CS depts. concentrate on theory (algorithm development, etc.) and IS is geared toward practical applications (database application d
This is a pointless exercise (Score:4, Insightful)
"When I finished grad school in blank I went to blank school to study blanking. A lot of people seemed surprised that someone interested in blanks would also be interested in blanking. They seemed to think that blanking and blanking were very different kinds of work-- that blanking was cold, precise, and methodical, and that blanking was the frenzied expression of some primal urge.
"Both of these images are wrong. Blanking and blanking have a lot in common. In fact, of all the different types of people I've known, blankers and blankers are among the most alike."
Re:This is a pointless exercise (Score:2)
Too much South Park, not enough sleep.
Re:This is a pointless exercise (Score:2)
Re:This is a pointless exercise (Score:5, Insightful)
So the point of this is that he is trying to say that hacking is a legitimate technique that has advantages over the traditional, slower and possibly less flexible, software engineering moethods and he's doing it by drawing parallels to how artists work. I think the truth is that you need a little of both.
There is place for everybody (Score:5, Insightful)
This is already the case. There are people specializing in writing comp-sci software (compiler etc...), there all those double-majors who write software for their other degree specialization (software for given domains like geophysical etc...), there are people who specialise on the ergonomic of the GUI, etc....
This isn't that different from people designing a car, a thing that is both functional and can be beautiful. It takes engineer and designer to make a car.
Now don't tell me "I am the creative type", I am writting software, science doesn't apply to me. I once work in a software lab where the lab had been producing software for several decades. One day the person in charge of QA convinced the person in charge of development to bring some quality type tools like cyclomatic analysis (McCabe etc...). A few engineer came up with that argument that they were producing art, that a software couldn't / shouldn't judge them.
Well, they did two things: They ran McCabe against a lot of their software, some that have been in the market for decades, and there was a direct correlation between the "level" the tool was finding and the number of patches applied to the piece of software. Then they analysed code per current programers: The artsy types were writting complex code that the QA dept. kept sending back !!
Conclusion, there is a place for "out there" artsy type to inovated in a small shop, there is a place in ergonomic to write "beautifull software", but a serious piece of software does need some science.
Think about this, how beautifull would a car that looks good but keeps breaking down be ? Doesn't this remind you a lot of the software out there ?
Re:There is place for everybody (Score:2, Funny)
Reminds me of quite a few cars too...
Great Quote (Score:5, Interesting)
What a great quote. This is so very true.
Dynamic typing is a win here because you don't have to commit to specific data representations up front. But the key to flexibility, I think, is to make the language very abstract.
From what I've seen, very few people - espessially those with degress in computer science - share my views on programming. This article takes a different approach to it, but it's the same view I have, when it gets down to it. I usually say that when programming, you shouldn't be bothering with types, memory locations, pointers, and other nonsense that has nothing to do with how the program works. Or in other words, the formal 'scientific' aspects of programming.
Most people will disagree with me here, and I've been involved in many arguments over it. My programing language of choice right now? PHP. Why? Because it sucks less than the other choices. It still boggles my mind that C is used to do any high-level programming (ie, anything besides api's to system calls, and writing drivers and kernels). "But it's so much faster" I hear all the B.Sc's saying. And they're right, it does run faster. It also takes ten times as long to code. And ten times as long to find all the strange bugs and buffer overflows that eventually show up as exploits.
Paul Graham hints at it in his article, but there is no good language right now for writing applications in. PHP in itself is a nice language to write, although it's an interpreted language, not compilied. Perl is a bit too messy for my liking (Paul also mentions this when he says he knows people who wrote perl programs and came back and couldn't understand how they worked), although it is quite powerful. Java is nice in theory, but implemented a bit slowly, and it's a bit too scientific, really -- you spend so much time handling exceptions and making sure all your code is very formal.
So what's the answer? I don't know. But it doesn't exist yet, as far as I know. Until then I'll continue running my slow PHP programs on modern "slow" computers. That run at a mere 1.5 GHz.
Python (Score:2)
Re:Great Quote (Score:2, Insightful)
When utilized properly they're nice things. =) But that's just my humble opinion
Re:Great Quote (Score:5, Insightful)
You carefully qualified your statement so I won't lay into you
An increasing number of smart people are starting to ask questions about that party line though. They'll try out a dynamic language like Python, and the disaster promised by the static typing advocates conspicuously fails to materialize. For two examples of this, see Are Dynamic Languages Going to Replace Static Languages? [artima.com] and Strong Typing vs. Strong Testing [mindview.net]. A lot of other people are leaning this way too in newsgroups and on personal weblogs, and of course a lot of people still believe the party line.
Personally, I'm suspicious of "received wisdom" that's much older then 10 or 20 years, as the static typing claims are; the world has changed a lot since then in a lot of ways, not least of which is our improved understanding of how to build things (i.e., even in non-technological ways).
Amen, brother!!! (Score:3, Insightful)
I have also battled it out here on Slashdot. C sucks!!! at first, it seems the all-out powerful language that you can do anything with it. And indeed you can!!! but it takes a lot of time, because the programmer has to define all details by hand.
I've caught myself thinking mu
Re:Great Quote (Score:3, Interesting)
Personally, I find it nothing short of terrifying that C is still used as much as it is. When you're dealing with hard realtime constraints, or an embedded system which barely has a bit of memory to spare, etc., then I can see it... but otherwise, for God's sake, use something appropriate to the problem set.
Personally, I love LISP. If only there were good UNIX API bindings for it, and a good
Re:Great Quote (Score:4, Insightful)
Paul Graham is a well-known Lisp programmer. He didn't beat us over the head with it in his article, but I'm pretty sure that he considers Lisp (Common Lisp, in particular) to be that good language, for yesterday and today at least.
I suppose that it's an acquired taste, but I'm convinced that it's a taste well worth acquiring. Here [pragmaticprogrammer.com] is a little screed I wrote to explain why I hold that conviction. Graham wrote several articles which tell his reasons. Some which pop to mind are: Beating the averages [paulgraham.com], Lisp in web based applications [yahoo.com] and What made Lisp different [paulgraham.com]
By the way, Lisp doesn't have to be very slow. Here is a pointer [cmu.edu] to a paper which might get you started.
This is part of a larger problem (Score:4, Informative)
that is being addressed partly by the research and practice of agile methodologies [agilealliance.org]. The idea is to change the focus of software development to a new set of principles (for example favoring running software over documentation).
There is also a problem with the way that many managers and business people view software creation as a construction or engineering process. I wrote a paper about this: "The Software Construction Analogy is Broken [kuro5hin.org]". The summary is that software has so many attributes that are unlike physical things that its creation cannot be accurately mapped to the creation of buildings. For example, the economics of distribution are completely different: a building cannot generally be moved after it is constructed, yet software can not only be moved, but also can be duplicated for almost zero cost.
Ultimately, I think that software creation is actually the creation of completely new media of communication. Every program created defines a new set of communication interactions that didn't exist before. We don't really have any "science" for that.
Paul Graham isn't the typical hacker (Score:5, Interesting)
That said, his view of what it means to hack is certainly different than what it usually means in geek circles. Actually, I should go further than that: Paul Graham isn't even a geek. Nobody would call Feynman or Dyson a geek, would they? Paul Graham is someone of high intelligence who happens to be applying that intelligence to computer programming (and writing, and speaking, and painting). This is much different from the typical hacker who pounds out C code because he has nothing better to do and revels in the geek traditions of arguing about Linux distributions, Star Trek movies, and yes, posting to Slashdot. In short, Paul Graham is a geek by association, because of what he decided he likes to do, whereas most hackers revel in their own geekiness, pointless and inbred though it may be.
Re:Paul Graham isn't the typical hacker (Score:3, Funny)
Have you read any of Feynman's books? That guy was an uber-geek. Any guy who would ask every girl at a party "Would you sleep with me?" based on a theory that 0.1% would say yes is pretty much a poster child for geekness. And don't get me started on his little geek-jokes in his technical writings.
Of course, being a geek doesn't make him any less a genius.
Re:Paul Graham isn't the typical hacker (Score:3, Interesting)
Yes, I've read them. The meaning of "geek" has changed. Feynman lived his own life; he did was he wanted. "Geek" these days is a lot more of a word for branding someone with a certain set of limited interests. If someone goes home and writes fantastic software in the evenings, he or she isn't a geek. But if he writes essays about Star Wars, endlessly posts to discussion forums about the evils of Microsoft, and spends more time installing
Art, Programming and design skill (Score:3, Interesting)
Art (can) be about seeing overall patterns and relationships between seemingly dissimilar things, as well as about organizing and processing information in a way that gives meaning to it.
Sounds like the skills I use everyday as a programmer.
Computer Science is Science (Score:4, Insightful)
How many people out there with C.S. degrees have gotten jobs that require them to develop, for example, a new compression algorithm? When's the last time you wrote your own language and a complier to go with it? I'm not saying it never happens, but the reality is that most Computer Scientists wind up being Software Engineers.
I mean, It's important to have the scientific background when being an engineer. How many civil engineers do you know that never learned static-state physics? But developing software systems is no more a science than designing cars or buildings. It's applied science, which is a different thing.
Hacking, Painting and Musicians (Score:2, Interesting)
They act like I am really unusual. Util I read this article I was starting to think I was the only one.
Why are Musicians so common but Painter's not in the Hacker community?
Too man over-generalizations (Score:2, Insightful)
Sure there is. Just because a term is overused doesn't mean it does not have legit application. Just because he doesn't like the term because it doesn't fit in with his vision does not provide a basis from which to dismiss the term.
Good software designers are no more engineers than architects are.
How many people today only design software, and never code or test it? How many people design s
Programming and Art (Score:2)
http://www.ratajik.net/ar
Programming and Art (Score:2)
http://www.ratajik.net/art/ [ratajik.net]
like (Score:2)
Rose tinted shades (Score:3, Interesting)
people always look at me funny (Score:3, Interesting)
i always felt that the most important issue, was not just being a maker, or constructivist, but being professional about my business conduct. if there was one and only one thing i learned it was that a proper presentation of one's self would decide if someone else will pay you to make things for them. after that, its all wine and roses, and blooshot eyes and doing what you love.
The supreme accomplishment is to blur the line between work and play. Arnold Toynbee (1889 - 1975)
fashion (Score:3, Interesting)
Oh? So what besides "fashion" explains C++? Or Java? Or Perl?
Bah (Score:4, Funny)
It's the number of cool chicks you meet in university.
(I'm a programmer and a cartoonist. Close enough?)
Great insights. But I have about three deltas. (Score:3, Insightful)
The first bump in the road was the flame against strong typing. I have found that strong typing is a wonderful aid. It lets the compiler help you keep track of whether the pieces of your concept fit together - and it comes into play exactly as your meat-computer hits its boggle-threshold. If it gets in the way, it is usually because your concept is flawed, and it is an arrow pointing straiht at the flaw, allowing you to fix it before you've built half a building on a sand foundation and must rework it all. In the language I'm most familiar with (C++, though this also applies somewhat to ANSI C), in those cases where it truly does get in the way it is trivial to subvert it - and the subversion itself clearly expresses your intent.
Next: The self-documenting code falacy and the denigration of comments. He has the right idea about leaving trail markers to inform those who come later, including especially "future-you". And for that either clear programming or comments work. But comments (as well as other documentation) serves a different purpose as well.
Someone debugging - be it another team member, a software tool, or even far-future-you - can't say whether a program is right or wrong. They can only say whether it does what is intended. "cat" is correct for what it does - but if you wanted "diff" it's REALLY broken. Once the design has drained from you memory - or another person works on it - this reduces to comparing two (or more) expressions of the intent. With "self-documenting code" you have ONE expression of intent - so virtually "all you can test is the compiler".
For maximum effectiveness the two expressions should be as different as practical. One, of course, must be the code itself. Comments, specs, or other optimized-for-human-readability prose works well for the other - unless you have a "correctness-proving" tool or a software documentation formalism that you must write for. (In the case of proof tools you probably need three expressions - spec and/or comments, code, proof-tool code.)
Yes the design starts as a sketch and fills in as you go. But as you change things you need to keep the code and the other expression in sync. Sometimes the code is wrong and you fix it. Sometimes the code shows you a problem in your concept, opens your eyes to a new possibility, etc. Then you fix the documentation. The two co-evolve.
Third: Mostly an ommission - though the "saving up bugs for later" comment makes it explicit. I view actually writing a program much like growing a perfect crystal. You start with a sketch. But as you fill in the sketch you debug what you filled in until it does EXACTLY what was intended for that part - or what you thought it should do at the time. This confines your debugging to the code you recently added - either what you're working on right now, or what you thought you had right a few minutes ago has an interface design flaw exposed as you go to use it. You have a similar number of bugs - but your search space is so small that you swat them immediately. This gets you a completely debugged system of crystaline perfection in about three times as long as ONE iteration of "get it to compile and fix one bug" in the hunt-and-peck approach.
Static typing is not strong typing. (Score:3, Informative)
C/C++ are statically typed. You determine the type of variables at compile time, not runtime.
C/C++ are weakly typed, not strongly typed. You can cast from one type to another. In a strongly typed language, once you've defined the type of an object (or storage location), you can't change it.
Graham is a lisp advocate. Common lisp is dynamically typed. The runtime checks types at runtime, not compile time. Common lisp is strongly typed. A lisp object cannot change its type
Keeping programs as short as possible (Score:5, Interesting)
When I have to code in Java (most of the time), I try to keep my applications as short as possible by first developing and testing low level class libraries to support a project - once these are tested, I find it easier to write much shorter application programs that I can tweak easily.
Still, I find Common Lisp to be my most productive language (Smalltalk is pretty good also :-).
-Mark
Re:So why is Lisp fading? (Score:3, Informative)
One answer is that it is not fading (too much :-)
There are several fine commercial Lisp development systems and many fine/good free Common Lisp compilers.
You are right though - relatively few programmers seriously use Lisp. This does not bother me in the least. Personally, I always like to use the right tool for a job. Choosing the right tool also involves issues like "can I find a programmer to maintain this code", etc.
I used Common Lisp recently on a commercial product that I developed
Re:So why is Lisp fading? (Score:3, Insightful)
Most companies will foolishly opt for 3 code monkeys (i.e., inexperienced, unproductive programmers) rather than one lisp master at 3 times the salary. This overlooks the fact that the lisp master is often 5 or 10 times more productive.
It's the same reason businesses choose cheap everything. Bean counters rarely look past initial cost.
Paul Graham's succ [paulgraham.com]
Re:So why is Lisp fading? (Score:3, Insightful)
Common Lisp is actually a relatively new language. It draws on older languages such as MACLISP, ZetaLisp, Scheme, and ALGOL, certainly, but it breaks away from each of them. Unlike every Lisp before, it takes lexical scoping (by default) from Scheme. But it retains a separate namespace for variables, functions, etc, unlike Scheme. It uses function names drawn from MACLISP but hammers down the semantics of interpretation and compilation (
a great related article about . . . (Score:3, Interesting)
pg mentions john lions and his supressed Unix tome. this is a great feature article about it, and some (possibly not so anonymous) linux kernel hacker with a really kewl girlfriend.
I gotta agree with this guy... (Score:3, Interesting)
Some folks ask me why I don't paint anymore, and I tell them I get my creative kicks writing software. Nice to know I'm not the only one who thinks this way (because you know the management won't understand!).
It's _one_ point of view (Score:5, Interesting)
Software is obviously not a single subject: it is like language, and can be applied in many different ways.
Let me take a simple example. There are two main ways that people look at the world of problems: they search for the commonality, or they search for the particularity. Now, I would argue that good software is built by finding the common patterns and solving those, but that is just the way I make software. Other people I've worked with do the opposite: they focus on hundreds or thousands of individual cases. Clearly we have different types of mind - what I consider mindless and irrelevant detail is to my colleagues the only part worth solving.
Painters, artists obviously work the same way. So do writers, archietcts, and all creative people, including scientists. There are hacker chemists, and there are the synthesizing chemists.
Personally, I find that the best art comes from using standard patterns in new way: for instance, good photgraphy relies on excellent understanding of light and subject, but every image must be unique. The best science takes the other extreme: determined effort to find the core patterns and understand those. Ten experiments that are each unique are worthless. Ten experiments that give the same results each time are perfect.
Two more dimensions to this, in my experience. First, men and women tend to different approaches when it comes to creating and problem solving. More men like to hack, not because we're taught that but because our brains work that way. Second, with age our minds also seem to change: older brains can understand a depth of asbtraction that escapes younger minds. Software is all about abstraction, unlike science or art, but very much like language. Young geniuses may be able to hold thousands of details in their heads, but they cannot (generally) use them to build large-scale abstractions that work well. Again, the same for writers.
No accident that some of the best programmers ever are also linguists and writers.
Re:Computer programming is NOT an art. Get over it (Score:2, Insightful)
Re:Computer programming is NOT an art. Get over it (Score:4, Insightful)
Using microsoft products evokes a raticaly diffrent reaction then using let's say an Apple product, or a Linux product.
Why would it be insulting for art and science to be the same thing. A good deal of science goes into art, and art into science.
Re:Computer programming is NOT an art. Get over it (Score:2, Insightful)
Re:Computer programming is NOT an art. Get over it (Score:3, Insightful)
Neither is an art in itself, but a programmer or painter _can_ use their tools to create art.
In other words, saying "computer programming is art" is wrong just as saying "paint and brushes are art" but a painting or a program can both be art.
Re:Computer programming is NOT an art. Get over it (Score:3, Insightful)
Excuse me, I've seen some pieces of code that are VERY beautiful and emotional. I'm not saying that a programmer and a painter should be grouped together, but there can be some extreme beauty in a piece of code. That's like saying that minimalists aren't artists because I think that a yellow dot on a red piece of canvas doesn't draw any emotions. Other people might look at that dot and see their entire life summed up, and get all teary eyed. Diffe
Re:Computer programming is NOT an art. Get over it (Score:2, Interesting)
What about this [thinkgeek.com]?
Art or no?
Re:really? (Score:2, Informative)
And when you RTFA, you'll realize that your comment has nothing whatsoever to do with the article.
Re:really? (Score:3, Interesting)
Shame you didn't RTFA, as your point is explicitly addressed:
Re:"a language that lets us scribble and smudge".. (Score:3, Funny)
Re:"a language that lets us scribble and smudge".. (Score:3, Insightful)
Re:Just dawned on me (Score:3, Funny)
"Let's boycott people and not buy any DVDs!"
"New sci-fi DVD out this week, buy it!"
"All big computer companies are simply profit-oriented"
"Apple releases new thing"
"Most of the world's population are sheep driven by obvious marketing"
"Isn't this new thing cool and shiny? Buy one! Hell, buy two! Shiny shiny!"
"Microsoft does thing, isn't it evil?"
"Linux does thing, rejoicing in the streets"
...oh, and..
"Ask Slashdot: Finding your rear-end with b
Re:I was taking it fairly seriously until... (Score:4, Informative)
Graham is a Lisper. Lisp is a strongly typed programming language, as opposed to, say, C: Every Lisp object knows its type, and there is no way to do something with this object that would require another, incomapible type, while C basically treats every object as of the type "bunch of bytes", and attaches type information to variables to (loosely) restrict what bunches of bytes can be associated with a given name, while not preventing you from casting a struct stat to a char*. On another, unrelated axis, Lisp is dynamically typed, while C is statically typed, i.e. Lisp does (most of) it's type handling at runtime, not at compile time.
Dynamic typing has nothing to do with sloppyness, while loose typing has. "Strong" and "static" are not the same, neither are "loose"/"weak" and "dynamic". Can't be that hard.