From ...
From: Erik Naggum
Subject: Re: Implementational Portability (was: multiple-value binding let and let*)
Date: 1999/08/23
Message-ID: <3144396420477272@naggum.no>#1/1
X-Deja-AN: 516126108
References: <3143984828088049@naggum.no> <3144039684834581@naggum.no> <3144063865821902@naggum.no> <4672bvejd.fsf_-_@beta.franz.com> <44shvvdef.fsf@beta.franz.com> <37BD6A2B.3FCE9E1B@pindar.com> <3144377424777287@naggum.no> <37C112D5.BF384F9@pindar.com>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; +1 510 435 8604; http://www.naggum.no
Newsgroups: comp.lang.lisp
* 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