Subject: Re: Implementational Portability (was: multiple-value binding let and let*) From: Erik Naggum <erik@naggum.no> Date: 1999/08/23 Newsgroups: comp.lang.lisp Message-ID: <3144396420477272@naggum.no> * William Deakin | But how do you become a serious programmer? This is something I would | hope to become one day. But I do not have anybody to tutor or supervise | me and I do not have access to the ANSI cl specification. actually, you do. http://www.harlequin.com/education/books/HyperSpec/ download it if you can't use the Net in real time. | Even if I had read and though that I understood the specification of the | language, there are still grey areas that are subject to interpretation. there always will be in any specification useful to intelligent people. if intelligent people can't disagree on what something means, it isn't worth writing down. (now, somebody disagree on this, please. ;) | This raises the point about what is the "value of a variable?" This is | clearly subject to interpretation (bringing back the sound of a tree | falling in the forest) and it would help if there was a bit more carping. even if it were worded differently, someone might decide to carp more than others, as CMUCL does, and people would find it difficult to ignore a warning, such as when they disagreed about the exact condition under which something is unspecified or even argue that it is underspecified. I believe in conforming to standards, but as a baseline, not as the end. conformance means you can trust something to be the way the specification says it should be, but it doesn't make sense to ask the specification a question like "what does it mean to do something that doesn't have fully specified behavior?". the proper answer is "why do you want to do that?". note also that when the specification doesn't say anything at all, it does in fact say "all that we say nothing about has unspecified behavior" and it equally invalid to use a specification to prove a point outside of exactly what it says. to answer your first question: you become a serious programmer by going through a stage where you are fully aware of the degree to which you know the specification, meaning both the explicit and the tacit specification of your language and of your problem. "hey, it works most of the time" is the very antithesis of a serious programmer, and certain languages can only support code like that. over time, you get a good gut feeling for the failure mode of your assumptions, and when you can trust that you are unlikely to make grossly invalid assumptions, the dangers that people run into in the absence of that trust vanish in a puff of standardization: it's the kind of trust you buy from somebody who claims to be conformant. non-conformance is about violating this sense of trust. certain languages support serious programmers, and others don't. e.g., I don't think it is at all possible to become a serious programmer using Visual Basic or Perl. if you think hard about what Perl code will do on the borders of the known input space, your head will explode. if you write Perl code to handle input problems gracefully, your programs will become gargantuan: the normal failure mode is to terminate with no idea how far into the process you got or how much of an incomplete task was actually performed. in my view, serious programmers don't deal with tools that _force_ them to hope everything works. #:Erik -- save the children: just say NO to sex with pro-lifers