Larry Hunter wrote: > The best idea I have seen for escaping this hell could only be done in > lisp. Chris Riesbeck has written a lisp homework parser that checks > for hundreds of stylistic and semantic errors that he never wants to > see. Some of it only works for particular problems (generally taken > from Graham's CL book exercises), but others are generic. Students > have to get the programs to pass his autochecker before submitting it > for his review. Source code is available...
I'm not sure that "could only be done in lisp" is right, though. (It's certainly easier in Lisp than in any other language I can think of.) There are similar tools for other languages, not written in Lisp. Even <shudder> C++.
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
Larry Hunter <Larry.Hun...@uchsc.edu> writes: > I could probably add more. All these examples are from code I've > seen since Monday. Yes, I am slowly going insane. Someone please > help me...or just kill me.
> The best idea I have seen for escaping this hell could only be done in > lisp. Chris Riesbeck has written a lisp homework parser that checks > for hundreds of stylistic and semantic errors that he never wants to
Actually, I vaguely remember the claim of one of my former lecturers to have written something similar in fortran (analyzing fortran programs) for his phd thesis, back in the days of punch cards. So maybe you really ought to say that it can only be done in well matured programming languages (like lisp *or* fortran). :)
> I'm the TA for an intro to AI course, so I think I can add a few items to > Erik's list...if I can drop the assumption that the person knows what he's > doing.
> * Don't put line breaks in....ever. I graded one assignment containing > a 393 character line. I'm not kidding. [...] > * declare 10 local variables with default values in a let form, then > spend the next 10 lines assigning values to them with 10 different > setf's. [...] > * Don't just mix underscore and StudlyCaps in a program. Truly awful > code requires going above and beyond. It requires mixing StudlyCaps, > nocaps, and various forms of WEIRDCaps into different references to > the same symbol. As in > (setf MyList (cons something MYLIST))
> * And my current favorite: add 5 numbers with this beauty. > (+ 1 (+ 2 (+ 3 (+ 4 (+ 5)))))
What's amazing is not much that students make mistakes like the ones mentioned in this thread. I am more suprised by the fact that they do such mistakes after being exposed to a usually large number of--hopefully--good and idiomatic code samples.
How much attention do they pay to _reading_ those examples? Shouldn't the "cut and paste" mindset be of some help here? Bad habits spread like wildfire, but there's a sort of psychological barrier to copying good ones.
On Wed, 13 Nov 2002 18:08:49 GMT, Kenny Tilton <ktil...@nyc.rr.com> wrote: > Exactly. In fact, sick idea: I'd love to track down the worst programmer > who likes Lisp. Maybe hold an anti-contest. I bet they would not be very
This is an interesting reading:
"FoOBaR - A Prehistoric Survivor" António Menezes Leitão Proceedings of ELUGM '99
Abstract: We describe an old and large AI system that crossed several Lisp periods and dialects. The system is currently implemented in Common Lisp but still represents an unique source of information regarding implementation problems and solutions in older Lisp dialects and implementations. Most of these solutions are techniques to sourmount language limitations, to use language features in unforseen ways, or just incorrect coding practices. This paper describes some of these problema snd solutions, and their impact on readability, efficiency, and maintenance.
> What's amazing is not much that students make mistakes like the ones > mentioned in this thread. I am more suprised by the fact that they do such > mistakes after being exposed to a usually large number of--hopefully--good > and idiomatic code samples.
Aye, therein lies the rub. Ordinarily, students start off with the standard Lisp beginner fare; reverse a list recursively and all that stuff. In this course, the professor decided to try a little experiment. He explained Lisp in some detail in the lectures, but then left the students to study on their own. They were supposed to read the Graham book (Ansi Common Lisp) and see me with questions. All the assignments have been fairly substantial pieces of code, at least considering their lack of experience. Of course, most didn't read anything and have just been trying to muddle their way through the semester. I actually thought this was a good idea. I've always found the best way to learn a language was to write something real in it. In hindsight, I think students probably need a little more guidance in the process of learning Lisp.
Yes, they _should_ have been exposed to plenty of good examples, but the reality is that many of them probably think mapcar is some sort of joint venture between Honda and Rand McNally.
I'm being a little too critical here. About 25% of the class is actually writing very good code. A couple of students have actually learned the Lisp efficiency model. I guess that's probably the norm in undergraduate education these days. You probably can't expect much more than that to do truly good work.
* Paolo Amoroso | What's amazing is not much that students make mistakes like the ones | mentioned in this thread. I am more suprised by the fact that they do such | mistakes after being exposed to a usually large number of--hopefully--good | and idiomatic code samples. | | How much attention do they pay to _reading_ those examples? Shouldn't | the "cut and paste" mindset be of some help here? Bad habits spread like | wildfire, but there's a sort of psychological barrier to copying good | ones.
The problem is that some people can learn something only once. They are only malleable while they are truly unexposed. Show them something, and the impression it makes causes anything that could occupy the same space later to be rejected. If they later learn that their first impression was wrong, the result is only that they reject everything, which makes them insecure and suspicious. To make matters worse, I believe this to be the default programming mode of the brain and that it requires directed effort -- also known as /thinking/ -- to override the default behavior.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote: > The problem is that some people can learn something only once. They are > only malleable while they are truly unexposed. Show them something, and > the impression it makes causes anything that could occupy the same space > later to be rejected. If they later learn that their first impression was > wrong, the result is only that they reject everything, which makes them > insecure and suspicious. To make matters worse, I believe this to be the > default programming mode of the brain and that it requires directed effort > -- also known as /thinking/ -- to override the default behavior.
-- Given any rule, however ‘fundamental’ or ‘necessary’ for science, there are always circumstances when it is advisable not only to ignore the rule, but to adopt its opposite. - Paul Feyerabend
* Pascal Costanza | I think you are talking about cognitive dissonance.
Well, cognitive dissonance is the effect of the cause I was talking about. When cognitive dissonance occurs, the default coping strategy is to reject rather than to think and analyze and embrace new input, but the key to the ability to learn is the ability to update a slot that had been filled by the first impression, or to internalize and integrate new and conflicting information. Failure to do this will only produce repeated incidents of cognitive dissonance.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
> Is Lisp being used in programs that do text processing of various > kind, such as parsing and manipulating an HTML file, parsing C code > (and reindenting it), etc.? Would Lisp be a good to choice if one is > to write such software?
It's not Common Lisp, but it's still great. It includes functionality for lexing - (regular-grammar), and lalr parser generation (lalr-grammar). Check it out, I'm really impressed.
