Python's biggest compromises

[Andrew Dalke]

Dennis Lee Bieber:
>         I'd swear that the BASIC I learned on -- via a timeshare
> Honeywell-Bull using a dial-up from an ASR-33 -- back in 1972 was
> interpreted...

Well, my background is all microcomputer basics in the 80s, including
some (very little) HP BASIC for lab equipment, so I'm not a good
judge.  Were I to implement a compiled BASIC I would have done
the "compile on <ret>" you suggested.  One of the links described the
Dartmouth BASIC commands and they would be easy to implement
that way.

>         Python's compatibility doesn't /feel/ like a different language;
> through all the changes in Python, a Python 1.3 program /looks/ like a
> Python 2.2+ program.

In playing around with some of the new Python 2.3 features, I noticed
myself using a more functional style, like

d = {"A": 1, "B": 9", ...}  # all uppercase keys
d.update(dict([(k.lower(), v) for k, v in d.items()]))

instead of the more readable and faster

for k, v in d.items():
    d[k.lower] = v

It's easier in Python 2.2+ to make Python code which doesn't
look like Python 1.3.  Which I think is the version I started with.  ;)

When I got QuickBasic in 1988 or so, it would run just about
all of my old GW-BASIC programs, which was distributed some
5 years previous.  But it's true, the GW-BASIC program wouldn't
look like a QB program.

Thinking some more ... the 1.3 code would have string
exceptions, so that's one age indicator.  It would use the
"while 1 / readline / if not line / break" idiom instead of the
more modern 'for line in file'.  It didn't have module support,
IIRC, and only the regex module for regular expressions.
Ahh, and no string methods.  That's very noticible when I
look at pre-2.0 code.

Okay, so the two main things that would make a 1.3-style
code stick out is using string.* and raising string exceptions.
In other words, I mostly agree with you, but couldn't let
you get a complete bye :)

>         But between early 70s BASIC and what passes for BASIC today looks
like
> totally different languages.

I stopped about 10 years ago.  I do recall reading an article by
a VB book author saying VB_(N+1) was too different from VB(N)
and the differences were driven by marketing and not for good
programming reasons.

There's also the TrueBASIC folks.  I believe they started in the
mid-80s and argue their BASIC is essentially the same.

> quick glance...  Let a non-programmer look at source files from K&K
> type BASIC, Visual BASIC, F-IV, F77, and F90... and he likely will be
> able to identify the three Fortrans as being related -- but would not
> consider K&K to be a relation of VB.

Interesting test.  Nasty idea: get that same person to judge if
Lisp and Scheme are closely related then post the results on c.l.lisp.

                    Andrew
                    dalke at dalkescientific.com