Lisp
I listened to a podcast of Guido Van Rossum, the architect of Python, talking at SD forum recently and, although it made me vaguely irritable the way dynamic typing people often condescendingly assume that "strong typing is for weak minds" (actual quote from an audience member), it did resurrect my desire to learn a new language.
Not Python - despite Pythonistas' claims I've done enough Python to convince me that it isn't different enough from other OO languages to change the way I think about programming. Indeed, since Python didn't start out OO, it can be slightly obtuse in that area - I think I'd like to avoid writing "self.foo" all the time to reference data members, and avoid, too, the subtle bugs that come with forgetting the "self" (I realise that only weak minds would make this mistake though).
I recently revisited Paul Graham's writings on Lisp, and his claim that all languages strive to become Lisp (Guido touched on that too in comparing Python to Lisp), so I decided to have another go at that disturbing language (I'll elaborate on the "disturbing" part next). Luckily Paul Graham has a very good book available online called "On Lisp".
What I immediately found from the first few chapters of Graham's book is that, although I can recognise deep down the elegance of Lisp, I find I can't "think" in it at all. I had the same experience at Uni looking at examples in Lisp and Miranda - after some forehead-wrinkling and mental contortion they finally clicked in my head and I was able to see the mathematical elegance of the solution. Although the elegance can be somewhat lost when "real" Lisp programmers try to avoid non-tail recursions for performance reasons and make the code that much less clean - see section 2.8 of the book if you care.
The problem may be that I had already learnt to program before I went to Uni. I learnt snippets of basic on my friend's Commodore 64. Then I moved to MS GW BASIC when my family finally got our own, IBM compatible, PC. From there I moved to QuickBasic, which lived up to it's name - I've never had such a speed improvement for "free" by just by upgrading compilers, it was almost like magic. QuickBasic had examples of programming with, gasp, procedures with no line numbers. Actually, this procedure thing wasn't totally alien, I knew about gosub/return, but named procedures with actual parameters, wow, what a revelation when I "got" that idea.
From QuickBasic I moved to QuickC. C actually wasn't too much of a leap from procedural basic, except of course pointers and complex data structures were new concepts. But basically C had the same core forms as basic (pointers and malloc/free excepted). And it was a "real" programmer's language. For the first time I was able to develop (what I thought were) real applications. I eventually got into writing low-level 8086 assember inside C to do things like write to the text mode screen buffer, execute the terminate and stay resident DOS call and access the then new MS mouse BIOS driver API's (and I can still remember that it was interrupt 33H).
My rambling back down memory lane is not intended to show that I can't stay on the point. It's intended to illustrate that I've had nearly 20 years (and I'm only 33) of procedural thinking. And while my current language of choice, Java, is a nice language, it wouldn't be at all alien to the me of 15 years ago.
So, I'm getting that same "hard of thinking" problem when reading the Lisp in Paul Graham's book. After some staring, I can get the examples, but I wouldn't have had the first clue how to write them. So it appears learning Lisp might be like my attempts to learn to touch-type, and fail for the same reason - while learning my productivity would be so painfully bad I'd give up.
It does vaguely worry me that the facility with which I can write code one way might be paid for by the inability to learn new, better, ways of doing things. After all, I somehow suspect that we haven't achieved perfection with current languages and tools.
In spite of this, or perhaps, because of it, my own belief is that language has very little overall effect on productivity. Things like GC, protected memory, sophisticated tools, copious good-quality libraries and a massive community support seem to be much more important factors than whether I can sort a list using a custom comparison function in two lines of code rather than 6. And the key factor? The quality of the developer obviously makes the most difference.
But of course I may be wrong. How can I really know whether I'd be a much better developer if I could think in Lisp? But I suspect the human mind at my age (i.e. post adolescence :/ ) has room for only one major language, programming or otherwise.
I'll keep at the Lisp though.
Not Python - despite Pythonistas' claims I've done enough Python to convince me that it isn't different enough from other OO languages to change the way I think about programming. Indeed, since Python didn't start out OO, it can be slightly obtuse in that area - I think I'd like to avoid writing "self.foo" all the time to reference data members, and avoid, too, the subtle bugs that come with forgetting the "self" (I realise that only weak minds would make this mistake though).
I recently revisited Paul Graham's writings on Lisp, and his claim that all languages strive to become Lisp (Guido touched on that too in comparing Python to Lisp), so I decided to have another go at that disturbing language (I'll elaborate on the "disturbing" part next). Luckily Paul Graham has a very good book available online called "On Lisp".
What I immediately found from the first few chapters of Graham's book is that, although I can recognise deep down the elegance of Lisp, I find I can't "think" in it at all. I had the same experience at Uni looking at examples in Lisp and Miranda - after some forehead-wrinkling and mental contortion they finally clicked in my head and I was able to see the mathematical elegance of the solution. Although the elegance can be somewhat lost when "real" Lisp programmers try to avoid non-tail recursions for performance reasons and make the code that much less clean - see section 2.8 of the book if you care.
The problem may be that I had already learnt to program before I went to Uni. I learnt snippets of basic on my friend's Commodore 64. Then I moved to MS GW BASIC when my family finally got our own, IBM compatible, PC. From there I moved to QuickBasic, which lived up to it's name - I've never had such a speed improvement for "free" by just by upgrading compilers, it was almost like magic. QuickBasic had examples of programming with, gasp, procedures with no line numbers. Actually, this procedure thing wasn't totally alien, I knew about gosub/return, but named procedures with actual parameters, wow, what a revelation when I "got" that idea.
From QuickBasic I moved to QuickC. C actually wasn't too much of a leap from procedural basic, except of course pointers and complex data structures were new concepts. But basically C had the same core forms as basic (pointers and malloc/free excepted). And it was a "real" programmer's language. For the first time I was able to develop (what I thought were) real applications. I eventually got into writing low-level 8086 assember inside C to do things like write to the text mode screen buffer, execute the terminate and stay resident DOS call and access the then new MS mouse BIOS driver API's (and I can still remember that it was interrupt 33H).
My rambling back down memory lane is not intended to show that I can't stay on the point. It's intended to illustrate that I've had nearly 20 years (and I'm only 33) of procedural thinking. And while my current language of choice, Java, is a nice language, it wouldn't be at all alien to the me of 15 years ago.
So, I'm getting that same "hard of thinking" problem when reading the Lisp in Paul Graham's book. After some staring, I can get the examples, but I wouldn't have had the first clue how to write them. So it appears learning Lisp might be like my attempts to learn to touch-type, and fail for the same reason - while learning my productivity would be so painfully bad I'd give up.
It does vaguely worry me that the facility with which I can write code one way might be paid for by the inability to learn new, better, ways of doing things. After all, I somehow suspect that we haven't achieved perfection with current languages and tools.
In spite of this, or perhaps, because of it, my own belief is that language has very little overall effect on productivity. Things like GC, protected memory, sophisticated tools, copious good-quality libraries and a massive community support seem to be much more important factors than whether I can sort a list using a custom comparison function in two lines of code rather than 6. And the key factor? The quality of the developer obviously makes the most difference.
But of course I may be wrong. How can I really know whether I'd be a much better developer if I could think in Lisp? But I suspect the human mind at my age (i.e. post adolescence :/ ) has room for only one major language, programming or otherwise.
I'll keep at the Lisp though.
posted by Matthew Phillips at
2:37 pm
|
4 comments
