Subject: Re: Why lisp failed in the marketplace From: Erik Naggum <erik@naggum.no> Date: 1997/02/27 Newsgroups: comp.lang.lisp,comp.lang.scheme Message-ID: <3066031941459593@naggum.no> * Markku Laukkanen | Well, I consider myself a good Lisp programmer, and it took me over a | year to MASTER the Common Lisp. Of course, if you mean some C/C++ like | programming, it is possible to grab CL quite soon, but to learn CL in two | weeks.. That is a good joke. more anecdotal evidence: I don't know how much time I spent learning the basics in Lisp, because I don't think I spent any conscious time on it. The Little Lisper lay on a table in the "pause area" where I once worked, and I picked it up and read it. reading that book was probably all it took to get most of the basics down pat. (I was somewhere between 13 and 15 at the time, probably very impressionable.) the rest has just sort of floated my way, _except_ for the more advanced aspects of CLOS and the condition system, which I still find troubling -- philosophical misalignment, I guess. (`change-class' still makes me queasy, but I was on the road to reinventing it, so I have come to conclude it can be the Right Thing when state-changes are easier to express with class changes.) most of my journey in Common Lisp has been a series of incidents like this: a week of programming, realizing that I'm doing "grunt work", having a flash of anxiety that this is "bad", reading up on some of the stuff I didn't see any use for or didn't understand in Steele or the HyperSpec, and getting much relieved, then deleting 500 lines of code and doing that week's work over in two hours. very satisfied, I write my observations down in a "programmer's log", take the rest of the day off, and play with the concept (and my cat). two years of that, and I think I have a pretty good grasp of the language. (Scheme, in contrast, gives me the feeling that this kind of "grunt work" is _not_ bad -- Scheme programmers implement complex stuff with basic buildings blocks over and over, it seems.) however, and this is what I find important, at no point in my using Common Lisp have I been _stumped_, or feeling that I was banging my head against a wall of minutiae or any such thing. I didn't _need_ to "master" Common Lisp to use it well. the simpler aspects of CLOS was shown to me by a friend not long ago -- it's just been saving me time, not the insufferable hair that I had to fight myself through in C++. I'm sure C++ can be as easy to learn as CLOS (Andrew Koenig's ever-present counter-argument that C++ is hard is that he can teach people this stuff in mere days), but _mistakes_ in C++ devour you (and sometimes your machine), and face you with language details you didn't even know _could_ exist. a C++ programmer might very easily see his program do something completely insane and spend the next three days trying to figure out what the hell happened, just to find that he had declared a new function and some other function was called with an argument of the wrong type and some constructor was called that he didn't even know would be affected by his new function. contrast this kind of incident (I had one of them a week, not all equally severe, when I tried to use C++ in a project in 1993) with the Common Lisp incidents I described above. C++ instilled in me a fear of mistakes that crippled my ability to experiment with the language, because I was unable to see the chain of events that led to the compiler's decisions, and I don't think I should have had to, either. Common Lisp provided me with an environment where mistakes had a _very_ low cost and offered early and precise detection to boot. this provided me with an early warning system for anything I might need to look up or study more. in C++, I would tend to think "sh*t, this _should_ work", whereas in Common Lisp, I would think "hmm, that's odd", and reach for the documentation. (I have subtracted for the normal bug-hunting in all the software I use in these descriptions.) concluding from the way I have learned many different programming languages (and CPU's) over the years, I'd say that the _only_ thing that matters to a student of a language is that he can _trust_ the language. I can trust C, I can trust Common Lisp, but I _could not_ trust C++. most of today's programmers _don't_ trust their programming language or environment and thus have a hard time with the "trust" concept, or so it seems, anyway. (speaking of trust, allow me a digression: people will associate feelings of distrust and the resulting powerlessness with some part of the learning experience, but not necessarily the right one. I suspect that some of this distrust from other languages is hurting Lisp. I speculate (I haven't made the slightest effort to test this idea on others, however) that when a programmer in a syntax-rich language reaches for the parens, it is because he cannot trust the compiler to do what he wants. I know from my own experience that I have had to add parens to oddly misbehaving expressions in C, but I haven't associated the pain of the debugging with the parens -- I have associated it with the infix syntax. if you associate the pain with the parens, how will you feel about a language where there are parens all over the place? now, if you're into conspiracy theories, or just enjoying them, consider that the most overloaded of all the horribly overloaded operators in C++ are the parens. if you were desinging a language, and you understood this feeling of distrust and the associative nature of the human brain, would it not be a great idea to make parens the most painful of all your operators if you wanted to keep your victims from discovering Lisp?) #\Erik -- if you think big enough, you never have to do it