Is Python for me?

[Kendall G. Clark]

On Tue, 20 Feb 2001 13:37:40 +0100, Alex Martelli <aleaxit at yahoo.com> wrote:

>Yes (such as: what is the best C-coded ANOVA package for Python...
>see my latest post!), but the (non-empty) set does not include
>O'Haskell (nor, alas, Mondrian -- which is a hack of which
>respondent sayeth no further).  O'Haskell looks cool, but I just
>would not recommend it within the given constraints 1-5 (which
>I invite you to review) -- it may mature into something *really*
>great, but it's still at "rabid early-adopters" stage now (IMHO).

Re: Mondrian, I didn't find it very compelling either, but if
someone is just really aching for objects and Haskell, it's at
least in the neighborhood. (I don't claim it satisfies the
5 criteria of the original poster.)

(Perhaps the only real claim to widespread interest Mondrian
has is that it seems one of the many languages, variants,
or alternative implementations springing up around MS's .NET
project. As an assiduous avoider of all things MS, and a booster
of all things open source or free software, I have some concerns
about .NET. But I'm also finding the kind of ancillary initiatives
it's either causing or funding to be of some interest when I put
on my 'social informatics' hat. Off the top of my head, I can think
of several languages that are working to accomodate .NET in some way:
Mondrian, Mercury, Smalltalk, Python, and so on. There may yet be
some interesting things of an analytic sort to be said about all
this. I just don't know what they are yet!)

Of course if one is *really* aching for objects and Haskell,
Ocaml may be the best practical choice (even given the differ-
ences between Haskell and the ML family).

Er, and it was also a decent chance to give a pointer to O'Haskell,
an effort that deserves to find some success.

>> 2. the Timbot is (still) spreading about the hoary 'Common Lisp is
>> *really* huge' myth[1]?

>Wasn't that in the context of a comparison with Scheme?  In which
>case, it seems to me that it's no myth, but simple fact.  It's not
>an issue of dimension of executable images, etc -- it's an issue
>of how big the *language* (with its libraries) is.  

Hmm, no, I didn't read it like that. But the original point was
just a throwaway line, I suspect, so it's not worth quibbling about,
at least not as matter of Timbotean exegesis. :>.

Your distinction between library and language conceptual size and 
the size of *all* the parts and pieces required to make working
programs in a given language is exactly right. CL isn't a large system
in the latter sense; but for many cases -- except perhaps all those
where Scheme *really* flourishes (like pedagogical uses and embed-and-
extend uses) -- library "largeness" is a very good thing. It's just
about the only good thing *I* can say about Perl, for example, though
Perl and CL libraries are rather different in the terrain they cover
(and cover best).

I did take Timbot to be making a claim about CL's largeness re:
development infrastructure, runtime requirements, etc. Maybe I was
just misreading him. At any rate, that *is* one of the hoary myths --
together with 'it's slow' and 'it's interpreted, so slow' and 'it's
just for AI' and 'it's just for academic wankers' -- that, together
with other factors, tends to hold CL back from the more widespread
commercial acceptance it rightly, in my view, deserves.

My *real* point was that one has to look far and wide, as I think I've
proven (!), to find stuff to complain about on c.l.python, which is
consistently excellent and often fun. ;>

Best,
Kendall Clark
-- 
In this world there are only two tragedies. One is not getting what one
wants, and the other is getting it. --Oscar Wilde