"Many people have webpages."

If your shop does OO or imperative design, and has between 10 and 500
coders working on something for Yoyodyne or MegaSoft, 'top down' might be
a good idea. It might be the only conceivable way of getting anything
done, despite the fact that you'll be sitting in specifications meetings
for weeks before doing any code writing.

If you're one to four guys working in the same boiler-room, this probably
isn't such a good idea. It's also a bad idea if you're doing something
truely new, and don't necessarily know how to get from point a to point b.
But in the latter case, deadlines are stupid anyway. I'm willing to bet "I
don't really know how to do this, though I think I can" is the source of
most deadline failures.

Despite the fact that the thing we call "a computer" pretty much sprung
fully formed from Von Neumann's brow after a few months of gestation in
1944 and 1945, everything else has been in fits and spurts, because we're
all a lot dumber than he was.

Things like relational databases, journaling file systems, the Macsyma
version of the Risch algorithm, multitasking OS and lisp itself seem to
have been invented in fits and starts and via a lot of noodling around.
Now that such things are standard, they should be easy for anyone to do
all over again (and, most software development *is* re-inventing the
wheel). But, practically speaking, a code-monkey may often be given a task
which he doesn't know how to do. And so he goes through similar (though
hopefully lesser) mental contortions, fits and spurts as the original
implementors of such ideas.

Regards,

(This is actually a pet peeve of mine regarding discussions about
software.  People will often ask, "Can you do X using
method/technique/tool Y?"  That is never the right question to ask because
the answer is always yes.  The right question to ask is, "How much easier
is it to do X using Y than without using Y (or by using Z instead)?"

What Spolsky is saying is not that you should take a boat.  He is saying
that you should *think* about whether or not to take a boat *before* you
strike out across the desert (i.e. begin to code), and that in fact you
should *write down* your decision and the rationale for it, e.g.:

"We're going to take a boat because our goal is to reach the East Coast
and we believe it is likely that we will encounter at least one unfordable
body of water along the way without enough resources nearby to be able to
fabricate a boat in situ."

or

"We're not going to take a boat because our goal is merely to cross the
desert, and the probability of encountering a long-lived and unfordable
body of water in the desert is low (since if we encounter such a body of
water we are ipso facto no longer in the desert)."

As opposed to, "Let's just start walking and if we hit a lake we'll figure
out what to do about it then."

So: does Lisp help when plans gang agly?  How?  Is that help worth the
tradeoff of the additional risk that Spolsky warns about (assuming you
accept Spolsky's argument)?  These are serious questions and I think we
(since I still count myself as a Lisp fan) would do well to come up with
cogent responses rather than just cavalierly dismiss them if we want to
see Lisp be a serious player in the software game and not just a toy for
noodling around.

+ Kent Beck, Extreme Programming Explained
+ Alistair Cockburn, Agile Software Methodologies
+ Kent Beck and Martin Fowler, Planning Extreme Programming

An important element of XP is test-first development. They actually do
not suggest to just wildly code ahead, but they have a very strict
process to follow, much stricter than, say, RUP.

It essentially goes like this: You first write user stories, then break
them up into manageable tasks, then you write test cases, and then you
write the code that makes the test cases succeed.

So the test cases actually take over the role of specifications - they
exactly tell you what is needed.

Another important element is to do the most simple thing that actually
works.

A toy example is this: Imagine you have a small set of test cases.

(assert (= (f 2) 4))
(assert (= (f 5) 10))
(assert (= (f 7) 14))

It's reasonable to write the following code to make these tests succeed:

(defun f (x)
   (ecase x
     (2 4)
     (5 10)
     (7 14)))

In later iterations, several more test cases are added:

(assert (= (f 1) 2))
(assert (= (f 3) 6))
(assert (= (f 4) 8))

The rule of doing the simplest thing actually makes you think about a
simpler implementation which leads you to come up with this:

(defun f (x)
   (* 2 x))

Again, this is a toy example. For more complex scenarios, it makes a lot
more sense. But it still illustrates the point that the resulting code
does not necessarily only cover the instances given in a test suite, but
rather will be as systematic as other code. However, in the end you will
have a rather large test suite which gives you much more confidence that
the code really works.

There are several more rules in XP that are to be followed. This is only
a sketch how XP works.

I have only shown the elements that argue against the widely held belief
that you need a detailed specification before you can program. The
counter argument is not to say that you don't need specifications, the
counter argument is that the specifications don't need to be static.
Test cases are "dynamic specifications".

Pascal

I love it. I think I'll just give the text widget a fixed size and get
on with my life. The funny thing is I was crafty enough not to make the
mouse-image dependent on the geometry of every widget on the screen
(meaning it would /not/ notice if some image moved under the mouse, as
it should, but that would take a deeper fix), but the calculation itself
still loops back.

I love this game!* :)

kenny

* Advertising slogan for NBA basketball

--

    $ portinstall clisp

and you're done. And

    $ portupgrade clisp

from time to time, assuming you're keeping your ports tree
up to date somehow.

I've been concentrating on physics, because that's what
everyone thinks of when philosophizing about science :-).
But, e.g., the theory of evolution didn't arise from
"testing well formulated hypotheses by carefully designed
experiments", so it's not just physics to which your
description doesn't apply universally.

