Is this a dream or a nightmare? (Was Re: XML)

[Alex Martelli]

"David T. Grove" <pete at petes-place.com> wrote in message
news:39e0a4b5.91145097 at news.davesworld.net...
    [snip]
> >Hey, waitaminute!  It this a case where the Python code is actually
> >_smaller_ than the "natural language" equivalent above?
>
> Why do you think I'm wanting to migrate to Python rather than, say,
> C++, with its ungodly verbosity? (Yes, Alex, that's a jab.) Of course,

Jab all you want -- me, I never made any silly claims about "verbosity"
of different programming languages.  The reference you were already given:
    http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf
shows median SLOC's for scripting languages, for a given task, of about
100 for scripting languages (Tcl, Rexx, Python, Perl) and about 250 for
traditional compiled ones (C, C++, Java), without really significant
distinctions among the languages inside each group.  You're the one who
made the extravagant claim of C++ taking 4 times more lines than C, and
Python taking 25 times more than Perl -- and I still haven't seen you
either back down totally from it, or write anything justifying it.  I
guess it's cheaper and handier to jab than to prove a totally false and
unjustified claim (or admit it always was totally false and
unjustified)...:-).


> My boss has always wondered why I'm more partial to doing it myself
> rather than giving good specifications to have someone else do it. The
> problem is, by the time the specs are written, I could have programmed
> it myself.

Writing good specs is an art, as it tight and effective coding, and
one may well have mastered either one but not both of these arts -- they
are related, but definitely not identical.

Unconstrained natural language is far too vague and ambiguous to make
a really good specification-language, anyway.  Just look at how formal
language standards expressed in constrained natural language apply those
constraints -- e.g., see the XML standard as an (IMHO) pretty good example.

Specifications gain a decisive advantage over prototypes if and when they
can make use, "by reference" so to speak, to a body of existing knowledge
(maths, logic, existing standards) that is not also embodied in executable
code a prototype could use in a similarly direct way.  "Implement and
expose a dual-interface COM object model allowing access to a W3C-standard
DOM for any compliant XML document", for example, is a 2-lines spec for
a (guessing...) over-10,000-lines task -- because it implicitly refers
to a couple of large bodies of existing standards (MS' COM, and W3C's XML).

A prototype would get back to evens if it could satisfy that spec with
something like "return CreateObject('Existing.XmlDomStuff')"...:-).

What I'm getting at, is that *re-use* is the key to productivity in both
fields, specifying and coding -- one of the crucial ways in which they
are "related".  If you're building totally from scratch in either case,
OR if you're reusing "the works" in either case, there may not be much
productivity advantage to either approach.

"Requirements is a dialog, not a document" -- one of the keys of the
Extreme Programming approach -- may be a fruitful thing to ponder.  I
suggest starting from http://c2.com/cgi/wiki?ExtremeProgramming.


Alex