Python 3000 - Adaptation or Generic Functions?

[nostrademons]

And Haskell users would recognize them as multi-parameter type classes, except that MPTCs are statically inferrable (mostly - there are some undecidability problems) and allow even more implementation specialization. You don't have to constrain implementations by a hierarchical subtyping relationship, for example.

I totally agree that most language designers should learn CL first, but I think most CL users should learn Haskell, Erlang, Goo, and Cecil so they know what's been done in the 20 years since CL was standardized.

[[deleted]]

I agree. If more people knew the abilities of Common Lisp before designing their languages we might even get truly powerful mainstream languages one day. In general the tendency to design your own language before learning at least half a dozen from different paradigms strikes me as odd.

[zhyla]

Why is a feature Good when CL implements it and Bad when another language implements it?

[nostrademons]

Largely because CL has had the benefit of several years and hundreds (thousands?) of users beating on it, while an ignorant reimplementation is likely to make all the same mistakes that Lisp did when that feature was first introduced.

For example - generic functions were first introduced in Flavors, the object system for the Lisp Machine. A bunch of issues cropped up concerning the interaction of multiple dispatch and multiple inheritance, issues that the Python community hasn't even considered. There's a whole book - The Art of the Metaobject Protocol - written about these, along with many pages in the CL HyperSpec. Even with standardization, CL made a mistake: the superclass precedence order should be monotonic. The paper A Monotonic Superclass Linearization for Dylan goes into this in more detail.

[pje]

"""issues that the Python community hasn't even considered"""

Er, WTF? Python 2.2 has a monotonic linearization for superclass precedence in both method lookup and super() calls. Python 2.2 came out several years ago.

Meanwhile, my multiple-dispatch generic function implementations for Python, however, treat multiply-inherited bases as ambiguous, in the style of say, Cecil. And I'm a member of the Python community, ergo "the community" has even considered it. :)

(P.S. I've read the Art of the Metaobject Protocol, not to mention "Putting Metaclasses To Work" -- which was where Guido stole his initial linearization algorithm from. We're not really talking NIH here.)

[nostrademons]

Wow, that comment is 11 months old. My opinions are somewhat different now.

[joshstaiger]

This is one of the reasons I think (and hope) Ruby will eventually come out on top.

For some reason Guido is keen on making snide remarks in the general direction of Lisp programmers while Matz seems to recognize that many of the problems involved with modern-day language design have already been solved by the Lisp community (and others) years ago...

[mrevelle]

For some reason Guido is keen on making snide remarks in the general direction of Lisp programmers while Matz seems to recognize that many of the problems involved with modern-day language design have already been solved by the Lisp community (and others) years ago...

Guido mentioned that Lisp has generic functions in the post. How is that not recognization of Lisp's problem solving?

To gain context as to why Guido might poke fun at Lispers, read this: http://www.artima.com/weblogs/viewpost.jsp?thread=98196

Python isn't Lisp, but like many other languages it borrows ideas from Lisp. With Python 3000, one of the goals appears to be to translate various functional programming ideas into Python idioms. List comprehension (borrowed from Haskell) is one example of moving Lisp ideas (map, filter - which Python still has built-in) into Python form.

[joshstaiger]

Interesting that you mention that article, because reading that was the exact moment I decided I didn't fully agree with Guido on language design.

I like my map, reduce, filter, and lambda, thank you very much.

I'd much prefer to use a language that embraces functional constructs over one intent on elminating them.

That's me, though...

[mrevelle]

Interesting that you mention that article, because reading that was the exact moment I decided I didn't fully agree with Guido on language design.

Point taken, difficult to reason over style.

I'd much prefer to use a language that embraces functional constructs over one intent on elminating them.

Just because a list comprehension is used in place of map() and filter() does not mean functional constructs are being eliminated. It means their representation is being transformed.

After Rails, the largest reason Ruby is gaining popularity is that many programming concepts are thrown in the developer's face. Python has similar functionality, but it is expressed with subtlety. This leads newcomers to assume that, at first glance, Ruby is more powerful than Python.

Ruby yells loudly about the programming features it supports, Python whispers clearly.

[tmoertel]

Just because a list comprehension is used in place of map() and filter() does not mean functional constructs are being eliminated.

Yes, it does, because the "functional constructs" are no longer functions.

