Python not a Very High-Level Language?

[Tim Peters]

[Ajith Prasad]
> http://www.oreilly.com/news/vhll_1299.html is an article by
> Greg Wilson

Interesting article!

> casting doubts on the effectiveness/value of Python and other
> very high level scripting languages. Wilson comments that:
> "Over the past few years, I have done several medium-sized
> projects using both Perl and Python. At first, I was very
> excited by what these Very-High Level Languages (VHLLs) let
> me do, and how quickly.

Hold that thought.

> The more I played with them, however, the less satisfied
> I was. In particular, I no longer believe that they
> deserve the 'V' in their name.

Unless he looked back and decided he was wrong about how quickly he got
stuff done at first <wink>, I say they still deserve the "V".  VHLLs were so
named in contrast to so-called HLLs (like Fortran, C and COBOL); the V has
more-than-less objective historical meaning -- the meaning isn't relative to
Greg's (or anyone else's) ever-increasing expectations.

A term I've often used for "what comes next" is UHLL, for Ultra High etc.
It's less typing than VVHLL or-- planning for the future <wink> --V2HLL.

> This article explores why, and suggests some ways in which
> they could evolve."
>
> Worth responding to as it includes detailed criticisms of
> Python in particular.

Well, I'd certainly agree that Python isn't a UHLL, and indeed lacks a few
common VHLL features (e.g., worrying about cyclic trash is grating in a
VHLL).  But there's no response to be made other than that There Are
Reasons, which were hashed and rehashed to death on c.l.py last millennium
<wink>, and are still under consideration.

OTOH, I've happily used several of the languages Greg champions as having
UHLLish features, and it's unclear they *can* be combined in sensible
ways -- mixing the world's tastiest apple with the world's most effective
motor oil yields something you're not likely to put in your car -- let alone
your mouth (e.g., while tastes differ, what I've seen of attempts to mix
functional styles with OO styles are usually ugly, and at best strained --
"no state" and "all state" just aren't a natural match!  you can emulate one
with the other, but it looks and feels like the trick it is).

In any case, it's quite rare for any given language to evolve in really
significant ways; there are strong pragmatic and social forces opposing it.
Fortran is a good example of an exception -- and many (I'd guess
overwhelmingly most) old-time Fortran programmers still want nothing to do
with the language currently called "Fortran".  So it goes!

People seeking revolution should look to new languages.  Languages Greg
didn't mention that should also be mined for inspiration are Prolog, Dylan
and SETL (the last being as close to a full-blown UHLL as I've ever seen).

After a mere decade <wink> of relentless salesmanship, I think there's some
marginally slim chance that Icon's notion of generators (in their
intersection with Sather's notion of iterators) *may* find their way into
Python2.  And a marginally better chance that SETL/Haskell's notion of list
comprehensions may be folded in.  Plus a good chance that the NumPy
extensions will move into the core.  I don't see Python moving in other
distinctly UHLL directions -- but, as is often & truly said, Python is not a
"research language", so speculative innovation isn't its *job*.  IDEs for
Python are a different matter, and much should be done to make life easier
there.

Curiously, Python's closest predecessor (ABC) had UHLLish quantifiers which
Python did not adopt, as in (pseudo-Python here):

    if each i in range(2, n) has n % i > 0:
        # we also get here if the iterator is empty
        print n, "is prime"
    else:
        # and here i is bound to a counter-example
        print n, "is divisible by", i

or

    if some i in x has some j in y has i+j == target:
        # i and j are bound to witnesses here
        print "x and y contain elements that sum to", target
    else:
        # i and j are not bound here; we also get here if
        # either iterator is empty
        print "nope"

Combine that with generators and list comprehensions, and you'd be amazed at
what you can accomplish in three lines of code.  Indeed, it may take you
three weeks to figure out what three lines of code do <0.9 wink>.

new-millennium-old-rant-ly y'rs  - tim