colostomy

[dirck at pacbell.net]

Moshe Zadka <mzadka at geocities.com> wrote:
> On Wed, 29 Mar 2000 dirckb at my-deja.com wrote:
>
> > A long time ago I used a C compiler on the DEC
> > VAX that would issue this warning message:
> > "missing semi-colon, assumed."
> > and Keep Compiling!
>
> That's exactly! what Guido hates, and I agree.
> How do you think we got in HTML hell?
> Precisely because browsers were trying to be helpful. TMTWODI
> just means you have to learn more then one syntax to read code.
>
I don't think I would attribute HTML hell to browsers trying
to be helpful. Why use a program if it isn't helpful?
Just stick to pencil and paper...
There is always more than one way to do something, just because no
two people think exactly the same way. A small coherent tool set,
instead of a kitchen sink approach, makes it more likely that the
implementation will be coherent to other people as well.
Python has distinct advantages here:
a clear vision, and a single reference implementation.
(c++ actually started out that way - oh well).
Any program suffers if it tries to be all things to all people.
HTML suffers from being a 'standard'.
Implementors interpret standards differently, and
if the standard doesn't cover desired functionality,
they don't always make good decisions about extending it.
In the case of browsers, the developers went every which way trying
to add more functionality. The browser wars weren't exactly a model
of cooperation, either.
A reference implementation is ideal because you can't argue about
what a program does - it just does what it does. If you match
the reference, you are 'correct'.
Because Python is open, anybody can try out any hack they like.
Presumably, on occasion, if a hack is useful and popular,
it might be blessed, and end up in the reference implementation.
Otherwise it will end up unsupported.
I think there is a definite difference between flexibility
and incoherence. Most software issues are subjective, and
subject to personal tastes. It's important to weigh issues on
their relative merits, and not try to develop based on absolutes.
[
there is no substitute for understanding
if you don't know what you are doing, rules won't help
if you do know what you are doing, rules are irrelevant
(if you are learning, rules can help lead the way)
]
But I digress.
It was a pet peeve of mine, and a fun hack. I can see how it added a
few ugly bits to the compiler code, though it slid in reasonably well
because of Python's architecture. I brought it up because there was
some discussion about Python 3k being source level incompatible, which
indicates some ideas are in flux. Doesn't sound like anyone shares my
enthusiasm for the minimalist syntax, which isn't a big deal. Over
time I will adapt ok. In the mean time, if i ever get frustrated when
I keep messing up, I can switch to a slightly more tolerant python and
focus on the programming, not on the programming language.
> > It was pretty impressive, a compiler actually
> > trying to be helpful.
>
> The right thing for a compiler to do is to insert the semi-colon
> for the *sole* purpose of finding more errors. However, putting
> error recovery in a compiler tends to complexify it a lot.
Yeah, that's the hard part. If the compiler isn't smart enough it
gets lost in a useless cascade of phantom errors. Lightspeed (er,
Think, er, Symantec, er...) C on the Mac used to just stop dead on the
first error and leave the cursor there for you to fix it. That's one
way to do it. Of course, you never had any idea how close you were to
actually running...
My thinking was, if the compiler is smart enough to put it in,
why does it need to be there in the first place?
what purpose does it serve?
...
Geeze, I best shut up now. Sorry to be so long winded.
Thanks for all the responses!
d
(news.pacbell.net STILL otl)
dirck at danbala.com
http://www.danbala.com
http://starship.python.net/crew/dirck


Sent via Deja.com http://www.deja.com/
Before you buy.