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

[Grant Griffin]

David T. Grove wrote:
> 
> >> die unless @d = map {"$basedir/$_"} grep {!-d && -w} readdir(dir);
> >>
> >
> >What in the heck does all _that_ mean?
> 
> Actually, fully extended, it means "give me a platform independent
> list of writable (non-directory) files in that directory in a form
> that will allow me to name the files so that I can see them from
> elsewhere in my code regardless of where they are on disk, or halt
> immediately because if this doesn't work you might screw something
> up".
> 
> >
> >> ...which is perfectly logical and readable to me as a single
> >> "thought"... "get me all the filenames in that directory or halt
> >> immediately because you'll screw something up".
> >
> >OK, _now_ I see!  9If only Perl were as readable as a natural language.
> ><wink>)
> 
> If I knew of one that could express this with as little typing, I'd
> switch immediately. LOL.

Programmers do tend to be rather focused on how much typing they have to
do, but that's just false economy.  The unstated premise of typing
fetishists is that most of the time and energy of programming is devoted
to typing.  But clearly this is not the case.  For example, how would
you compare the ratio of time it takes to just _type_ in a program from
a page versus how long it takes to _write_ one from scratch?

"Writing" takes longer than "typing".  But writing is only the
beginning.  My experience is that debugging almost always takes longer
than writing.  So what causes bugs?  In my experience, bugs are mostly
caused by code that isn't fully understood.  (If you fully understood
it, you wouldn't have written a bug into it, silly!)  Similarly,
removing bugs mostly consists of the process of fully understanding your
code.  Once the source of a bug is found, fixing it is almost always
trivial.  And that brings us back to typing.  Fixing bugs involves very
little typing.

Personally, I place a *VERY* high value on readability.  (Admittedly,
this is a bit of a personal value; others don't always share it)  Now,
readability is partly a function of the programmer ("you can write
Fortran in any language"), and is partly a function of the language
("Fortran is by far the easiest language to write Fortran in").  So my
quest for readability (understandability) leads me to write the most
readable code I can, in the most readable language I can find that is
suited to the job.  (In that vein, I'm hoping that "Static Python" will
someday replace C/C++.)

One could argue that most of the progress that has been made in
programming languages has to do increasing readability (or maybe
"understandability").  The two most obvious examples are the emergence
of structured programming, followed by object-oriented programming. 
Perl and Python include both of these.

> >if-i-were-designing-a-programming-language-with-the-express-purpose
> >   -of-eliminating-lines,-i'd-pick-on-the-braces-before-the
> >   -semicolons-(or-maybe-just-eliminate-both-<wink>)-ly y'rs,
> 
> (What is this. Some kinf of "japh" sig?

Not really: each one is different.  (Python code is easier to customize
than Perl. <wink>)

> It appears to be limited to
> this newsgroup,

Naw, I use it on comp.dsp, too.  I can't say that it's very popular
there, though. <wink>

> so I assume it's python-based in some way.

I think Tim Peters taught us.

> Still have to figure out the "-ly y'rs".)

Tim has a story on that.  I forget the details.  <<masonic handshake>>

> OH I GET IT!!! The -ly y'rs is the whole clue, ain't it? Just a
> "Sincerely Yours" with python indentation.

Naw.  IIRC, it doesn't have any specific relation to Python syntax. 
(BTW, neither does "wink". <wink>)

> Hmmm. I'll have to try
> that. Nobody laugh as I screw up my first few with something silly.

OK, here's a tip: some aren't silly, but all things being equal, silly
helps.

> Rather more polite than a japh, I'd say.

And a _lot_ more polite than Tom Christiansen.  <0.1 wink>

(BTW, figuring out what wink numers are for is left as an exercise for
the student. <0.7 wink>)

> Well, just because you can't see your beginning spaces or tabs that
> define your blocks doesn't mean that they're not extra characters in
> your file. They just happen to be invisible to the naked eye unless
> you have CodeMagic set to see invisible characters. The semi-colon
> just becomes a habit, though.

It's not really about characters...

One benefit of indenting is that, since all experienced programmers do
it anyway (except, strangely, on C's #if's--go figure), why not take
credit for them?  If they have meaning to _you_, why not let the
programming language in on that?  
Also, what about "single-point maintenance"?  If braces are meaningful
to the compiler, but indents are meaningful to you, what happens when
the two become inconsistent?  You get fooled, because the braces are
what really count.

But Tim has suggested an even _more_ sinister reason for them: braces
can be placed umpteen ways; everybody has a different preference, and
some folks will fight you to the death that their way is "best"; note,
however, that this unfortunate "more than one way to do it"-based
problem magically disappears when you swap indents for braces. 
(However, I guess Pythoneers still can fight about the number of
spaces-per-indent.  Guido's magic wand can only solve so many problems.
;-)  

Also, I guess I'm an adherent of Will Strunk's imperitive to "omit
needless words".  (Despite all the blather you read from me here.
<wink>)  Strunk justifies this by comparing it to a couple of more
obvious cases: "a drawing should have no unnecessary lines" and "a
machine should have no unnecessy parts".

Given that the Python machine seems to do just fine without braces and
semicolon, one can only conclude that those are unnecessary parts in
other programming language machines.  In fact, a mechanical text
translation could easily allow Perl-with-indents, C-with-indents, (or
even--egad!--Python-with-braces).

The use of indents instead of braces certainly alienates a few folks,
but since the whole nutty indent thing fits perfectly into Tim Peters'
Python philosophy (see http://www.python.org/doc/Humor.html#zen), folks
who don't like indents probably wouldn't much care for the rest of
Python either.

> You'll never know how many sentences
> I've written in emails and normal (non code) documents where I've
> accidentally hit the semi-colon rather than the period.

That's funny: I write a lot of emails and non-code documents myself, but
I've never once accidently hit the period when writing Python; <wink>

> In code, I
> don't actually see it. My eye passes it just as much as yours passes
> your spaces or tabs.

OK, on that basis, how would you respond to the following statement
recently made by a poster to comp.lang.python?:

> If I knew of one [programming language] that could express this with
> as little typing, I'd switch immediately. 

Actually, IMHO, it's not about typing--and never has been.  It's about
clearing the forest so you can see the trees--which is kind of where
Strunk's "omit needless words" idea is coming from.  In other words,
that which does not add, detracts.

> If-it-weren't-for-monotype-text,-you'd-never-catch-your-end-of-block
>     -errors,-though-ly y'rs.

OK, ya' got me. ;-)

But don't tell us that you program _Perl_ using proportional fonts? 
(Perl folks just amaze me with the creative ways they come up with to
make their code hard to read. <wink>)

> 
> ;-))
> 
> Did I do that right? Give a guy a break it's my first python japhsig.

Hey, that's pretty good!

for-a-first-try-<wink>-ly y'rs,

=g2
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation	      http://www.iowegian.com