The other thing I think is worth considering in a move to Clojure is how different functional thinking is. I mean, if you're used to moving between C and Perl and Python and PHP and Java and Javascript and so on, you're used to language transitions within more or less the same paradigm. It feels like a categorically different problem to try to transition a team from one of those to a functional language.
They lay out a couple of algorithms in an imperative style, and then gradually morph them into a functional style. It's pretty wild: you go from a story, "do this, then do this, then do this" to a math problem: "your answer is a list composed of f() of g() of h() of another list". (Unfortunately you only get snippets from that link -- it's worth the money to get the whole thing if you're interested.)
Anyway, having followed through their examples and done some of my own Clojure programming, I ended up not so convinced that people who are good at solving story-style imperative problems will necessarily be good at solving math-style functional problems. It felt like a different part of my brain.
This is not at all a reason not to dabble with functional languages, just a potential pitfall to be aware of if you're thinking of bringing a whole team over. And maybe I'm overstating it? I haven't dabbled too much myself.
Anyway, having followed through their examples and done some of my own Clojure programming, I ended up not so convinced that people who are good at solving story-style imperative problems will necessarily be good at solving math-style functional problems. It felt like a different part of my brain.
When you're coming to a new paradigm which is completely different from what you're currently using, then of course it will initially feel hard/different and that you're using a different part of your brain. That doesn't necessarily mean that it's harder for you to program in a functional style, it just means that you're more experienced in imperative programming.
"C and Perl and Python and PHP and Java and Javascript and so on, ... It feels like a categorically different problem to try to transition a team from one of those to a functional language."
I just have to throw a flag here and point out that Javascript is also a functional language. With Javascript you can declare functions as variables, pass functions as arguments to other functions, return functions as the result of other functions, and use them as part of a data structure. Javascript is much closer to Scheme than it is to a C paradigm.
Well, you can pass around function pointers, return function pointers, and store function pointers in data structures in C, too. You can also use closures - a closure is just a (function pointer, struct with its closure values) struct. Sure, OCaml, Scheme, and company box the pair for you, garbage collect it, and don't make you flatten your code into a single file-level scope, but the difference between Javascript and C isn't as big as you think.
Javascript is kinda sorta maybe functional if you look at it right, but it's still mostly the same imperative/object-oriented mishmash as Java, Python, or Ruby.
Indeed. I'd certainly rather be able to nest functions, but C became a lot more powerful to me after I learned how to compile a bunch of high-level features to it. (Your 'ichbins' helped, by the way. That, LiSP, and some SML papers.) I'd still rather automate much of the heavy lifting, of course.
I'm weirded out by the idea of writing CPS-transformed code by hand for node.js, but apparently people like it? Perhaps it's something similar.
The thing I don't get about node.js is that it used to have a promise abstraction and they dropped it to go callback-only. I guess the abstraction leaked, in a language not built around it?
I like to imagine Node's success comes from bringing some of E's insights to a community just ready to use them, and if the cost is manual CPS, apparently it's not too high.
(Relevant E theory at http://erights.org/elib/concurrency/overview.html )
There is a distinct difference between languages designed around the functional paradigm (Haskell, lisps etc), and languages that support the functional paradigm (python, javascript etc). Most javascript code is imperative, not functional, and it would be disingenuous to say that there is not a difference in the way of thinking when writing in lisp, and when writing in javascript.
> With Javascript you can declare functions as variables, pass functions as arguments to other functions, return functions as the result of other functions, and use them as part of a data structure.
I'm pretty sure you can do all of those things with function pointers in C. void (*func)(void), for example.
"With Javascript you can declare functions as variables, pass functions as arguments to other functions, return functions as the result of other functions, and use them as part of a data structure. "
I'm thinking in particular of this section from O'Reilly's Clojure book: http://books.google.com/books?id=I8KdEKceCHAC&ots=wNiLN6...
They lay out a couple of algorithms in an imperative style, and then gradually morph them into a functional style. It's pretty wild: you go from a story, "do this, then do this, then do this" to a math problem: "your answer is a list composed of f() of g() of h() of another list". (Unfortunately you only get snippets from that link -- it's worth the money to get the whole thing if you're interested.)
Anyway, having followed through their examples and done some of my own Clojure programming, I ended up not so convinced that people who are good at solving story-style imperative problems will necessarily be good at solving math-style functional problems. It felt like a different part of my brain.
This is not at all a reason not to dabble with functional languages, just a potential pitfall to be aware of if you're thinking of bringing a whole team over. And maybe I'm overstating it? I haven't dabbled too much myself.