What writing code gives you that writing specs doesn't
is the ability to feed real data in and see what happens.
Perhaps infinitely intelligent people wouldn't need that;
they could just contemplate an algorithm and see in their
heads what it would do in practice. Those of us who are
cursed with finite minds have to try things out. Sometimes
we can predict things using (say) mathematics, but in
these days of scarily fast computers it can be much
quicker to try a few algorithms than to analyse them.
(The analysis may still need to be done -- but maybe
only on one algorithm, after trying many.)

Another possible reason is that the actual tacit disclaimer
is more like "Provided you're writing the sort of stuff for
which writing specs is possible".

                             *

This all seems a bit surreal to me, anyway. There's no inconsistency
between using Lisp and writing specs. For certain (unusual, for most
programmers) kinds of problem, writing specs may be much less helpful
than it generally is, and Lisp may be very effective in attacking some
such problems. That doesn't mean that you can't use it for other
things.

Programs written in Lisp are generally easier to change than
programs written in C++. That doesn't mean you *have* to go
changing them all the time. (It does mean that some of the costs
of change are lower, which means that some of the reasons for
writing specs in advance are weaker, which may or may not be
enough to make a suck-it-and-see approach better than a
first-write-your-spec approach in some cases.) It doesn't
mean you *can't* write a spec at the start. All it means
is that when you need to make changes (which you do, even
if there's a detailed spec from the outset and the requirements
never change and the spec was done *really* well) you can
make them more easily. How can that be bad?

Maybe we shouldn't pore over his writing as if it were the Talmud.  I
get the impression you want a deep engineering debate, but this is a
guy who lets people peek into his company.  Reality TV, not Oxford
debates.  Sometimes reality TV is more enlightening, depends on what
you want to get out of it.

And hey, even the win32 reference standard is chaos now because I just
bolted in FTGL and ImageMagick and I have to rethink everything... well,
FTGL is painless, god bless it. But with i/m, well, it's painless, too,
but now I am thinking OpenGL now moves to the background and i/m (or the
open fork (GraphicsMagick?)) becomes the normal graphics toolkit, with
everythng dropping into an OpenGl texture for final rendering. raw
opengl widgets still possible, for those brave enough to go there.

Here's a samplr setback caused by the huge win of I/M (look at this API:
http://www.imagemagick.org/www/api.html -- check out esp. DrawingWand):
I now should resurrect my invalidation scheme, by which widgets get
selectively redrawn. Currently any graphical attribute changing anywhere
posts a GLUT redisplay event and the whole kebash gets re-rendered.
Yikes! With i/m every widget can have it's own pixmap (or I suppose draw
directly to a container's pixmap--these are the things now on the table)
and at redraw time most graphic components just whap their cached pixmap
out to the GPU and only the "invalid" ones re-render thru i/m to regen
the pixels.

But if you have checked the Cello pre-cursors on the t-t site reffed in
my sig, all those use an invalidation scheme, so I just need to dust one
of them off... nah. NIH applies to my own code, too. Rewrite! :)

kenny

--

  Do not put code in your program that might be used.  Do not leave
  hooks on which you can hang extensions.  The things you might want
  to do are infinite; that means that each has 0 probability of
  realization.  If you need an extension later, you can code it later
  -- and probably do a better job than if you did it now.  And if
  someone else adds the extension, will he notice the hooks you left?
  Will you document this aspect of your program?

There's probably more of this in "Thinking FORTH" if you can get your
hands on a copy.

* Gareth McCaughan
| This all seems a bit surreal to me, anyway.  There's no inconsistency
| between using Lisp and writing specs.

  Precisely.  Erann Gat equated what I said with «aimless hacking», and
  his bait only applies to such a surreal reading of what I wrote.  Some
  things have not changed in a year...

| Programs written in Lisp are generally easier to change than programs
| written in C++.  That doesn't mean you *have* to go changing them all
| the time.  (It does mean that some of the costs of change are lower,
| which means that some of the reasons for writing specs in advance are
| weaker, which may or may not be enough to make a suck-it-and-see
| approach better than a first-write-your-spec approach in some cases.)
| It doesn't mean you *can't* write a spec at the start.  All it means
| is that when you need to make changes (which you do, even if there's a
| detailed spec from the outset and the requirements never change and
| the spec was done *really* well) you can make them more easily.  How
| can that be bad?

  Very well said.  You relieved me completely of commenting on this.

--
Erik Naggum | Oslo, Norway                                      2004-028

Iterative approach assumes that changes into initial version of
specification at later stages of development are inevitable, which
means that the cost of change should be accounted for. Some of us find
that using Lisp makes that cost lower.

  Royce, W.W., Managing the Development of Large-Scale Software:
               Concepts and Techniques
               Proceedings, Wescon, August 1970
               (also reprinted in Proceedings, ICSE9)

It does include prototyping, involved customers, planned testing, etc.
It is sad it was forgotten, or then the early adopters didn't read past
figure one or two...

It's definitely a paper worth to find and read.

Ah, yezz... Which brings to mind the old aphorism:

   When you're up to your ass in alligators, it's hard to remember
   that your original intention was to drain the swamp.

-Rob