On Complaining, Off Lisp
I've really been trying to avoid griping about technical problems on this blog. I think such things are more often than not foolish; more often than not the complainer is missing a small detail that is causing his/her whole problem. All of their anger is over nothing. In general, I think that's why it's a good idea to not get angry at things. Of course, I'm not that perfect, so I just try and keep it to myself.
But alas, I'm having technical problems. While I don't believe in catharsis, I do think that typing up and clarifying my thoughts might be valuable for some insight and introspection. I also don't post here enough, so what few readers I might have get to suffer through it. I promise I'll try and be constructive.
Much to my (pleasant) surprise, my internship in Germany has me working in Lisp. As such, I thought it'd be a good idea to read up on some of the writings of Paul Graham one of the loudest evangelists for the language. I have his "ANSI Common Lisp" book, and went through the exercises in the first few chapters on BART for a few weeks a year ago. Lately, I've been perusing his book "On Lisp" during my free-time, really wanting to believe the language is everything he says it is.
Graham's evangelism has always touched a nerve for me. I really want to like Lisp; I want it to be the magical panacea for programming that Graham insists it is. But I can't honestly read most of his gushing without getting the impression of a snake-oil salesman. I'm not accusing him of being a liar. More than likely, I do not completely understand what he's trying to get at. But so many of his early justifications for lisp look like a lot of hogwash.
Who knows, maybe I did learn a thing or two about critical thinking from high school; who'd have though?
Let's take his diatribe on utility functions which takes up just about all of chapter 4 in "On Lisp." Graham spends a chapter on some simple (and possibly very useful) utility functions to demonstrate bottom-up programming in Lisp. He goes on to justify utility functions as if other languages never had such things. As far as I can tell, Graham is describing what every library in the world does. In fact, I remember when that seemed like such a cool thing in C, or C++, or Java. There are some subtle advantages to his examples (namely, that Lisp allows you to pass functions around and declare them on the fly with more leverage than C++), but the tone of the passages make it sound like he's never seen a library. Graham also goes on about macros as if they're the best thing since sliced bread. So far, they look like little more than C++ templates. However I haven't read the macro chapter yet, so I shall see.
But it's little things like this that give me so much trouble understanding what exactly Graham means by "bottom-up programming." It sounds exactly like top-down programming, except you're avoiding design. I have yet to see design book suggest that you don't abstract your functions so that you can use them again; yet that's exactly what I feel like Graham is criticizing top-down approaches for.
I think one of the reasons I gave up on Lisp last summer was because of this sort of writing. It just leaves a sour taste in my mouth. I'm going to try and push through "On Lisp" more though; I might as well since I'm programming in Lisp anyway. And hey, it doesn't really matter if it's not the panacea Graham makes it out to be; I like what I've seen so far in the language, even if I'm probably not using it to its full potential. And who knows, even if he's wrong, I might learn a thing or two.
What might be more helpful would be if I printed out his book, and make annotations of all of the little things that bother me as I go along. Then, as questions are answered, cross off those little annotations, or at least point out where they were answered. The book is 400+ pages though, so I need to find a printer where that kind of printing is okay. I could probably cut it down to 100 sheets of paper, but that's still pretty crazy. It'd be really awesome if I could annotate his PDF. I ought to figure out how to write a utility like that, except it's probably been done. And I'm lazy. It'd be even cooler if I had a tablet PC to do it on. Or if I had my wacom tablet with me. Some way to hand-write it.
All this talk of wanting-to-believe makes me think that I need a big poster on my wall that looks like Fox Mulder's "I want to believe" poster, except with a big lambda instead of a UFO.
The biggest problem I have learning any new programming language always seems to be people's refusal to connect ideas to other programming languages. No C# text I've seen is willing to compare it to Java, even though they're both practically the same language. Many Java texts seemed reluctant to compare it to C++, except to say how it's better. It feels like everyone is willing to say how much better they think they are, but they aren't willing to say how they're the same. "We're great, because we have this feature that's been around since the 70s! But we won't admit it!"
Am I really the only one who learns by finding out how things are similar, and building off of that? Hell, I seem to have the same problems with foreign languages; people seem hesitant to make comparisons because of corner cases. But corner cases are just that; it's easier to learn "this is the same, but keep this one thing in mind" rather than "They are different! Don't even try to compare them! You'll just confuse yourself."
It's a pity too, I really enjoy seeing at how similar both real and programming languages are to each other.
But alas, I'm having technical problems. While I don't believe in catharsis, I do think that typing up and clarifying my thoughts might be valuable for some insight and introspection. I also don't post here enough, so what few readers I might have get to suffer through it. I promise I'll try and be constructive.
Much to my (pleasant) surprise, my internship in Germany has me working in Lisp. As such, I thought it'd be a good idea to read up on some of the writings of Paul Graham one of the loudest evangelists for the language. I have his "ANSI Common Lisp" book, and went through the exercises in the first few chapters on BART for a few weeks a year ago. Lately, I've been perusing his book "On Lisp" during my free-time, really wanting to believe the language is everything he says it is.
Graham's evangelism has always touched a nerve for me. I really want to like Lisp; I want it to be the magical panacea for programming that Graham insists it is. But I can't honestly read most of his gushing without getting the impression of a snake-oil salesman. I'm not accusing him of being a liar. More than likely, I do not completely understand what he's trying to get at. But so many of his early justifications for lisp look like a lot of hogwash.
Who knows, maybe I did learn a thing or two about critical thinking from high school; who'd have though?
Let's take his diatribe on utility functions which takes up just about all of chapter 4 in "On Lisp." Graham spends a chapter on some simple (and possibly very useful) utility functions to demonstrate bottom-up programming in Lisp. He goes on to justify utility functions as if other languages never had such things. As far as I can tell, Graham is describing what every library in the world does. In fact, I remember when that seemed like such a cool thing in C, or C++, or Java. There are some subtle advantages to his examples (namely, that Lisp allows you to pass functions around and declare them on the fly with more leverage than C++), but the tone of the passages make it sound like he's never seen a library. Graham also goes on about macros as if they're the best thing since sliced bread. So far, they look like little more than C++ templates. However I haven't read the macro chapter yet, so I shall see.
But it's little things like this that give me so much trouble understanding what exactly Graham means by "bottom-up programming." It sounds exactly like top-down programming, except you're avoiding design. I have yet to see design book suggest that you don't abstract your functions so that you can use them again; yet that's exactly what I feel like Graham is criticizing top-down approaches for.
I think one of the reasons I gave up on Lisp last summer was because of this sort of writing. It just leaves a sour taste in my mouth. I'm going to try and push through "On Lisp" more though; I might as well since I'm programming in Lisp anyway. And hey, it doesn't really matter if it's not the panacea Graham makes it out to be; I like what I've seen so far in the language, even if I'm probably not using it to its full potential. And who knows, even if he's wrong, I might learn a thing or two.
What might be more helpful would be if I printed out his book, and make annotations of all of the little things that bother me as I go along. Then, as questions are answered, cross off those little annotations, or at least point out where they were answered. The book is 400+ pages though, so I need to find a printer where that kind of printing is okay. I could probably cut it down to 100 sheets of paper, but that's still pretty crazy. It'd be really awesome if I could annotate his PDF. I ought to figure out how to write a utility like that, except it's probably been done. And I'm lazy. It'd be even cooler if I had a tablet PC to do it on. Or if I had my wacom tablet with me. Some way to hand-write it.
All this talk of wanting-to-believe makes me think that I need a big poster on my wall that looks like Fox Mulder's "I want to believe" poster, except with a big lambda instead of a UFO.
The biggest problem I have learning any new programming language always seems to be people's refusal to connect ideas to other programming languages. No C# text I've seen is willing to compare it to Java, even though they're both practically the same language. Many Java texts seemed reluctant to compare it to C++, except to say how it's better. It feels like everyone is willing to say how much better they think they are, but they aren't willing to say how they're the same. "We're great, because we have this feature that's been around since the 70s! But we won't admit it!"
Am I really the only one who learns by finding out how things are similar, and building off of that? Hell, I seem to have the same problems with foreign languages; people seem hesitant to make comparisons because of corner cases. But corner cases are just that; it's easier to learn "this is the same, but keep this one thing in mind" rather than "They are different! Don't even try to compare them! You'll just confuse yourself."
It's a pity too, I really enjoy seeing at how similar both real and programming languages are to each other.