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