* Joe Marshall | If there were no vet in the nearby area that specialized in the kind of | pet that I had, then I'd prefer one that felt comfortable with all | animals in the same family or order to one that felt that cats differed | so much from dogs as to be incomprehensible.
And then there are people who do not consider emergencies the proper focus of all their planning, philosophies, and ethics.
-- 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.
> >>Matt Curtin wrote: > >> > The difference is that there aren't a lot
> >>>of incompetent "programmers" out there claiming to be able to write > >>>Common Lisp code.
> >>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 bad. Hmmm, maybe I should look at the Lisp archives. > > What you're really talking about is an obfuscation contest. And
> > only the best Lisp programmers would be able to win such a contest > > framed as looking for the worst Lisp code...
> No, no, no, the code has to be a genuine best effort. So we would need > anti-prizes. The winner has to pay the losers.
You'd get exactly zero participants in such a contest...
> Maybe we have a new form of the Turing Test: can a good programmer > really produce code that would fool a judge into thinking they were > awful at it? They can't just produce obfuscated-code, wouldn't be > convincing.
You'd get exactly zero qualified judges for this...
> Try placing three stones on a piece of paper so they appear to be > randomly located.
> and pass values back through "global" variables. Use Hungarian notation > and variable names in Polish, but do not declare types. Avoid hyphen, use > underscore /and/ StudlyCaps. Sprinkle whitespace, including line breaks, > after open and before close parens.
It's also important to adopt the kind of naming conventions for functions and variables that would be familiar to C programmers brought up in the "externally visible identifiers must be unique in the first six characters" world. Eschew vowels, abbreviate wherever possible, abbreviate some places where not possible, name side-effecting functions for their return value, value-returning functions for their side-effect, and functions that do both and have no clear purpose at all by concatenating a random selection of words associated with the general concept of the program's application area
Words such as 'do', 'manager', 'process' and 'stuff' are always useful additions if a name is looking too readable
Daniel Barlow <d...@telent.net> writes: > Words such as 'do', 'manager', 'process' and 'stuff' are always useful > additions if a name is looking too readable
Erik Naggum <e...@naggum.no> writes: > underscore /and/ StudlyCaps. Sprinkle whitespace, including line breaks, > after open and before close parens.
and then: Top it off with a few counter-intuitive macros and reader macros, and you can make it look like a basic programmer's first encounter with Perl! -- (espen)
Erik Naggum <e...@naggum.no> writes: > * Michael Hudson > | What would _really bad_ Common Lisp look like?
> It is posted here from time to time. Just use a `setq´ of free variables > that are not declared special, and you are half there with just one major > ugliness. Then think you are writing in Scheme and you have taken another > half out of the rest of the journey to worst-possible Common Lisp. And if > you really want to do a good approximation, think you are writing in C and > do your own allocation of all objects from a pre-allocated pool and crash > when you run out of space from that pool or any other error happens. Do > not use the exception system, but use reasonable return values for errors > (like -1 where it really is a valid value). Avoid multiple return values > and pass values back through "global" variables. Use Hungarian notation > and variable names in Polish, but do not declare types. Avoid hyphen, use > underscore /and/ StudlyCaps. Sprinkle whitespace, including line breaks, > after open and before close parens.
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.
* Pretend that and/or do not exist and write complex branching logic using cond nested five levels deep.
* 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.
* Use this code to iterate over a list. (dotimes (i (length lst)) (do-something-to (elt lst i)))
* 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)))))
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.
Deon Garrett <garr...@cs.colostate.edu> writes: > 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.
Hey, have some faith: Maybe he generated the code and just didn't bother shoving it through the pretty printer because he was assuming that you have some AI program doing the grading, anyway, and would never actually look at it!
Regards, -- Nils Gösche "Don't ask for whom the <CTRL-G> tolls."
Deon Garrett wrote: > > * Michael Hudson > > | What would _really bad_ Common Lisp look like? > * 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.
> * Use this code to iterate over a list. > (dotimes (i (length lst)) > (do-something-to (elt lst i)))
Had a colleague once who specialised in thousand-line functions doing 5 separate things, including several nested loops iterating over several variables in various directions, and never used recursion. (Those few times he noticed recursion might be cleaner he had to ask me to write those pieces...)
Michael Parker <michaelpar...@earthlink.net> writes: > That's gotta be Greenblatt.
Heh heh. I couldn't find anything with his explicit signature on it, but I was looking for an example.
My first assignment as a `professional' Lisp hacker was to write a microcode verifier for the LMI Lambda. RG handed me half a dozen files written in such a perspicuous style, pointed me at the Lisp machine microcode, and said `dive in'.
The doctors say that with therapy I could once again lead a normal and productive life.
Deon Garrett wrote: > Erik Naggum <e...@naggum.no> writes:
>>* Michael Hudson >>| What would _really bad_ Common Lisp look like?
>> It is posted here from time to time. Just use a `setq´ of free variables >> that are not declared special, and you are half there with just one major >> ugliness. Then ....
> 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.
They must have been going between PC and Mac, yes? Anyway...
> * Pretend that and/or do not exist and write complex branching > logic using cond nested five levels deep.
OK, youse guys are having a lot of fun with my anti-contest, but you are losing sight of the premise that everyone involved sincerely likes Lisp and so would have had enough experience not to (+ 1 (+ 2 3)). Similarly, for example, there would be no StudlyCaps because even a bad Lisp programmer would have been hounded into conformity by a mob of hyphen-zealots.
> 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.
We feel your pain. Have them pre-flight their homework here on cll; some of us like to teach, the others need a way to keep their claws from growing too long.
:)
--
kenny tilton clinisys, inc --------------------------------------------------------------- ""Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it."" Elwood P. Dowd
>Daniel Barlow <d...@telent.net> writes: >> Words such as 'do', 'manager', 'process' and 'stuff' are always useful >> additions if a name is looking too readable > You forgot "factory".
Daniel Barlow <d...@telent.net> writes: > It's also important to adopt the kind of naming conventions for > functions and variables that would be familiar to C programmers > brought up in the "externally visible identifiers must be unique in > the first six characters" world. Eschew vowels, abbreviate wherever > possible, [...]
As opposed to conventions leading to clear names like cddddr, psetf, ldp, fboundp, or rplacd?
tuo...@yahoo.com (Tuomas P) writes: > 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?
Yes - since you have functions like read and the reader macros as well as powerful macros.
Some time ago I was complaining about parser generating tools like ANTLR lack of CLOS support (it generates code for C/C++ and Java).
Then I took a quick look at Meta. I briefly read the paper by Baker(1). I thought it looked interesting and asked the author for the source code so I could study it in more detail. He kindly replied that all the code was in the paper. It was only a couple dozen lines long! I would recommend looking at this paper (and don't assume parser generators to be huge programs like I did)
Meta is simple and elegant. I have just played with it to parse simple numbers etc, but have anybody used it to write parsers and translators for a full programming language?
* Henrik Motakef | As opposed to conventions leading to clear names like cddddr, psetf, | ldp, fboundp, or rplacd?
* Erik Naggum | All crystal clear to me, except for `ldp´.
* Martti Halminen | The original poster possibly meant ldb, which I believe was directly | borrowed from PDP-10 assembler.
Yes, `dpb´ and `ldb´ are PDP-10 instructions, all right. I wish more low-level instructions like this were available to Common Lisp programmers. E.g., byte-swapping instructions and rotates.
However, you seem to have missed the potential for a humorous bent on this. Complaining about cryptic names is one thing, but getting them wrong when you do is inherently funny, at least in my book.
-- 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.
Daniel Barlow <d...@telent.net> writes: > Words such as 'do', 'manager', 'process' and 'stuff' are always > useful additions if a name is looking too readable
You should see some of the code I work with here. If you can think of a concept, it has a "manager" associated with it. It won't be long until we birth a ManagerManager.
Petter Gustad <newsmailco...@gustad.com> wrote: +--------------- | Meta is simple and elegant. I have just played with it to parse simple | numbers etc, but have anybody used it to write parsers and translators | for a full programming language? +---------------
Way back ~1970 there was a PDP-10 program named "Meta II" that was a standalone Meta processor. I used it to write a dead stupid BLISS compiler over a single weekend! Now, granted, my compiler emitted *dumb* PDP-10 assembler code[1], but it implemented most of the core language. It didn't hurt that BLISS is roughly LL(1) [if not LL(0)!], which nicely matches Meta's recursive-descent style.
Meta is cool.
-Rob
[1] The code generator I wrote didn't bother with register management, assuming a simple stack VM, so that the code for "A = .A + .B * 3" turned into this horrid mess: (*blush*)
movei t0,A ; get A's address push p,t0 ; save for later movei t0,A ; get A's address, *again*! (oops) move t0,(t0) ; get .A (contents of A) push p,t0 ; save for later movei t0,B ; same song & dance for B move t0,(t0) push p,t0 movei t0,3 ; get 3 pop p,t1 ; get .B back mul t0,t1 ; .B*3 pop p,t1 ; get .A back add t0,t1 pop p,t1 ; get A back [note: *address* of A] storem t0,(t1) ; done
But of course, none of that was Meta's fault. ;-} ;-}
----- Rob Warnock, PP-ASEL-IA <r...@rpw3.org> 627 26th Avenue <URL:http://www.rpw3.org/> San Mateo, CA 94403 (650)572-2607
> > Words such as 'do', 'manager', 'process' and 'stuff' are always > > useful additions if a name is looking too readable
> You should see some of the code I work with here. If you can think of > a concept, it has a "manager" associated with it. It won't be long > until we birth a ManagerManager.
Or a FactoryFactory, or a FactoryFactorySingleton. Hopefully not a SingletonFactory, though...
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 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...
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 > 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...
