On Mon, 01 Feb 2010 14:35:57 -0800, Jonathan Gardner wrote: >> If it was common-place to use Curried functions and partial application in >> Python, you'd probably prefer "f a b c" to "f(a)(b)(c)" as well. > > That's just the point. It isn't common to play with curried functions > or monads or anything like that in computer science today. Yes, > Haskell exists, and is a great experiment in how such a language could > actually work. But at the same time, you have to have a brain the size > of the titanic to contain all the little details about the language > before you could write any large-scale application.
No, not really. Haskell (and previously ML) are often used as introductory languages in Comp.Sci. courses (at least in the UK). You don't need to know the entire language before you can use any of it (if you did, Python would be deader than a certain parrot; Python's dark corners are *really* dark). The lack of mutable state (or at least, the isolation of it within monads) eliminates a lot of potential problems. How many Python novices get tripped up by "x = y = [] ; x.append(...); # now y has changed"? And in spite of the category theory behind monads, Haskell's I/O system really isn't any more complex than that of any other language, beyond the constraint that you can only use it in "procedures" (i.e. something returning an IO instance), not in functions. Which for the most part, is a net win, as it forces you to maintain a reasonable degree of structure. Now, if you actually want to use everything the language has to offer, you can run into some fairly hairy error messages. But then I've found that to be a common problem with generic programming in general. E.g. error messages relating to the C++ STL can be quite insanely complex (particularly when the actual error is "there are so many nested templates that the mangled function name is longer than the linker can handle" and it's trying to explain *where* the error is). -- http://mail.python.org/mailman/listinfo/python-list
