Lambda the Ultimate

it's just so fun to use and has made me twenty times more productive!. Well, I happen to like Python a lot.

I like Python. It is my "scripting language" of choice. In fact, I am working on a little Python tool as we speak.

For what it's worth some of the things that made me productive were that I could use lists, map over them (and apply anonymous functions) and use list comprehensions.

Shouldn't the functional languages heritage be acknowledged more often?

A lot of my favourite things about Python are taken from functional languages.

The other thing I like a lot is the degree of control you have over what happens when something tries to invoke a method or set/get an attribute on an object. Support for metaprogramming is one of Python's stronger points.

I think Frank emitted a jibe in passing about how all "scripting languages" were just Scheme with added syntax. Actually, I think that's about right. Scheme with added syntax is pretty much what I want, and Python, Ruby and Javascript are all reasonably acceptable variations on that theme.

will python 3000 (the next big change) be less functional?
IIRC GvR is going to kill the various lambda, map,filter & reduce leaving just generator expressions/list comprehension. Ok, I know LC are a functional heritage too, but I kind of liked map & lambda :/

How could they get rid of reduce? I'm fine with getting rid of map and filter--list comprehensions replace them pretty well--but reduce still hasn't been replaced. Anyone who's used true lazy lists (aka streams, as Scheme has them) doesn't really like generators; they're like lazy lists' evil, incompitent twin. When accessing the next "element", you loose the past one. With function decorators (which I assume will also be generator decorators), you could solve this (I guess you already could today, it'd just be ugly) by making a class to memoize it, but then GvR doesn't seem to like it too much when we make abstractions....

I suspect that all the genuinely desirable properties of dynamic languages will turn out to be properties of some as yet uncreated statically-typed language X, but while we're waiting for X to arrive

I often wonder if that lack of waiting--the let's make something useful right now, theory be damned, philosophy--is what makes dynamic typing so appealing. So many functional language arguments include statements like "You can get that kind of type system right now in language X" where X is some not-anywhere-near-production-ready research project. So while it may be true that a future statically typed language will encompass the properties of currently popular dynamically typed languages, waiting for it isn't an option.

I want to make clear that I agree with this.

My points of concern—not disagreement, just concern—are:

• Correctness concerns. Most of the debate to this point has been about these, and perhaps that wasn't an effective focus.
• Ossification concerns ("Well, sure, this new statically type-inferred does what Python does more safely and faster, but we already have 100,000 lines of Python.")
• Mindset lock-in concerns ("Hey, our 100,000 lines of Python works most of the time, nevermind that it look five years to iron out all the priority-one bugs. Why should we change?")

A twentieth century problem is that technology has become too "easy". When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. This is inverse vandalism: the making of things because you can. Couple this to even less sophisticated buyers and you have generated an exploitation marketplace similar to that set up for teenagers.

Still, in the final analysis, I do have to agree that the expressive/convenience difference between, say, O'Caml and Python is epsilon, so the only concrete reason I can think of to choose O'Caml over Python is speed, and heaven knows there are other DLs that are faster than Python (pick any compiled Lisp or Scheme, for example).

James Hague: "So while it may be true that a future statically typed language will encompass the properties of currently popular dynamically typed languages, waiting for it isn't an option."

I want to make clear that I agree with this.

If you agree with James Hague (good call!), then you're implicitly acknowledging something about the richness or at least flexibility of the latent type systems in dynamically checked languages. That is, unless you have some other explanation for the relevant DL properties.

It doesn't seem consistent to simultaneously hold that position along with what you more recently wrote in another post, "there are no grounds for even suggesting, let alone claiming, that DLs are richer than SLs".

In this particular case, all I'm agreeing with is James' observation that in industry we don't have the luxury of waiting for, e.g. Epigram to show up on job listings.

Now, having said that, I do happen to know that many DLs do have quite rich latent type systems. What I also know is that they don't have an extensive body of literature describing foundational support for the definition of those systems. As you've no doubt noticed, this bothers me a lot.

Anton: It doesn't seem consistent to simultaneously hold that position along with what you more recently wrote in another post, "there are no grounds for even suggesting, let alone claiming, that DLs are richer than SLs".

I'll get there on the other thread, but let me just note here that I have what feels to me like exactly the same "er" problem that you had with the untyped/unityped error that Frank and I made: we now seem to have shifted back to the (perceived) claim that DLs are somehow richer than SLs.

Anton van Straaten: "If you agree with James Hague (good call!), then you're implicitly acknowledging something about the richness or at least flexibility of the latent type systems in dynamically checked languages. That is, unless you have some other explanation for the relevant DL properties."

In this particular case, all I'm agreeing with is James' observation that in industry we don't have the luxury of waiting for, e.g. Epigram to show up on job listings.

What I also know is that they don't have an extensive body of literature describing foundational support for the definition of those systems. As you've no doubt noticed, this bothers me a lot.

we now seem to have shifted back to the (perceived) claim that DLs are somehow richer than SLs.

I can do it over SLIP, Ethernet, ...

Seriously, SOAP is a link in a big foodchain of abstractions, it preys on transports, and is eaten by more high-level (non-)protocols like WebServices.

Ofcourse you can run TCP/IP over multiple transports, it's a protocol. SOAP doesn't tell you anything about garantueed delivery (or not), idem potency (or not) etc. TCP/IP does, best as I remember.
(I am a little out of my sweetspot here, so I could be wrong)

I agree it was wrong to compare SOAP to TCP/IP, as WS use SOAP just as one of possible bindings (at least in theory), which is usually not true about TCP/IP users.

And SOAP is positioned as a protocol by its creators (and that P in the name has something to do with protocols).

But our discussion goes away from PLT. I suggest we just agree that it was too poetic to compare SOAP for WS to TCP/IP for whatever was implied. Can we allow artistic license for programmers time to time? :)

Back to closures!

Technical purity:
Dynamic languages were designed to solve the technical problems faced by their inventors, not to address specific goals identified as part of a 'strategic plan' to influence buyers of IT solutions..

The same could be said of C and other non-dynamic lab born languages. This seems to be a direct swipe against C# and VB.

Optimizing person-time, not computer-time:
The driving forces for the creation of each major dynamic language centered on making tasks easier for people, with raw computer performance a secondary concern...

One big gotcha for using "dynamic languages" is that it places much more runtime checking onto the programmer's shoulders. Hence, my unit tests have to cover much more than intent of code, but deal with the dynamicism introduced by the language.

I've done production systems and applications in Perl and Tcl (and Python too).

Even with perl warnings turned on and "use strict" pragma engaged, I have still found a few problems (years later) in my perl code regarding variable use (doh! which context am I executing in?).

Some of my Tcl systems have crashed weeks later due to variable interpolation errors.

In the end, I am still glad I built these systems using dynamic languages (they allowed me to get something working quicker and shortened the turnaround on feedback), but in the long run I don't think they made me more productive. I was able to get something running quickly, but if I were to follow the "old school" approach: Prototype in a scripting language and then implement in a "production" (stricter) language, would I get the same benefits?

I think Ruby manages closures just fine. Python not so fine - you can do

def adderOfNToX(n):
   def addNToX(x):
      return n+x
   return addNToX

but not

def incrementer(start):
   def increment():
      start += 1
      return start
   return increment

This can be worked around, but it's still a blemish. Continations are another thing that Ruby does and Python doesn't (that is, Ruby has call/cc; obviously you can write Python in CPS if you want to).

Parent should be the comment about functional Python, not root.