From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader1.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> Mail-Copies-To: never From: Erik Naggum Message-ID: <3215285396139730@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 74 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Nov 2001 22:49:59 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader1.kpnqwest.net 1006296599 193.71.66.49 (Tue, 20 Nov 2001 23:49:59 MET) NNTP-Posting-Date: Tue, 20 Nov 2001 23:49:59 MET Xref: archiver1.google.com comp.lang.lisp:20524 * Chris Perkins | But, Java and C++, by their nature, can perform some basic contract | enforcement at compile time, rather than waiting for runtime. | Specifically, the compiler will bleat for violations of access | (public/private), argument count, and argument type. They also have a prohibitively expensive compilation process compared to Common Lisp. This is _why_ it is important in those languages to make sure that runtime is a less expensive debugging environment. Comparisons of language tend to forget their contexts and evolution completely, and take one of these for granted while the other is treated like a stranger in a strange land. This is why you should strive to forget where you came from and try to figure out how your new language came to be and why what it does is natural in its environment. | I would venture that most C++/Java programmers *like* type safety and see | it as a real advantage - they are warned of stupid mistakes at compile | time, rather than having to vette them out at runtime. That is because so many things are mistakes that no human being in his right mind can be expected to figure out are mistakes. Languages that are so hard only compilers (that are so hard to write that no human being in his right mind can do it) can figure out whether a program is correct, should simply not be used by human beings. I happen to think Java is pretty good this way while C++ is absolutely insane. | To my mind, C++/Java programmers gain the side effect of a simple | preconditional contract on their arguments by using types. And, bonus | for them, that contract is verified at compile time, rather than at | runtime. A less elaborate contract can actually be remembered and understood. | Does LISP have any way of doing this? I'm not proposing abusing type | specifications to achieve this, but is there anyway to have simple pre | and post conditional contracts verified outside of runtime? I think you should re-examine the reasons you are obsessing against run-time. Run-time may hurt in C++ because debugging is so hard, but learning from pain is not a very good way to learn the right thing. (The only thing that appears to work is to make it painful _not_ to think, because it is appears to be painful to many people to think.) Because you break to the debugger in Common Lisp and you can debug much more accurately when you do not compile your Common Lisp code, so the compiler is actually even less important than it might appear to be. | I would love a system to be able to specify pre & post conditional | contracts, class invariants, etc. and have them all checked by simply | issuing a command at the prompt. While I'm fantasizing, in an ideal | system, contracts that are 100% verifiable would be taken out of the code | (why slow it down?), and the rest would be converted to assert clauses to | continue runtime monitoring. One of the things you learn from writing serious Common Lisp programs is that you never take out the "checks and balances" part, because it does not slow the program down appreciably (use a profiler to find out where your performance is less than optimal -- it is not where you think it is, and certainly not in execution safety, which turns into crashes and long debug cycles when you remove them, reduce the safety setting, and ask for higher speed optimization, and all errors were not taken out of the code) and because even if you test your own code, you make it harder for others (including yourself) to use it, whether in that "reuse" fashion, or when modifying the program sometime later on. Coming from the C++ world, it can take a while to get used to programs that do not crash and burn. Likewise, returning from Common Lisp to C++ is _amazingly_ painful. /// -- 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.