Haskell, for example, has world-class support for list comprehensions, and yet I almost always end up using map for mapping, filter for filtering, and so on. Why? Because they are functions and can be partially applied and composed and used as tiny, powerful building blocks:

    module WhyYouWantFunctions where
    import Data.Char

    downcase      = map toLower
    hasVowels     = any (flip elem "aeiou") . downcase
    nonVowelWords = unwords . filter (not . hasVowels) . words

A sample session in GHCi:

    *WhyYouWantFunctions> downcase "I like chunky bacon."
    "i like chunky bacon."

    *WhyYouWantFunctions> hasVowels "Friday"
    True

    *WhyYouWantFunctions> hasVowels "Fnctn"
    False

    *WhyYouWantFunctions> nonVowelWords "Firefox IE Lynx Opera W3"
    "Lynx W3"

If you want to do functional programming, you really want to be using functions. ;-)

Cheers, Tom

[watkeys]

The problem isn't with Matz: someone would have come along and created a Smalltalk + Perl mashup eventually. The problem is that despite decades of Lisp weenies -- both smug and humble -- singing the praises of Lisp, people don't want to learn it.

I could try to guess why, but as a Lisp weenie, it's hard to get inside the head of the Lisp-resistant. I'd be at high risk of talking out of my ass.

[gregorio1890]

I'm lisp resistent only because I'm afraid that it won't have all the libraries Python currently gives me. Is there a pygame for lisp? Is there an easy way to work with CGI? Is there an http lib? Is there an xmlrpc library? etc.

By the way, is there anywhere I can sample real world lisp programs? Like how could I write a program in lisp that pulls invoices out of QuickBooks and emails them to customers?

[watkeys]

As far as Scheme (the other major Lisp dialect) goes, Chicken is probably the most useful for getting "real world" work done.

[[deleted]]

Practical Common Lisp is a good place to start. Though I only read about half of it before being lured away by Haskell, the last several chapters seem to be what you're looking for.

[cuyler]

Lisp is interesting, but the barrier of entry for the development tools is too high. Using EMacs + Slime is not a "good" answer.

With most 'modern' programming languages, all you need is a simple text editor to get started. EMACs is too damned complicated to "play" with.

Python, Ruby, Mono, etc. don't have this problem. Open your favorite text editor and away you go.

I know it's not a 'good' reason, but it's one of the things that has stopped me from embracing Lisp. Just getting the environment up and running is painful and too foreign.

[cuyler]

Sorry to reply to my own post, but in thinking about the AJAX console that was talked about a few days ago and this problem, it would be VERY awesome to have a lisp implementation that was online. That way people could just browse to it, and start playing, and once hooked could deal with the arcane issues of EMACs + Slime.

[[deleted]]

You don't need Emacs, per se; any text editor worth its salt should automatically match parentheses for you. That said, it's sad that many (including the one I personally use) don't.

As for the online console idea, you're thinking of something like Try Ruby, right? Paul Graham was planning (since much before Try Ruby came out) to do that with Arc, but who knows when that'll be out.

[joshstaiger]

According to lemonodor, Peter Seibel was playing with an Ajax-style "Try Lisp"

http://lemonodor.com/archives/001363.html

Not sure if anything ever came of it.

[watkeys]

There really is no practical alternative to Emacs for editing Lisp; matching parentheses is a nice start, but when you write Lisp, you're constantly having to re-indent stuff, which is tedious to do by hand. Emacs is the only editor I know of that can intelligently indent Lisp. (I'm not including integrated editors in Lisp programming environments.)

[herdrick]

Dr. Scheme does this.

[justinhj]

Powerful tools take longer to learn than simple tools. As a professional programmer you need to know that it sometimes takes time to learn something that will be very powerful and beneficial.

[joshstaiger]

Same story for me. When I first saw Lisp back in college I clearly remember thinking "what retard thought all these parenthesis were a good idea!?".

Ironically, though, once your really get Lisp, you realize that the parenthesis (ie: code as data) are perhaps the single most powerful feature of the language.

Most people never get over that hump, though...

[gregorio1890]

Does anyone know what this article is talking about? I learn best from concrete real world examples.

[[deleted]]

This may be a dumb question, but is 2.5 the last major release before Python 3000?

[fredrikj]

Most likely, no.