What is the best way to process this list
in [Lisp]
|
From: Tamas K Papp on 8 Jan 2010 03:10 On Thu, 07 Jan 2010 13:48:21 -0800, Ron Garret wrote: > In article <87wrzt3akf.fsf(a)cantab.net>, > Christophe Rhodes <csr21(a)cantab.net> wrote: > >> Ron Garret <rNOSPAMon(a)flownet.com> writes: >> >> > On the other hand, Lisp has a strong cultural bias against creating >> > *new* abstractions, preferring instead to pun mainly on cons cells. >> >> This is not representative of the Lisp culture that I think of myself >> as a part of. > > I'm not saying everyone subscribes to this, but many (I would go so far > as to say an overwhelming majority) do. Lisp pedagogy certainly leans > heavily in this direction. Is there even one Lisp book out there that > doesn't introduce ALists and/or PLists early on and saves CLOS as an > "advanced topic"? And then, of course, there is SICP which takes this > to an extreme and is highly regarded in certain circles. I think that there are two communities here. One is what I would call "academic" (with apologies to people who are in academia but clearly don't belong to this group), the other "practical". The academic group mainly uses Lisp-like languages for teaching, and "clever" manipulations of lists, preferably using recursion, is held in high regard. Macros are not emphasized, if mentioned at all. The "Little Schemer" is a perfect example of this community. The practical camp uses Lisp as practical programming language, solving actual problems. They care about programming in the large, performance, and robustness, and exploit syntactic abstraction with macros to a large extent. It is an unfortunate historical accident that Lisp education is almost exclusively in the hands of the academic group. The majority of students who encounter Lisp in college think that it is a DSL for recursive list manipulation, and treat it as little more than a impractical curiosity. Given the way they are taught Lisp, they are probably right. Sometimes I think that Lisp as a practical language would benefit enormously if it was scrapped from college curriculums. Tamas
From: Ron Garret on 8 Jan 2010 03:46 In article <7qo7kfF9e3U1(a)mid.individual.net>, Tamas K Papp <tkpapp(a)gmail.com> wrote: > On Thu, 07 Jan 2010 13:48:21 -0800, Ron Garret wrote: > > > In article <87wrzt3akf.fsf(a)cantab.net>, > > Christophe Rhodes <csr21(a)cantab.net> wrote: > > > >> Ron Garret <rNOSPAMon(a)flownet.com> writes: > >> > >> > On the other hand, Lisp has a strong cultural bias against creating > >> > *new* abstractions, preferring instead to pun mainly on cons cells. > >> > >> This is not representative of the Lisp culture that I think of myself > >> as a part of. > > > > I'm not saying everyone subscribes to this, but many (I would go so far > > as to say an overwhelming majority) do. Lisp pedagogy certainly leans > > heavily in this direction. Is there even one Lisp book out there that > > doesn't introduce ALists and/or PLists early on and saves CLOS as an > > "advanced topic"? And then, of course, there is SICP which takes this > > to an extreme and is highly regarded in certain circles. > > I think that there are two communities here. One is what I would call > "academic" (with apologies to people who are in academia but clearly > don't belong to this group), the other "practical". The academic > group mainly uses Lisp-like languages for teaching, and "clever" > manipulations of lists, preferably using recursion, is held in high > regard. Macros are not emphasized, if mentioned at all. The "Little > Schemer" is a perfect example of this community. > > The practical camp uses Lisp as practical programming language, > solving actual problems. They care about programming in the large, > performance, and robustness, and exploit syntactic abstraction with > macros to a large extent. > > It is an unfortunate historical accident that Lisp education is almost > exclusively in the hands of the academic group. The majority of > students who encounter Lisp in college think that it is a DSL for > recursive list manipulation, and treat it as little more than a > impractical curiosity. Given the way they are taught Lisp, they are > probably right. Sometimes I think that Lisp as a practical language > would benefit enormously if it was scrapped from college curriculums. > > Tamas Just for the record, when I wrote "Lisp has a strong cultural bias against creating *new* abstractions" what I had in mind was new abstract data types, not macros. But since you bring it up... Even the practical camp has a somewhat schizophrenic attitude towards macros. On the one hand, macros are often touted as the cool feature that makes Lisp superior to other languages. On the other hand, reactions to specific macros are often strongly negative. "Leave macro writing to the experts" is an often-heard refrain, and even macros written by experts are more often than not very badly received (e.g. John Foderaro's IF* macro, or more recently, Pascal Costanza's filtered functions). The LOOP macro has a dedicated band of detractors who regularly urge people not to use it because it isn't "Lispy" enough (whatever that could possibly mean). The *idea* of macros seems to be much more enthusiastically embraced than actual macros. rg
From: mdj on 8 Jan 2010 03:48 On Jan 8, 6:10 pm, Tamas K Papp <tkp...(a)gmail.com> wrote: > It is an unfortunate historical accident that Lisp education is almost > exclusively in the hands of the academic group. The majority of > students who encounter Lisp in college think that it is a DSL for > recursive list manipulation, and treat it as little more than a > impractical curiosity. Given the way they are taught Lisp, they are > probably right. Sometimes I think that Lisp as a practical language > would benefit enormously if it was scrapped from college curriculums. I completely agree. The treatment that Lisp can be given in a semester or two of an undergraduate degree only serves to perpetuate the common myths about the language. I'm not sure what 'camp' I belong to in the Lisp community, but my preference is to think of it as a 'syntaxless' language; ie. when using it I'm directly writing abstract syntax trees, and macros are manipulations of those trees. I don't think I have a preference for particular data structures, and often create my own as required using defstruct and friends. I'm also not above directly representing an algorithm I picked up in pseudo code from from say, TAOCP using TAGBODY. Often, I won't bother making it "lispy" as long as it works fine and is efficient. I suspect some 'camps' would consider this 'naughty', but I prefer pragmatism to idealism myself. Matt
From: Tamas K Papp on 8 Jan 2010 04:24 On Fri, 08 Jan 2010 00:48:48 -0800, mdj wrote: > I'm also not above directly representing an algorithm I picked up in > pseudo code from from say, TAOCP using TAGBODY. Often, I won't bother > making it "lispy" as long as it works fine and is efficient. I suspect > some 'camps' would consider this 'naughty', but I prefer pragmatism to > idealism myself. Then you are a man after my own heart --- a lot of my numerical code that I have implemented based on journal articles is done using TAGBODY. I think that TAGBODY is an underappreciated gem --- for some algorithms, it _is_ the cleanest choice. Tamas
From: mdj on 8 Jan 2010 04:38
On Jan 8, 7:24 pm, Tamas K Papp <tkp...(a)gmail.com> wrote: > On Fri, 08 Jan 2010 00:48:48 -0800, mdj wrote: > > I'm also not above directly representing an algorithm I picked up in > > pseudo code from from say, TAOCP using TAGBODY. Often, I won't bother > > making it "lispy" as long as it works fine and is efficient. I suspect > > some 'camps' would consider this 'naughty', but I prefer pragmatism to > > idealism myself. > > Then you are a man after my own heart --- a lot of my numerical code > that I have implemented based on journal articles is done using > TAGBODY. I think that TAGBODY is an underappreciated gem --- for some > algorithms, it _is_ the cleanest choice. Not to mention that for heavily numerical code, modern processors do a fine job of keeping their pipelines full when executing that style of code. Sometimes paying attention to the underlying architecture is imperative to achieving acceptable performance, even today. I learned a lot of what I know about lisp using macroexpand on the standard macros until I got TAGBODY's and other special forms. Once I ran disassemble on some contrived examples enough pieces fell into place and profound respect for the designers ensued. |