begin quoting Tracy R Reed as of Tue, Feb 01, 2005 at 02:37:27PM -0800: [snip] > I have been pondering this very issue myself. I am looking at LISP but > more seriously considering Scheme.
If you're looking for some simple problems to practice in scheme, perhaps the lpsg list could look into filling out the Scheme entry in Andrea's Programming Language Matrix. There are *no* scheme entries, last I looked. [snip] > reminds me: I have his excellent book "Hackers and Painters" which I have > already read and greatly enjoyed. I is available for loan if anyone wants > it. I intend to donate it to the KPLUG library. Does anyone really check I think I need to add that to my "recommended books" list. It's been recommended several times now. > books out of the kplug library? This book is the sort of thing I wish I > could run off a bunch of copies of and give them away to friends. Having > just one copy of it is so inefficient, buying many is expensive, and a lot I wanna win the lottery so I can buy my friends the books I think they ought to have! > of people won't read it unless it is dead tree. Plus, dead tree supports the author better. Speaking of online/dead-tree, http://www.sourcetext.com/grammarian/less-than-words-can-say/ is an online version of an excellent book that I own in dead-tree format. Humor, with bite. Highly recommended. > > Besides stretching my brain, I'd like to think LISP knowledge > > actually is useful. I know..wishful thinking. > > I think the idea of functional programming is very interesting and I am > puzzled as to why it has not grown in popularity. More compact code > meaning less to verify/debug, It's not the amount of code to verify, it's the ease of verification. It's the area under the curve, not just the distance along an axis. Extremely dense code is very hard to debug. Plus, junior programmers and students are often not concerned about compact code. They write code like: somevar = (foo && bar) || (foo && !bar); if ( somevar == true ) { return true; } else { return false; } > no side-effects, A lot of programmers seem to *like* side-effects. > inherent modularity, etc. A lot of programmers don't actually like modularity. They *say* they do, but they couple strongly between modules anyway. There's a great paper out there on coupling and cohesion, and I don't know where my copy is, nor the author -- I'll have to dig it up and post the identifying information. > are all very good things that we are encouraged to do in imperative > languages but often do not because it is so easy to exercise those bad > habits. I do not think a language can make up for poor habits. If you have poor habits in imperative languages, you will pick up and use poor habits in functional languages, leading to the same sort of problems as you had before, just different. :) > The only reason I can think of for the lack of popularity is that LISP got > a reputation for being slow back when cpu time was expensive and C and > other imperative languages took over all of the mindshare. Well, scheme typically takes me a bit of effort to shift into the proper outlook; I need to noodle with it a bit before solutions arrive naturally. The "Worse is Better" paper -- or the paper in which that article is a part of -- talks about the performance difference. I suspect that a mediocre Lisp programmer writers slower code than a mediocre C programmer, even taking into account the relative differences in "base speed". I think BLQ's comments about Forth being a multiplier apply to lispish languages as well -- the very good become godlike, but the mediocre become pretty bad, the the not very good become terrible. > I love the idea of functional programming as being described as what you > want done not how you want it done. In learning about cfengine I see that > cfengine employs similar ideas in that you describe the idea system state > rather than how to get there. Structured programming makes the same promise for imperative languages, doesn't it? -Stewart "mostly Object-Oriented these days, I'm afraid" Stremler -- KPLUG-List mailing list [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
