From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Checking for Errors Before Run Time References: <6cb6c81f.0111201212.6c599fe8@posting.google.com> <3215285396139730@naggum.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3215303341821008@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Nov 2001 03:49:04 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader3.kpnqwest.net 1006314544 193.71.66.49 (Wed, 21 Nov 2001 04:49:04 MET) NNTP-Posting-Date: Wed, 21 Nov 2001 04:49:04 MET Xref: archiver1.google.com comp.lang.lisp:20541 * Chris Perkins | I'm not necessarily advocating type specifications in Lisp. I do not follow you. Type specifications are already available to you in Common Lisp. Why use an inferior Lisp without them? Or do you mean that you want static type checking? That you cannot get very easily. Or do you mean that you do not want to add type declarations in the true sense of a declaration -- you _declare_ its type? Why not? If you have knowledge you withhold from the compiler, that can only be your loss. | The sooner I can discover a typo or an error, the better. I believe this | is true for any language. I disagree, probably to your surprise. The earlier an error is detected, the _firmer_ the determination that it is an error is, and the simpler the world must be in which statements are made. For instance, we have the option in Common Lisp of redefining a function between the definition the compiler knew about at compile-time of a caller and the actual time it was called. This would require a total re-compile in languages that consider such things an error with no option to negotiate. In the long history of programming languages, indeed human history, there are people who insist that they know what is true and good, and who seek to limit other people's opportunity to find out what other things are true and good. These generally call anything they disagree with "errors" and make people angry at their compilers or computers. Then there are people who only think they know what is wrong, and while they have their own ideas about what is true and good, they only seek to limit other people's opportunity to do wrong and harmful things. These generally do not think things are errors unless they are _clearly_ wrong and harmful. If not clearly, they may issue a warning or a style-warning. (E.g., omitting the value of the final branch of a cond or case expression when the value returned is stored in a place that is declared not to accept nil as a possible value, might be a style warning because the compiler cannot know that you do not know better.) | While it is true that I don't have to restart my machine when I miscode in | Lisp, I still "crash and burn" - I incorrectly use a form - I pass arguments | in the wrong order, etc. Then you have a _really_ bad Common Lisp environment. | Little things that haunt every programmer - even Lispers. No, not really. You see, a Common Lisp programmer who is uncertain about the arguments to a function he is about to call, asks the system for the lambda list. If he changes the lambda list in any way, he calls upon the system to let him edit all the calling points of that function. If he uses a smart editor, like Emacs, many of these operations can be fully automated, and this is again possible because (almost) all Common Lisp expressions are easy to scan both forwards and backwards in the editor, so you can move them around with simple editor commands. | And, I assert, little things that *could* be detected by my language or | tool, instead of me, my debugger, or my users. I assert that writing better code to begin with, working with a language that is actually small enough that it does not impose a cognitive load on its users. Common Lisp programmers make fewer syntactic bloopers because there is much less syntax, much better support for what syntax there is in their editors (although the other languages are getting some of the benefits of Lisp's superior syntax in Emacs). The tradeoff between how much the programmer, the editor, and the compiler does is very different between Java and Common Lisp. If you think that whichever language you learned first has every implicit or tacit assumption right, you are wrong. The language you learned first was an accident. Learning a new langauge can be done two ways: Either drop everything you have gotten used to and open your mind to the new language, or study carefully how you react to things that differ and make those assumptions explicit. Anything else will fail. (Mixing works. :) /// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.