Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> Haskell and ML are both evaluate typed lambda calculus unlike Lisp
> which is based on untyped lambda calculus.  Certainly the most
> familiar features of Lisp (dynamic typing, S-expression syntax,
> programs as data (Lisp's macro system results from this)) are absent
> from Haskell and ML.

And that is supposed to make them better and more flexible???  The
ideal language of the future will have *optional* manifest typing
along with type-inference, and will have some sort of pramgma to turn
on warnings when variables are forced to become dynamic due to there
not being enough type information to infer the type.  But it will
still allow programming with dynamic typing when that is necessary.

The last time I looked at Haskell, it was still in the stage of being
a language that only an academic could love.  Though, it was certainly
interesting.

> Haskell's type system lets it do stuff that Lisp can't approach.

What kind of stuff?  Compile-time polymorphism is cool for efficiency
and type safety, but doesn't actually provide you with any extra
functionality that I'm aware of.

> I'm reserving judgement about whether Haskell is really practical
> for application development, but it can do stuff that no traditional
> Lisp can (e.g. its concurrency and parallelism stuff, with
> correctness enforced by the type system).  It makes it pretty clear
> that Lisp has become Blub.

Where do you get this idea that the Lisp world does not get such
things as parallelism?  StarLisp was designed for the Connection
Machine by Thinking Machines themselves.  The Connection Machine was
one of the most parallel machines ever designed.  Alas, it was ahead of
it's time.

Also, I know a research scientist at CSAIL at MIT who has designed and
implemented a version of Lisp for doing audio and video art.  It was
designed from the ground-up to deal with realtime audio and video
streams as first class objects.  It's actually pretty incredible -- in
just a few lines of code, you can set up a program that displays the
same video multiplied and tiled into a large grid of little videos
tiles, but where a different filter or delay is applied to each tile.
This allows for some stunningly strange and interesting video output.
Similar things can be done in the language with music (though if you
did that particular experiment it would probably just sound
cacophonous).

Does that sound like an understanding of concurrency to you?  Yes, I
thought so.

Also, Dylan has optional manifests types and type inference, so the
Lisp community understands some of the benefits of static typing.
(Even MacLisp had optional manifest types, but they weren't  there for
safety, but rather for performance.  Using them, you could get Fortran
level of performance out of Lisp, which was quite a feat at the time.)

> ML's original implementation language is completely irrelevant;
> after all Python is still implemented in C.

Except that in the case of ML, it was mostly just a thin veneer on
Lisp that added a typing system and type inference.

>> Also, Scheme has a purely functional core (few people stick to it, of
>> course), and there are purely functional dialects of Lisp.

> Scheme has never been purely functional.  It has had mutation since
> the beginning.

I never said that was purely functional -- I said that it has a purely
functional core.  I.e., all the functions that have side effects have
and "!" on their ends (or at least they did when I learned the
language), and there are styles of programming in Scheme that
discourage using any of those functions.

|>oug

P.S.  The last time I took a language class (about five or six years
ago), the most interesting languages I thought were descended from
Self, not any functional language.  (And Self, of course is descended
from Smalltalk, which is descended from Lisp.)