2009/12/25 Carsten Führmann <c.fuhrmann@bath.ac.uk>:
I used the term "functional [programming] language" on purpose (as opposed to "functional programming style"), because of your statement
So there's not a lot of call for learning a functional programming language either.
which I feel might be wrong.
OK, I worded that badly. I think there are lots of reasons to learn functional programming, and once you're doing functional programming, then you need to learn category theory to do it well. Most of the code we've got is not functional, and the languages we work with make it hard to use higher-order functions and closures. So there's some resistance to overcome in convincing people to use functional style.
I meant that JavaScript is a functional programming language in the same way in which ML/OCaml/F#, Lisp, and Scheme are (just uglier, slower, and running in a sandbox called "browser"). These are considered functional languages by many, and their categorical semantics has been studied. (Well, the semantics of idealized versions.) JavaScript is just riddled with some syntactic and semantic ugliness that makes it unattractive for formal study, but that doesn't make it un-functional in principle.
The syntax of those languages certainly encourages functional composition over imperative programming, and they make it easy to construct closures and higher-order functions. However, none of them are purely functional like Haskell. I suppose I don't see the point of making the distinction between functional and imperative unless you really can't cause side-effects.
I'm not sure what you mean by "the whole monad business does not apply". There are lots of monads, each doing something different. There are several monadic parsers I know of in JavaScript, for instance. Here's a monad for making JavaScript be lazily evaluated instead of eager: function e(x) { return function() { return x; } } function m(x, y) { return function () { return x()(y()); } }
Doesn't very fact that JavaScript allows you to write down the delaying monad give away its functional-language nature? And doesn't
I could write down the delaying monad in Java, too, but it would be much larger. If the only feature you require of a functional language is that the syntax makes it *possible* to create closures, then nearly any programming language will fit the bill. If it has to be easy, then Java and C/C++ are not functional, while Scheme, ML, JavaScript and Perl are. On the other hand, if you say that it should be hard to use the imperative style in a functional language, then Scheme and ML are functional, while Perl and JavaScript are not.
the existence of monadic parsers in JavaScript underpin that it might be beneficial for real-life programmers to learn some functional programming?
Sure. See above.
By "monad business" I meant using monads to introduce side effects to lazy languages like Haskell, I could have been clearer there.
Categorically, your monad is of a different kind, as I shall now sketch. (Just in case anyone is interested.)
Thanks, that _was_ interesting! I suppose what I'm really looking for is cool algorithms like the one described in Backhouse's paper "Fusion on Languages" (thanks, Neel!) where they either wouldn't have been discovered without category theory, or where category theory is the only decent way to understand the algorithm.
Happy holidays, Carsten
Thanks! To you, too. -- Mike Stay - metaweta@gmail.com http://math.ucr.edu/~mike http://reperiendi.wordpress.com [For admin and other information see: http://www.mta.ca/~cat-dist/ ]