On Sun, 27 Jun 2010 12:41:36 -0700 (PDT)
cageface <milese...@gmail.com> wrote:

> Python definitely seems to be the product of a very different design
> philosophy than Lisp. I've always felt it was too prescriptive.
> Omitting features that *might* be misused in an effort to keep the
> language simple seems to have backfired on them.

Not quite - it's to keep the language *readable*. And if there's a use
case for a feature that outweighs the damage done by abusing it,
they'll add it. Witness with, list comprehensions, and those
never-to-sufficiently-cursed augmented assignment operators. This
implies simple only to the extent that it shouldn't get so large that
one person can't keep the entire language in their head.

And yes, it's gotten a bit larger than most people would like. But
that's part of the point of Python 3.0 - removing some of the bits
that have been obsoleted by more recent additions, or at least moving
them out of the language core.

> Too keep up with the
> competition they've had to add so many new features to the core
> language (list comprehensions, annotations, iterators, with statement,
> properties etc) that Python doesn't feel like a small, simple language
> to me at all anymore. Anyway, I don't mean to pick on Python because
> it's not a bad language. I think this just illustrates that it's
> better to build from a simple, flexible core than to bolt on pieces
> later.

So how does providing a drill press and bolt set (i.e. - macros) to
the end user fit into this?

> I think you can go too far in the other direction too though.
> Certainly Scheme is a very elegant language but omits so much from the
> spec that you have dozens of incompatible OO implementations floating
> around. I think at a minimum a language should provide a single,
> consistent, standard implementation of the following:
> 
> 1. a string/text type
> 2. an abstract datatype/object model
> 3. container types
> 4. concurrency primitives
> 5. ffi
> 
> Clojure covers these points well, I think, and I'm not worried about
> Clojure fracturing into a babel of incompatible macro-based dialects.

Well, there are already multiple OO implementations on top of
1.1. Most of them are more to show that you can do that if you really
want to, and I'm not sure how much the additions to 1.2 will obsolete
them.

        <mike
-- 
Mike Meyer <m...@mired.org>             http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to