(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Monday, October 16, 2006
Irony
From time to time people quote this as a justification for staying away from high-level languages like Lisp, Scheme, Python, and Ruby, and not only sticking to popular languages but also staying within the lowest-common denominator when choosing idioms within those popular languages.
Isn’t it interesting that the quote is from a book explaining concepts such as recursion and metalinguistic abstraction? In Scheme?
The full text is on line. If you have yet to read it, I recommend you give it a try.
update: if you enjoyed reading SICP, you may find my list of the first seven books I would buy if my shelves were bare interesting.
Programs must be written for people to read, and only incidentally for machines to execute.
Abelson & Sussman, Structure and Interpretation of Computer Programs
From time to time people quote this as a justification for staying away from high-level languages like Lisp, Scheme, Python, and Ruby, and not only sticking to popular languages but also staying within the lowest-common denominator when choosing idioms within those popular languages.Isn’t it interesting that the quote is from a book explaining concepts such as recursion and metalinguistic abstraction? In Scheme?
The full text is on line. If you have yet to read it, I recommend you give it a try.
update: if you enjoyed reading SICP, you may find my list of the first seven books I would buy if my shelves were bare interesting.
Comments on “Irony”:
<< Home
Perhaps we would have better software if we acknowledged the minimum standard of competence required to maintain a piece of software responsibly.
Yep, it's one of the few texts which are focused on the concepts of programming, not on the specific syntax of a language.
Very very good but not easy.
It Should be on every dev "Short List Of Mandatory Books".
Very very good but not easy.
It Should be on every dev "Short List Of Mandatory Books".
From time to time people quote this as a justification for staying away from high-level languages
This just kills me. I also hear people complaining that a very hard to understand algorithm should be ripped out in favor of 500 lines of baby-talk code.
I would upgrade Abelson & Sussman's quote with one key difference, however: Programs should be written to be understood by programmers.
If you need to do a very hard transformation on some data, and you can do it by grinding out hundreds of lines of baby-talk or by expressing the transformation directly in all its feral glory, you should express it directly.
If the what of your code is very hard to understand, cluttering it up with chattering how will only serve to further obscure that hard concept.
This just kills me. I also hear people complaining that a very hard to understand algorithm should be ripped out in favor of 500 lines of baby-talk code.
I would upgrade Abelson & Sussman's quote with one key difference, however: Programs should be written to be understood by programmers.
If you need to do a very hard transformation on some data, and you can do it by grinding out hundreds of lines of baby-talk or by expressing the transformation directly in all its feral glory, you should express it directly.
If the what of your code is very hard to understand, cluttering it up with chattering how will only serve to further obscure that hard concept.
I haven't read the original text, but I don't see how that's a justification from staying away from high-level languages.
I think an admonishment to keep your code readable equally applies to every language.
It's still very possible to write spaghetti code in high-level languages, and I certainly see enough of it day-to-day.
I think an admonishment to keep your code readable equally applies to every language.
It's still very possible to write spaghetti code in high-level languages, and I certainly see enough of it day-to-day.
It should be the case again that shades of grey apply - if the problem is hard and it requires hard code to perform then so be it. There may be more straight forward ways to solve the 'hard' problem but likely the hard code that was written to solve it will not look very different. In this case I would just write a nice lengthy code comment to attempt to explain/justify what the hard code is doing. I don't see the point in writing 'hard' code in a more simplistic drawn out way just because I can and because it would make it more understandable to a beginner - I would rather train and bring the begining programmer up to a level of understanding then dumb down something that maybe harder to understand but perfect elegant in execution. - My 2 bits.
I don't see the point in writing 'hard' code in a more simplistic drawn out way just because I can and because it would make it more understandable to a beginner
I think we should distinguish between being able to understand the algorithm at a micro and macro level.
If you "baby-talk" an algorithm, a novice can point to any twenty lines of code and say "this is what that code does," I agree.
And there is a temptation to think that because the novice can understand the code at a micro level, they must be able to build a picture in their mind of what five hundred or more lines of code are doing at a macro level.
But this is not necessarily true. The novice has to infer the "macro" behaviour from "micro" evidence, and in many cases this is a very hard job.
Remember, we are taking as a given that we are solving a "hard" problem, and if the problem is hard, inferring the "hard" solution from a pile of code is incredibly hard.
When we write at a higher level, whether by importing idioms or by using a more abstract tool, we might be able to express the entire "hard" solution in twenty lines of code.
It is far easier for the novice to grasp the "macro" solution from dramatically fewer lines of code.
There is still work to be done for the novice to figure out each line, but I find it easier to "drill down" than to "build up."
I think we should distinguish between being able to understand the algorithm at a micro and macro level.
If you "baby-talk" an algorithm, a novice can point to any twenty lines of code and say "this is what that code does," I agree.
And there is a temptation to think that because the novice can understand the code at a micro level, they must be able to build a picture in their mind of what five hundred or more lines of code are doing at a macro level.
But this is not necessarily true. The novice has to infer the "macro" behaviour from "micro" evidence, and in many cases this is a very hard job.
Remember, we are taking as a given that we are solving a "hard" problem, and if the problem is hard, inferring the "hard" solution from a pile of code is incredibly hard.
When we write at a higher level, whether by importing idioms or by using a more abstract tool, we might be able to express the entire "hard" solution in twenty lines of code.
It is far easier for the novice to grasp the "macro" solution from dramatically fewer lines of code.
There is still work to be done for the novice to figure out each line, but I find it easier to "drill down" than to "build up."
You might be interested in seeing the video lectures that go with the book.
"These twenty video lectures by Hal Abelson and Gerald Jay Sussman are a complete presentation of the course, given in July 1986 for Hewlett-Packard employees, and professionally produced by Hewlett-Packard Television. The videos have been used extensively in corporate training at Hewlett-Packard and other companies, as well as at several universities and in MIT short courses for industry."
Video Lectures by Hal Abelson and Gerald Jay Sussman
"These twenty video lectures by Hal Abelson and Gerald Jay Sussman are a complete presentation of the course, given in July 1986 for Hewlett-Packard employees, and professionally produced by Hewlett-Packard Television. The videos have been used extensively in corporate training at Hewlett-Packard and other companies, as well as at several universities and in MIT short courses for industry."
Video Lectures by Hal Abelson and Gerald Jay Sussman
# posted by 
: 9:07 PM
: 9:07 PM
"From time to time people quote this as a justification for staying away from high-level languages like Lisp, Scheme, and Ruby"
Who? I don't believe you.
Who? I don't believe you.
# posted by : 6:25 AM
: 6:25 AM
Who?
I'm not naming names because I don't think that using this quote invalidates the point they're trying to make.
I don't necessarily agree, but I'm not claiming that they've scored a bit of an own goal, either.
If you absolutely must search for citations, try the comments on various posts right here in this blog, or over at programming.reddit.com.
Speaking of irony, one amusing thing about reddit is that it is very popular, has positive cash flow, and is a Y Combinator startup.
It's also one of the most popular places to criticize Y Combinator startups. Y Combinator is, to a small extent, cashing in on their detractors :-)
I'm not naming names because I don't think that using this quote invalidates the point they're trying to make.
I don't necessarily agree, but I'm not claiming that they've scored a bit of an own goal, either.
If you absolutely must search for citations, try the comments on various posts right here in this blog, or over at programming.reddit.com.
Speaking of irony, one amusing thing about reddit is that it is very popular, has positive cash flow, and is a Y Combinator startup.
It's also one of the most popular places to criticize Y Combinator startups. Y Combinator is, to a small extent, cashing in on their detractors :-)
Using the same reasoning, assembly languages are extremely simple (and they mostly are) - I can point to any handful of instructions and know exactly what they do. What I find difficult (and why people bother with higher level languages at all) is seeing the big picture. Each individual instruction is damned simple, but that does not make the overall routine or program simple. If anything, it makes it harder to understand because you have to keep more instructions in your head and think about how they fit together as a whole.
In a high level language, an instruction may be harder to understand, but it becomes a lot easier to understand the big picture. I think this is probably because you have to think about fewer instructions at once. My mind only has so much RAM...
For this reason, I completely agree with this post. When Hal Abelson and Gerry Sussman said that, they were (I would assume) talking about the big picture, not the individual instructions.
In a high level language, an instruction may be harder to understand, but it becomes a lot easier to understand the big picture. I think this is probably because you have to think about fewer instructions at once. My mind only has so much RAM...
For this reason, I completely agree with this post. When Hal Abelson and Gerry Sussman said that, they were (I would assume) talking about the big picture, not the individual instructions.
<< Home
