Jeff Dalton <j...@todday.aiai.ed.ac.uk> writes: > cbbro...@knuth.brownes.org (Christopher Browne) writes:
> > >Yes there is a problem with how universities teach Lisp. [...]
> > The problem is that the typical way of teaching Lisp (or Scheme) > > seems to be as a _part_ of a course, often on comparative programming > > languages.
> True, but even courses devoted to Lisp can give students a misleading > impression of the language.
Forgive my post if I tend to ramble as I am still basking in the glow of my newfound Lisp awareness and slowly catching up on news, but luckily I have a counter example to share. I agree that in many instances what you describe is the case, but I don't see why it has to be, or rather why it tends to be as such. One of my co-workers teaches a class on Lisp. It is a one credit hour technical elective, but the amount of information and the impression students are left with is not even close to what you have described in most cases, not that what you said incorrect.
> Some trivial signs that Lisp is likely to end up looking bad: "Lisp" is > written as "LISP"; RPLACA and RPLACD get an earlier or more prominent > mention than SETF; you're told that EQ is only for comparing atoms > (or symbols); EQ is first introduced in a discussion of destructive > modification of lists; you're told that in Lisp "everything is a > list"; Lisp is called "an interpreted language"; Lisp is called "an AI > language"; you're given the impression that no one likes Lisp's syntax > but they put up with it in order to get the programming environment or > because it makes macros easy; the instructor keep apologising for > Lisp's syntax or for its use of names such as LAMBDA, COND, CAR, and > CDR; you're told that "CAR" stands for (rather than originally stood > for) "Contents of Address Register".
It seems to me that if an instructor is always apologizing for Lisp's syntax they just don't get it or they don't know how to teach it. Perhaps that is the case many times. In the Lisp class I am referring to other languages are poked fun of a bit in fact :-) The text for this class is Graham's ANSI Common Lisp. If you stretch it a bit, you can go all the way to CLOS (Chapter 11 non-inclusive) in just one quarter. That may seem like a lot to do in one quarter, but I have been going through the book on my own doing _all_ the exercises and I know that it can be done (sans doing all the exercises). Most of the students keep up, but a lot of that has to do with the quality of the instructor and the amount of clues he can lay claim to. In the least they are left with quite a different impression of Lisp than described here. Perhaps we are just lucky!
> One of the worst problems, I think, is that courses often fail to get > students to understand Lisp data as objects, "objects" meaning that > they have an identity, live in their own storage, and so on (rather > than that they're instances of classes). From that, it will make > sense - in the sense that it forms a coherent picture - that procedure > calls and assignments don't copy, that EQ and EQL can test object > identity, that it's possible to determine the type of an object at > run-time, that types are primarily associated with objects rather > than variables or other places where (refs to) objects are stored; > that hash tables can make connections between particular objects; > that lists, arrays, etc, can contain arbitrary objects rather than > being specialised to some particular element type; that it's easy > to implement simple O-O "extensions"; and so on.
I feel that there is a fundamental flaw with how CS students are taught in general. I see some courses and am left just asking myself "Why?" I don't want to get into specifics, unfortunately, but I am pretty discontent with the whole thing really. I see a desire to teach a paradigm where many limitations of certain languages are worked around and ideas like software reuse and OO techniques are employed, and I am left wondering why the implementation language used to teach these concepts is not Lisp or something more along those lines. Why?
How hard are these concepts to grasp really? Is it that difficult to teach functional programming? I just don't get it. I don't see how many people just cannot put their heads around the concepts you just listed. I think that the fact that one paradigm is drilled into their heads from day one while everything else is left as an after thought might have something to do with it. To me this is a serious flaw.
> But courses that just do list processing in Lisp never get there.
Very true, but this is not how it has to be, even for a one credit hour class.
> > Students tend to get the gist of what they're taught; when they're > > taught that the only point to Lisp is to have a section in a course > > where you do useless things with it, it _must_ be pretty useless.
> Yes, and when students are required to use Lisp and find it an > unpleasant experience, they tend to resent it, and this can turn > into an active dislike of the language.
Does anyone feel that Lisp or scheme should be taught first in a CS program? It seems to me that this would give people a real chance to learn something. My academic experience, which is highly unusual to say the, involved learning C++ first, then C. I found these languages fairly easy to grasp even if they were taught haphazardly. Then outside of the academic environment I discover things like Lisp where there are greater possibilities. Now, I am not yet an expert on Lisp, but I can feel it whenever I read a new chapter out of Graham's ANSI Common Lisp or work on the chapter questions. I can catch a glimpse of something greater, where I am not limited in many ways. It's like I have a whole new way of approaching problems that I would not have had otherwise. It seems to me that I would have had a much more productive time if I would have been introduced to Lisp first.
> > This is _exactly_ where all the "driveby flamings" tend to come from.
> I think so too, in many cases at least.
Those who perpetrate "driveby flamings" scare me. These are most likely the same people who write the following code:
while (1) { fork();
}
printf("Got here.\n");
Sorry about the C there, but I didn't make that up. I see this all the time, and since I am the system administrator I know when the labs that deal with these basic concepts are due, and in classes where these concepts should already have been learned. It may seem like people writing code like this is a fluke, but let me tell you, a lot of people who are moderately advanced in CS programs do it, and not just here. Much to my dismay I am left wondering if most of the people who get CS degrees really know anything at all. -- Shaun Rowland rowl...@cis.ohio-state.edu http://www.cis.ohio-state.edu/~rowland/
>>>>> "Christopher" == Christopher Browne <cbbro...@knuth.brownes.org> writes:
Christopher> CL may have DEFSTRUCT, but the subset that instructors Christopher> present to students is highly unlikely to include that Christopher> portion of the vocabulary, just as it is highly Christopher> unlikely to include arrays, LOOP, or, for that matter, Christopher> hash tables.
I teach Lisp (CIS459.31) at Ohio State University. It's a one credit-hour course that lasts one quarter (10 weeks). Just this year, I switched primary texts to Graham's _ANSI_Common_Lisp_.
We cover structures, arrays, and hash tables. We discuss LOOP but not in detail.
The class has five labs. Lab 4 requires students to write their own program that will demonstrate use of arrays, structures, or hash tables. I've seen folks implement things from Tic-Tac-Toe games to databases to keep track of wines in a collection.
One quarter isn't long at all, and being only one credit-hour doesn't help for the presentation of such a big language. But clearly, (most) students _can_ and _do_ get it.
Perhaps proper instruction of Lisp is lacking in many places or in general. I do think that by painting so broad a stroke, you're doing those of us who teach Lisp and care about doing it well a great disservice.
Jeff Dalton <j...@todday.aiai.ed.ac.uk> writes: > cbbro...@knuth.brownes.org (Christopher Browne) writes:
> > >Yes there is a problem with how universities teach Lisp. [...]
> > The problem is that the typical way of teaching Lisp (or Scheme) > > seems to be as a _part_ of a course, often on comparative programming > > languages.
> True, but even courses devoted to Lisp can give students a misleading > impression of the language.
Forgive my post if I tend to ramble as I am still basking in the glow of my newfound Lisp awareness and slowly catching up on news, but luckily I have a counter example to share. I agree that in many instances what you describe is the case, but I don't see why it has to be, or rather why it tends to be as such. One of my co-workers teaches a class on Lisp. It is a one credit hour technical elective, but the amount of information and the impression students are left with is not even close to what you have described in most cases, not that what you said is incorrect.
> Some trivial signs that Lisp is likely to end up looking bad: "Lisp" is > written as "LISP"; RPLACA and RPLACD get an earlier or more prominent > mention than SETF; you're told that EQ is only for comparing atoms > (or symbols); EQ is first introduced in a discussion of destructive > modification of lists; you're told that in Lisp "everything is a > list"; Lisp is called "an interpreted language"; Lisp is called "an AI > language"; you're given the impression that no one likes Lisp's syntax > but they put up with it in order to get the programming environment or > because it makes macros easy; the instructor keep apologising for > Lisp's syntax or for its use of names such as LAMBDA, COND, CAR, and > CDR; you're told that "CAR" stands for (rather than originally stood > for) "Contents of Address Register".
It seems to me that if an instructor is always apologizing for Lisp's syntax they just don't get it or they don't know how to teach it. Perhaps that is the case many times. In the Lisp class I am referring to other languages are poked fun of a bit in fact :-) The text for this class is Graham's ANSI Common Lisp. If you stretch it a bit, you can go all the way to CLOS (Chapter 11 non-inclusive) in just one quarter. That may seem like a lot to do in one quarter, but I have been going through the book on my own doing _all_ the exercises and I know that it can be done (sans doing all the exercises). Most of the students keep up, but a lot of that has to do with the quality of the instructor and the amount of clues he can lay claim to. In the least they are left with quite a different impression of Lisp than described here. Perhaps we are just lucky!
> One of the worst problems, I think, is that courses often fail to get > students to understand Lisp data as objects, "objects" meaning that > they have an identity, live in their own storage, and so on (rather > than that they're instances of classes). From that, it will make > sense - in the sense that it forms a coherent picture - that procedure > calls and assignments don't copy, that EQ and EQL can test object > identity, that it's possible to determine the type of an object at > run-time, that types are primarily associated with objects rather > than variables or other places where (refs to) objects are stored; > that hash tables can make connections between particular objects; > that lists, arrays, etc, can contain arbitrary objects rather than > being specialised to some particular element type; that it's easy > to implement simple O-O "extensions"; and so on.
I feel that there is a fundamental flaw with how CS students are taught in general. I see some courses and am left just asking myself "Why?" I don't want to get into specifics, unfortunately, but I am pretty discontent with the whole thing really. I see a desire to teach a paradigm where many limitations of certain languages are worked around and ideas like software reuse and OO techniques are employed, and I am left wondering why the implementation language used to teach these concepts is not Lisp or something more along those lines. Why?
How hard are these concepts to grasp really? Is it that difficult to teach functional programming? I just don't get it. I don't see how many people just cannot put their heads around the concepts you just listed. I think that the fact that one paradigm is drilled into their heads from day one while everything else is left as an after thought might have something to do with it. To me this is a serious flaw.
> But courses that just do list processing in Lisp never get there.
Very true, but this is not how it has to be, even for a one credit hour class.
> > Students tend to get the gist of what they're taught; when they're > > taught that the only point to Lisp is to have a section in a course > > where you do useless things with it, it _must_ be pretty useless.
> Yes, and when students are required to use Lisp and find it an > unpleasant experience, they tend to resent it, and this can turn > into an active dislike of the language.
Does anyone feel that Lisp or scheme should be taught first in a CS program? It seems to me that this would give people a real chance to learn something. My academic experience, which is highly unusual to say the least, involved learning C++ first then just working with C. I found these languages fairly easy to grasp even if they were taught haphazardly. Then outside of the academic environment I discover things like Lisp where there are greater possibilities. I am not an expert on Lisp, but I can feel it whenever I read a new chapter out of Graham's ANSI Common Lisp or work on the chapter questions. I can catch a glimpse of something greater, where I am not limited in many ways. It's like I have a whole new way of approaching problems that I would not have had otherwise. It seems to me that I would have had a much more productive time if I would have been introduced to Lisp first.
> > This is _exactly_ where all the "driveby flamings" tend to come from.
> I think so too, in many cases at least.
Those who perpetrate "driveby flamings" scare me. These are most likely the same people who write the following code:
while (1) { fork();
}
printf("Got here.\n");
Sorry about the C there, but I didn't make that up. I see this all the time, and since I am the system administrator I know when the labs that deal with these basic concepts are due, and in classes where these concepts should already have been learned. It may seem like people writing code like this is a fluke, but let me tell you a lot of people who are moderately advanced in CS programs do it, and not just here. Much to my dismay I am left wondering if many who get CS degrees really know anything at all. -- Shaun Rowland rowl...@cis.ohio-state.edu http://www.cis.ohio-state.edu/~rowland/
Centuries ago, Nostradamus foresaw a time when Matt Curtin would say:
>>>>>> "Christopher" == Christopher Browne <cbbro...@knuth.brownes.org> writes:
> Christopher> CL may have DEFSTRUCT, but the subset that instructors > Christopher> present to students is highly unlikely to include that > Christopher> portion of the vocabulary, just as it is highly > Christopher> unlikely to include arrays, LOOP, or, for that matter, > Christopher> hash tables.
>I teach Lisp (CIS459.31) at Ohio State University. It's a one >credit-hour course that lasts one quarter (10 weeks). Just this year, >I switched primary texts to Graham's _ANSI_Common_Lisp_.
>We cover structures, arrays, and hash tables. We discuss LOOP but not >in detail.
Sounds rather good.
>The class has five labs. Lab 4 requires students to write their own >program that will demonstrate use of arrays, structures, or hash >tables. I've seen folks implement things from Tic-Tac-Toe games to >databases to keep track of wines in a collection.
>One quarter isn't long at all, and being only one credit-hour doesn't >help for the presentation of such a big language. But clearly, >(most) students _can_ and _do_ get it.
>Perhaps proper instruction of Lisp is lacking in many places or in >general. I do think that by painting so broad a stroke, you're doing >those of us who teach Lisp and care about doing it well a great >disservice.
I'd tend to think that if Graham's book is used as the text, it would be fairly difficult for an instructor to simultaneously contend the relative "obsolescence" of Lisp.
I'm certainly not trying to preclude the thought that there are indeed good presentations out there; good teaching is surely a laudable thing.
>>>>> "Christopher" == Christopher Browne <cbbro...@knuth.brownes.org> writes:
Christopher> I'm certainly not trying to preclude the thought that Christopher> there are indeed good presentations out there; good Christopher> teaching is surely a laudable thing.
At the same time, I readily recognize that there are serious problems in many cases with how Lisp is taught. I don't think this is as much an issue with Lisp as it is with teaching in general. Some folks are just _boring_. Others don't really know their topic very well.
The big problem that Lisp does face in education is that there is the possibility that what little folks do know about Lisp isn't highly relevant to anything, or they'll have some general prejudice about something that's so "old". (Strange how in any other context, that sort of thing isn't called "old" or "obsolete", it's called "history" and "culture", both generally considered Good Things.)
Combine that with the relatively little amount of noise that is made about Lisp and the need for Lisp programmers in the industry and there just isn't much in the way of incentive for folks to learn the language well where there isn't someone there to give students a good introduction. Anyone can look at the amount of hype that surrounds Java and see that even where there isn't lots in the way of formal education about a language, people can see that it's big enough to be motivated to do what's necessary to learn it.
People sometimes ask me why there aren't billions of ads for Lisp programmers, why they don't hear a lot about the need for there to be more Lisp programmers, etc. I like to answer thusly: o How much of all software development is maintenance work? (Answers vary, but it's always a LOT, typically in the 80-95% range.) o If programs are written correctly the first time, there aren't going to be lots of bugs that need to be fixed. o If programs are designed well from the beginning, they should be able to do quite a lot without needing to have lots of code changes made. o A language that helps programmers write good programs will therefore require much less maintenance work. o If the vast majority of programming is maintenance work, the need for maintenance programmers will largely be dictated by how badly the programs are being written. That can be heavily influenced by the language choice.
So the answer, of course, is that there is a need for Lisp programmers to build new systems. But there isn't much need for Lisp programmers to fix all the junk that everyone else has already written four times. As a result, there will be less "visibility" of the language.
Am I exaggerating? Probably. Is there an element of truth in what I'm saying when I answer this way? I think so. But in what other way could a genuine Lisp programmer answer? I think "getting it right early on" is an important element of Lisp itself and its culture. I like to convey that to students.
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
>* Rainer Joswig <rainer.jos...@ision.net> >| Please waste other people's time.
> If I can waste your time so you don't continue to slander people and > companies and create unnecessary animosity between developer groups, > that's a _very_ good thing in my view. So, I'm glad your time is > wastable with such simple means.
Could you "squalling brats" _PLEASE_ take your "waste of time" to email, where it won't trouble the rest of us?
Sometimes, my .sigmonster picks something incredibly more appropriate than anything I would have _tried_ to choose myself; this is one of those occasions... -- This program posts news to billions of machines throughout the galaxy. Your message will cost the net enough to bankrupt your entire planet. As a result your species will be sold into slavery. Be sure you know what you are doing. Are you absolutely sure you want to do this? [yn] y cbbro...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
Centuries ago, Nostradamus foresaw a time when Robert Monfera would say:
>"Andrew K. Wolven" wrote: >> Mallery isn't doing anything for the benefit of the Lisp Community itself, >> and >> is only alienating supporters if he thinks I am going to make any customer >> cough up more than two hundred bucks for CL-HTTP when Apache is free.
>If $200 is big money for a web server for your customers, then I don't >envy you, but supposedly your talent can add a lot of value to it (embed >the web server in an application, for example), and help you make decent >money. Or is it that you can't get the clients to pay for anything?
Sometimes it's appallingly remarkable what clients are unwilling to pay for...
The _problem_ is that with the availability of Apache, for free, and Boa, for free, and Roxen Challenger, for free, and AOLserver, for free, Zope, for free, IIS :-), for free, and probably a bunch of other options, _for free_, a lot of people look pretty funny at the notion of charging anything much for a web server.
Sure, Apple's WebObjects is pretty expensive; of course, it appears to have dropped from $50K to $700, which is suggestive that declining web server prices are the norm rather than than the abnorm.
I agree that $200 isn't all that much, but it's sure not unusual for web servers to be priced vastly lower than that.
>As for the CL-HTTP license, I think that a meaningful commercial license >(maybe along with an alternative, unsupported OS license) would be >preferable, but I don't think it would make a difference for you, as you >are clearly out of your medication.
The problem with the CL-HTTP license doesn't seem to me to be the price, but rather the fact that the licensing is fairly vague.
If I wanted to build a derivative of CL-HTTP, and redistribute it, it may be reasonably likely that it will be fine with the authors for me to do so, perhaps at some fee, but it seems evident that there's not a "pricing sheet" on how to do it. I'd essentially have to pre-arrange terms individually with the authors.
The uncertainty that is entailed is discouraging.
I can't speak for Wolven's meds :-). -- Rules of the Evil Overlord #140. "I will instruct my guards when checking a cell that appears empty to look for the chamber pot. If the chamber pot is still there, then the prisoner has escaped and they may enter and search for clues. If the chamber pot is not there, then either the prisoner is perched above the lintel waiting to strike them with it or else he decided to take it as a souvenir (in which case he is obviously deeply disturbed and poses no threat). Either way, there's no point in entering." <http://www.eviloverlord.com/> cbbro...@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>
* Christopher Browne | Could you "squalling brats" _PLEASE_ take your "waste of time" to | email, where it won't trouble the rest of us?
You're responding to a message posted 2000-05-18 on 2000-06-02 with a complaint like that? _Why_? I think you're the squalling brat flinging dung at others when you take that long after THINGS HAVE ALREADY QUIETED DOWN to complain. Just quit your pointless and counterproductive complaining, will you? Sheesh!
#:Erik -- If this is not what you expected, please alter your expectations.
> | Could you "squalling brats" _PLEASE_ take your "waste of time" to > | email, where it won't trouble the rest of us? > You're responding to a message posted 2000-05-18 on 2000-06-02 with > a complaint like that? _Why_? I think you're the squalling brat > flinging dung at others when you take that long after THINGS HAVE > ALREADY QUIETED DOWN to complain. Just quit your pointless and > counterproductive complaining, will you? Sheesh!
I think the article got injected twice -- there's another copy in my spool dated 19-may: I guess his newsreader fouled up?
Centuries ago, Nostradamus foresaw a time when Tim Bradshaw would say:
>* Erik Naggum wrote: >* Christopher Browne >> | Could you "squalling brats" _PLEASE_ take your "waste of time" to >> | email, where it won't trouble the rest of us?
>> You're responding to a message posted 2000-05-18 on 2000-06-02 with >> a complaint like that? _Why_? I think you're the squalling brat >> flinging dung at others when you take that long after THINGS HAVE >> ALREADY QUIETED DOWN to complain. Just quit your pointless and >> counterproductive complaining, will you? Sheesh!
>I think the article got injected twice -- there's another copy in my >spool dated 19-may: I guess his newsreader fouled up?
Reinjection of some spool; oops... Sorry about that... -- aa...@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/> Why does the word "lisp" have an "s" in it?
So after reading random stuff from this thread, here's my $0.02 about what should be taught first:
> Does anyone feel that Lisp or scheme should be taught first in a CS > program? It seems to me that this would give people a real chance > to learn something. My academic experience, which is highly unusual > to say the, involved learning C++ first, then C.
here's what I believe to be true about human beings. Let's first make the generalization that the "city" is better than the "country" in the same way that "Common Lisp" is better than "C" (note: not Lisp, but particularly CL; I am not talking about Scheme here). This is just an assumption, and I'm trying to make a point.
It seems, from my experience, that if you take a country boy, born and raised in the country, and then move him to the city, and he assimilates, and gets used to it, then it's very hard for him to go back; much harder, in fact, than for a city boy, born and raised in the city, to go to the country, get used to it out there (farming or whatever) and then return to the city.
Applying this [mere generalization] to the programming question of which language to teach first, it would make sense to teach C first and CL second. Because then programmers "know" C, but once they've "seen the better way" it's hard to go back. Given the choice, they'd rather "live in the city" now.
This is basically already what is happening. _very_ few students/programmers see CL before either C, C++, Pascal, Basic, or Java. And this is kinda the way I like it. It means that nearly ALL CL programmers know another language, and that makes CL prorammers wiser, more knowledgable, and more versatile. I'd rather that the CL community remain small, but that its members be, on average, "wiser" than other programmers. Does this sound elitist? Maybe. Probably. But I think it's the right way. I don't want to see high school kids and your typical Perl scripting hackers having a serious impact on CL.
The other side of the coin here is that with the influence of features in other languages, people will move over to CL and then miss things not present in CL, but in other languages, and so the trend will be to wash CL into the other languages. But it's good for CL to have users who know about features in other languages.
My only gripe is that Common Lisp is not marketed properly to many people who would really benefit from it. I'll just recount a story. I met a guy a year or so ago who graduated CMU with an advanced degree in computer science, and then came to MIT to do his PhD. He was doing all sorts of complex analyses, proofs, etc. We were talking, and he said he used C. I said something like "coming from CMU, I'd have figured that you, especially, would use CL for your work..." He then said something like "Are you crazy? that language sucks! it's not even compiled!". And this is someone who got his B.S. and M.S. at CMU. So go figure. people just arn't getting the right information. they're also not getting the opportunities to use CL with the right level of instruction.
David Bakhash <ca...@alum.mit.edu> writes: > But I think it's the right way. I don't want to see high school kids > and your typical Perl scripting hackers having a serious impact on CL.
Um, since I just now finished 11th grade, does that mean I should go away now?
The REST of it was quite well written... =)
-- vsync http://quadium.net/ - last updated Thu Jun 1 23:57:30 MDT 2000 Orjner.
vsync <vs...@quadium.net> writes: > David Bakhash <ca...@alum.mit.edu> writes:
> > But I think it's the right way. I don't want to see high school kids > > and your typical Perl scripting hackers having a serious impact on CL.
> Um, since I just now finished 11th grade, does that mean I should go > away now?
This is why I hate generalizations. You must consider what I'm saying in context.
Trying to standardize and perfect a programming language comes from a maturity in programming that tends to come over time. I'm 26, and still find myself learning tons, both about CL and about programming in general. that's all I was trying to say.
> > > But I think it's the right way. I don't want to see high school kids > > > and your typical Perl scripting hackers having a serious impact on CL.
> > Um, since I just now finished 11th grade, does that mean I should go > > away now?
> This is why I hate generalizations. You must consider what I'm saying > in context.
Sorry, humor's kind of hard to convey on Usenet... I think I had a smiley in there somewhere. Anyway, I did get your point and I agree with you.
Unfortunately, the way society is, a more "elite" language will just be regarded as somehow bad. This happens at work all the time. If I need to implement something, some of the managers (not all, thank goodness) request details about how I'm doing it. Most of the time, these managers don't understand the information they're given, and it ends up being that if they've heard of the tool I'm using, they like it. If they haven't, they don't, and no additional information will change their minds.
If programmers themselves often don't understand what Lisp is, as in your example of the CMU student, then this will translate to even less acceptance among those who make the decisions. This isn't to say that you aren't right, but I don't think there really is a good solution. Personally, I wish they'd trust those of us who do the actual work to be able pick the right tool for the job, but... =)
> Trying to standardize and perfect a programming language comes from a > maturity in programming that tends to come over time. I'm 26, and still > find myself learning tons, both about CL and about programming in > general. that's all I was trying to say.
Very well stated. I think if a person isn't willing to learn, they shouldn't be allowed anywhere near a computer (but that's another topic =), much less programming, because there's so much exploration involved. I think one of my favorite things about Lisp is the way it encourages such exploration. Instead of having to lay out every detail of a program beforehand, with a huge cost if I change my mind later, I can just let it grow organically as I add features. Lisp really puts fun and adventure into programming, which is as it should be.
-- vsync http://quadium.net/ - last updated Thu Jun 1 23:57:30 MDT 2000 Orjner.
David Bakhash <ca...@alum.mit.edu> writes: > Applying this [mere generalization] to the programming question of > which language to teach first, it would make sense to teach C first > and CL second. Because then programmers "know" C, but once they've > "seen the better way" it's hard to go back. Given the choice, they'd > rather "live in the city" now.
I can follow your logic, and it seems sound to me. I believe that I wrote more of my own experiences in there than I wanted to. The reason that I was thinking of teaching Lisp first is because it would give students the exposure to a new language they might not otherwise get. The problem in the one credit hour technical elective example is the class is optional. There are a few different technical electives that a student can take in fact, and the Lisp class is only offered one quarter of the year. That's very unfortunate in my eyes. I could go on for hours about how I think what is actually learned by most students hurts them in ways, but I won't. I just wish that the Lisp class was required. I think that everyone would benefit from the experience. What is even worse in this situation is that one must know what Lisp is already. How else would one know to take the class in the first place? There is not much motivation given the C/C++ "focus" in other classes unless clues about what Lisp is and why it might be important to learn are already present. If Lisp were taught first it would still be necessary to learn C or C++. This would accomplish my goal, but the reasons for my general question are too specific.
> This is basically already what is happening. _very_ few > students/programmers see CL before either C, C++, Pascal, Basic, or > Java. And this is kinda the way I like it. It means that nearly ALL > CL programmers know another language, and that makes CL prorammers > wiser, more knowledgable, and more versatile. I'd rather that the CL > community remain small, but that its members be, on average, "wiser" > than other programmers. Does this sound elitist? Maybe. Probably. > But I think it's the right way. I don't want to see high school kids > and your typical Perl scripting hackers having a serious impact on CL.
I can see the benefits you state here, but I don't agree with the last sentence in this context. The students in a CS program are not supposed to be just typical Perl scripting hackers. If you want that go to a technical college or learn it on your own.
> My only gripe is that Common Lisp is not marketed properly to many > people who would really benefit from it. I'll just recount a story. > I met a guy a year or so ago who graduated CMU with an advanced degree > in computer science, and then came to MIT to do his PhD. He was doing > all sorts of complex analyses, proofs, etc. We were talking, and he > said he used C. I said something like "coming from CMU, I'd have > figured that you, especially, would use CL for your work..." He then > said something like "Are you crazy? that language sucks! it's not > even compiled!". And this is someone who got his B.S. and M.S. at > CMU. So go figure. people just arn't getting the right information. > they're also not getting the opportunities to use CL with the right > level of instruction.
Right, but I don't take too much stock in what people with B.S. and M.S. degrees tell me. I have too much experience dealing with them :-) Unfortunately people with B.S. and M.S. degrees often do a good job representing their own population, just not a good job representing the real truth that can be found in Lisp. Now that probably sounds elitist!
None of what I am saying here means that Lisp is the one true way for everyone. I would rather see students receive good exposure to Lisp along with other languages. If that were happening I don't believe we would see answers like "that language sucks! It's not even compiled!" Any objections would be more along the lines of what I expect from someone with an advanced degree in computer science and not someone who has no real idea of the benefits of one language over another for certain applications. Often times I believe I expect too much. -- Shaun Rowland rowl...@cis.ohio-state.edu http://www.cis.ohio-state.edu/~rowland/
> CL programmers know another language, and that makes CL prorammers > wiser, more knowledgable, and more versatile. I'd rather that the CL > community remain small, but that its members be, on average, "wiser" > than other programmers. Does this sound elitist? Maybe. Probably. > But I think it's the right way. I don't want to see high school kids > and your typical Perl scripting hackers having a serious impact on
CL.
Umm, I'm confused. How does using have an impact, particularly a negative one? (Perl went non-linear because Larry Wall is non-linear.)
Precisely what is the virtue in being a back-water language?
A lisp could, and arguably should, have had the position that Python is getting. Yet, due to the lisp communities insistence on fragmentation and not acknowledging the importance of interaction with the outside world, Python is going to be important, and lisp is, well, lisp.... (Python is interpreted as bytecodes.)
This story has been repeated a number of times. Why is this a good thing?
In article <8hf89s$89...@nnrp1.deja.com>, Andy Freeman <ana...@earthlink.net> wrote:
> This story has been repeated a number of times. Why is this > a good thing?
I mentioned Python because that's the best choice for what I'm doing now.
After I hit "send", I remembered a dinner that I had with a very senior executive at an e-commerce company. I asked a meaningless question and was rather floored by the response "you know, XML could have been lisp, but ...." That wasn't an answer to my question, and I doubt that he knew that I knew lisp, let alone preferred it, but it's still interesting.
When I have to start processing XML with Python, I'm not going to think fondly of the people who find virtue in keeping lisp in the back-water. It's not pure, it's stagnant.
David Bakhash <ca...@alum.mit.edu> writes: > So after reading random stuff from this thread, here's my $0.02 about > what should be taught first:
> > Does anyone feel that Lisp or scheme should be taught first in a CS > > program? It seems to me that this would give people a real chance > > to learn something. My academic experience, which is highly unusual > > to say the, involved learning C++ first, then C.
> here's what I believe to be true about human beings. Let's first make > the generalization that the "city" is better than the "country" in the > same way that "Common Lisp" is better than "C" (note: not Lisp, but > particularly CL; I am not talking about Scheme here). This is just an > assumption, and I'm trying to make a point.
> It seems, from my experience, that if you take a country boy, born and > raised in the country, and then move him to the city, and he > assimilates, and gets used to it, then it's very hard for him to go > back; much harder, in fact, than for a city boy, born and raised in > the city, to go to the country, get used to it out there (farming or > whatever) and then return to the city.
> Applying this [mere generalization] to the programming question of > which language to teach first, it would make sense to teach C first > and CL second. Because then programmers "know" C, but once they've > "seen the better way" it's hard to go back. Given the choice, they'd > rather "live in the city" now.
> This is basically already what is happening. _very_ few > students/programmers see CL before either C, C++, Pascal, Basic, or > Java.
the problem, as i see it, is that very few students/programmers see CL at all. as an electrical engineer, i can tell you i was never exposed to it in any class.
if they do, the don't see it before learning *all of* C, C++, pascal, basic *and* java. then they see lisp. they think -- lisp looks weird. it's got all these parenthesis and the professor gives three minor projects having to do with flattening lists. student gets the idea that 1) flattening lists is a pointless exercise. 2) it was harder than it ought to be. 3) dealing with lists was supposed to be lisp's strength. 4) lisp sucks. this is *not* the impression i want to have lisp give.
if you have people fluent in lisp before seeing C++, maybe they will react in appropriate horror to that. as it is, they put up with C++ because it's more like things they know. once someone has invested the effort to be good at C++ it will be *very* hard to expand their minds. no one wants to admit they are wrong.
> And this is kinda the way I like it. It means that nearly ALL > CL programmers know another language, and that makes CL prorammers > wiser, more knowledgable, and more versatile.
it also means there are too damn few lisp programmers. this means that 1) lisp compilers and tools are expensive 2) no more lisp machines 3) significant bit rot on useful things like window systems, number crunching &c.
i mean, lisp would be *the* natural language for window based programming. look how well emacs does with reacting to keystrokes. C++ limps along with class inheritance, but it doesn't have lambda. CL has functional *and* OOP style. it's a natural for windows (not microsoft but in general). but does everyone have nice lisp based windowing systems? noooooo we are struggling with monstrosities constructed in C++. why? because lisp isn't near popular enough.
> I'd rather that the CL > community remain small, but that its members be, on average, "wiser" > than other programmers. Does this sound elitist? Maybe. Probably. > But I think it's the right way. I don't want to see high school kids > and your typical Perl scripting hackers having a serious impact on > CL.
what i am afraid of is worse is better and we will, in the end, all be reduced to windows visual basic.
lots of idiots knowing lisp doesn't bother me in the least. it will mean lots of smart people knowing lisp too. a language isn't good or bad just on popularity alone, but being popular helps. sometimes, more really *is* more.
> The other side of the coin here is that with the influence of features > in other languages, people will move over to CL and then miss things > not present in CL, but in other languages, and so the trend will be to > wash CL into the other languages. But it's good for CL to have users > who know about features in other languages.
i'd be happy if CL just had users period. (yes, i know CL does have users, but i want more of them!)
> My only gripe is that Common Lisp is not marketed properly to many > people who would really benefit from it. I'll just recount a story. > I met a guy a year or so ago who graduated CMU with an advanced degree > in computer science, and then came to MIT to do his PhD. He was doing > all sorts of complex analyses, proofs, etc. We were talking, and he > said he used C. I said something like "coming from CMU, I'd have > figured that you, especially, would use CL for your work..." He then > said something like "Are you crazy? that language sucks! it's not > even compiled!". And this is someone who got his B.S. and M.S. at > CMU. So go figure. people just arn't getting the right information. > they're also not getting the opportunities to use CL with the right > level of instruction.
Johan Kullstam writes: > i mean, lisp would be *the* natural language for window based > programming. look how well emacs does with reacting to keystrokes. > C++ limps along with class inheritance, but it doesn't have lambda. > CL has functional *and* OOP style. it's a natural for windows (not > microsoft but in general). but does everyone have nice lisp based > windowing systems? noooooo we are struggling with monstrosities > constructed in C++. why? because lisp isn't near popular enough.
I have to agree with this, but I don't know what to do about it. (Write software, I suppose.) I'm a CL dabbler; I like it, it's fun, and it's a good source of ideas. Over the weekend, though, I found myself re-implementing a miniature version of CLOS generic functions in Python, because that style of modularity fit what I was doing better. I was just doing simple GUI development, telling objects how to use the GUI to display themselves, edit themselves, and so on.
It's a beautiful fit; the GUI stuff stays in the GUI methods, while everything else stays in the more basic methods. Wow. A light goes on.
I don't quite know where to go from here, but I'm back to watching CL very carefully. I like the feeling.
Joe Marshall <jmarsh...@alum.mit.edu> writes: > cbbro...@knuth.brownes.org (Christopher Browne) writes:
> > --> C has structs; the only way to simulate that in Lisp is via > > those horribly inefficient association lists.
> Alists? What are those? My first lisp course covered propertly lists > on symbols.....
we'll, I'd have retored by saying that CL has well-capable and efficient structs in most implementations. But symbol plists arn't considered to be extremely efficient, and I'd guess that alists and plists are on the same order of inefficiency wrt access times in most implementations. One reason I don't like using plists is that I feel that the data is somehow hidden. Of course, it's not, but it always feels like it's one level underneath the surface. I feel that while compile-time systems should make full use of plists, your runtime systems should not use them heavily. But I'd like to know more about how people use them, since I very seldom use them.
David> I feel that while compile-time systems should make full use of plists, David> your runtime systems should not use them heavily. But I'd like to David> know more about how people use them, since I very seldom use them.
Well, I know lisp mostly from emacs-hacking, but rarely come across it. Based on the emacs lisp corpus I find the following stats:
emacs/20.5/lisp/*.el has 236 uses of GET in 191995 lines of code (0.1 %) emacs/20.5/lisp/emacs-lisp/*.el has 116 uses of GET in 35448 lines (0.3 %)
supporting the feeling that plists aren't a main stream thing. However, they do seem to be a very useful construct for clever things like compilers, debuggers, profilers and code-instrumenters such as advice.el. I expect there to be correlation between the occurrences of EVAL and of p-lists :-)
Philip -- Is your dog vegetarian too? --------------------------------------------------------------------------- -- Philip Lijnzaad, lijnz...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-24 +44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
David Bakhash <ca...@alum.mit.edu> writes: > But I'd like to know more about how people use them, since I > very seldom use them.
Nor should you. Plists are a `poor man's 2-d table'. The problem is that this table is not first class, the key pairs come from a global namespace, and the table shared with every function that uses a 2-d table.
The latter two problems are ameliorated somewhat by packages, but in most cases where a plist is being used, a hash table, alist, btree, etc. would be a better choice.
* David Bakhash | But I'd like to know more about how people use them, since I | very seldom use them.
* Joe Marshall <jmarsh...@alum.mit.edu> | Nor should you.
What nonsense!
| Plists are a `poor man's 2-d table'.
Well, that's _one_ view.
| The problem is that this table is not first class, the key pairs | come from a global namespace, and the table shared with every | function that uses a 2-d table.
Firstclassitude is _so_ overrated. Don't listen to Schemers!
Property lists exist in many objects, not just symbols. They are very convenient ways to store _incidental_ information with the object when the object itself is vastly more important than the _property_ you want to associate with it. Take symbols. If the symbol has it's very own, very good raison d'être, you'd be a fool to set up an eq hash table to store some particular properties on them, and particular to set up a whole bunch of them, probably named by their own symbols, to hold on to each one. You already have the symbol in hand, so it's a wanton waste of resources to use an expensive external mechanism to avoid being criticized by Schemers.
However, if you don't use symbols for the many good reasons for which you _should_ use symbols, but for some of the more numerous good reasons to _avoid_ using symbols, it's just stupid to waste resources on symbols only for their property lists. Remember, symbols are _expensive_ little things. If you gotta have them, you might as well exploit that fact, but if don't have to for some other reason, property lists is not a reason to use them.
Scheme exposure damages your brain if you want to program in Common Lisp in your real life. Scheme doesn't have symbols, so they're _envious_ of our very useful property lists! (Or whatever, they simply don't _get_¹ the symbol as a first-class object, no matter how much they otherwise rant and rave about firstclassitude².)
#:Erik ------- ¹ pun intended ² this really should be a word -- If this is not what you expected, please alter your expectations.
Erik Naggum <e...@naggum.no> writes: > Property lists exist in many objects, not just symbols. They are > very convenient ways to store _incidental_ information with the > object when the object itself is vastly more important than the > _property_ you want to associate with it.
I was objecting to the `globalness' of property lists. `Naked' property lists don't have this problem.
> Take symbols. If the symbol has it's very own, very good raison > d'être, you'd be a fool to set up an eq hash table to store some > particular properties on them, and particular to set up a whole > bunch of them, probably named by their own symbols, to hold on to > each one. You already have the symbol in hand, so it's a wanton > waste of resources to use an expensive external mechanism to avoid > being criticized by Schemers.
Erik raises a good point, but there are drawbacks to using plists even in this situation. Since symbol plists are a global structure, they share the same drawbacks as any other global structure, like a global variable.
There is no way to manipulate properties as a collection, however. It is difficult, for example, to enumerate all symbols with a particular property, or to maintain two sets of properties with the same name.
A particular example is in a compiler. Many compilers put properties on symbols indicating how to process forms with these symbols. However, when you want to retarget the compiler, you have problems. You must replace the properties that the compiler is looking for with a new set, but doing that makes the compiler useless for the current machine. There is no easy way to say `ok, do the compile, but use a non-standard set of properties'. If there were instead an explicit table rather than an *implicit* one scattered about the environment, it would be trivial to hand the compiler a different set of special symbols.
Perhaps I should say: `it's a wanton violation of abstraction to use a global mechanism to avoid being criticized by Erik.'
> Scheme exposure damages your brain if you want to program in Common > Lisp in your real life. Scheme doesn't have symbols, so they're > _envious_ of our very useful property lists! (Or whatever, they > simply don't _get_¹ the symbol as a first-class object, no matter > how much they otherwise rant and rave about firstclassitude².)
MIT Scheme has both symbols and propertly lists, but they are not advertised.
* Joe Marshall <jmarsh...@alum.mit.edu> | Erik raises a good point, but there are drawbacks to using plists | even in this situation. Since symbol plists are a global structure, | they share the same drawbacks as any other global structure, like a | global variable.
I'm sure it's possible to view them this way, but _why_? This looks like unfounded fear to me, and I'm not at all sure how to respond when the technical issues at hand seem completely irrelevant. Are global variables unilaterally and universally _bad_, now? Furrfu!
| There is no way to manipulate properties as a collection, however. | It is difficult, for example, to enumerate all symbols with a | particular property, or to maintain two sets of properties with the | same name.
The latter is obviously solved by the package system. The former is the same problem as finding all the keys that have values in a hash table which match certain criteria. If you have such a need, you cater to it by using something else. If you don't have such a need, you don't need to do something else. Contrary to what nearly every Scheme proponent will react as if he meant, we do not deal with the fully general abstract notion of a program, but an actual program that has a number of real-world constraints. If using property lists would lead to problems, smart people use something else, but Scheme proponents conclude that it is problem-laden and will never use it even when there are no problems.
| A particular example is in a compiler. Many compilers put | properties on symbols indicating how to process forms with these | symbols. However, when you want to retarget the compiler, you have | problems. You must replace the properties that the compiler is | looking for with a new set, but doing that makes the compiler | useless for the current machine. There is no easy way to say `ok, | do the compile, but use a non-standard set of properties'. If there | were instead an explicit table rather than an *implicit* one | scattered about the environment, it would be trivial to hand the | compiler a different set of special symbols.
Or you could be sufficiently smart and use one level of indirection in the properties: The code does not reference properties by a constant value (symbol), but by the value of a global symbol.
I'm sorry, but I"m not into this "let's find one more ridiculous problem with something I don't like" game. If you enjoy such games and impractical purity, Scheme is for you. If you are smart enough to deal with the real world in its sometimes messy complexity, stay with Common Lisp and observe that unlike static typing and Scheme proponents, other programmers trust that you have a working brain and know when using a practical, useful mechanism is a good idea and when it is not. Smart people never listen to those who claim that something is always bad or always good, anyway.
#:Erik -- If this is not what you expected, please alter your expectations.
