3 ms·

I've known engineers who would swear up, down, and center that using Haskell or Lisp or Clojure made them more productive. More features, better, and faster. F

by Kalium 4y ago

I've known engineers who would swear up, down, and center that using Haskell or Lisp or Clojure made them more productive. More features, better, and faster. From the outside, I didn't see any evidence of this. The people who were better and more experienced engineers tended to produce more, better, and faster. I saw that they were happier using the tools of choice. As far as I could tell the supposed extra productivity over Rails or some other modern framework for the task at hand was largely illusory. On the one hand, happier engineers is good. On the other hand, code in relatively obscure languages is more difficult to find people to maintain and libraries are less likely to be kept patched by the community. It's a tradeoff. I wouldn't say one is better. The primary gain from Lisp and similar is, in my experience, not that it's useful for writing software. It's that learning a different approach teaches you new ways to attack problems. Sometimes those are useful.

rad_gruchalski 4y ago
> From the outside, I didn't see any evidence of this. The people who were better and more experienced engineers tended to produce more, better, and faster. I saw that they were happier using the tools of choice. As far as I could tell the supposed extra productivity over Rails or some other modern framework for the task at hand was largely illusory. I don’t think the claim is that one has to use those older technologies exclusively. I read the GP’s comment as that the knowledge one gains by learning those older technologies gives one more tools in their bag when using modern technology. > The primary gain from Lisp and similar is, in my experience, not that it's useful for writing software. It's that learning a different approach teaches you new ways to attack problems. Sometimes those are useful. Exactly. An example: trying to learn functional programming? Erlang will force one into that mindset. It is natural to spot mapping, folding, flattening in any other language later on. Working with local data, or state machines becomes a habit because there’s no other way of doing things in Erlang. That knowledge is directly applicable in any other language.
eyelidlessness 4y ago
> The primary gain from Lisp and similar is, in my experience, not that it's useful for writing software. It's that learning a different approach teaches you new ways to attack problems. Sometimes those are useful. This exactly describes my experience with Clojure. Sure, I learned “functional programming” which was a “different paradigm”, but at the end of the day what I learned was how to reason about: 1. Whether some bit of state is intrinsic, not strictly necessary but it is highly convenient, or neither of those. (The highly convenient case in Clojure is mostly a reference to Transients[1], which I don’t think I ever used. But the concept has been incredibly valuable when transferring what I’d learned to more imperative languages.) 2. There are correct and obvious function boundaries even for quite a lot of domain specific code, and they usually become evident while you work if the previous point is applied judiciously. 3. Some general purpose abstractions are so self-evidently useful that adopting them is never premature. (Here I’m thinking of what Clojure abstracts as `seq` and the enormous set of functions which operate on `seq`-conforming collection types. Other FP languages similarly bring their own wealth of broadly applicable abstractions.) 4. Many, maybe most, functions have a correct parameter order, which is the order you’d use for true lambdas. Once learned, it can almost always be applied subconsciously. 5. Metaprogramming is good, actually, if you have a good reason to do it. And having a good foundation for metaprogramming is invaluable even if its value is hard to elucidate. (Macros, of course. But I’d give my figurative left kidney to have time to explore the kinds of problems I could potentially solve with Racket’s language-oriented features.) For another day or at least a later comment, 6. Lack of static types in most lisps hilariously undermines each one of the points above. 1: https://clojure.org/reference/transients https://clojure.org/reference/transients

by Kalium 4y ago

rad_gruchalski 4y ago

> From the outside, I didn't see any evidence of this. The people who were better and more experienced engineers tended to produce more, better, and faster. I saw that they were happier using the tools of choice. As far as I could tell the supposed extra productivity over Rails or some other modern framework for the task at hand was largely illusory. I don’t think the claim is that one has to use those older technologies exclusively. I read the GP’s comment as that the knowledge one gains by learning those older technologies gives one more tools in their bag when using modern technology. > The primary gain from Lisp and similar is, in my experience, not that it's useful for writing software. It's that learning a different approach teaches you new ways to attack problems. Sometimes those are useful. Exactly. An example: trying to learn functional programming? Erlang will force one into that mindset. It is natural to spot mapping, folding, flattening in any other language later on. Working with local data, or state machines becomes a habit because there’s no other way of doing things in Erlang. That knowledge is directly applicable in any other language.

eyelidlessness 4y ago

> The primary gain from Lisp and similar is, in my experience, not that it's useful for writing software. It's that learning a different approach teaches you new ways to attack problems. Sometimes those are useful. This exactly describes my experience with Clojure. Sure, I learned “functional programming” which was a “different paradigm”, but at the end of the day what I learned was how to reason about: 1. Whether some bit of state is intrinsic, not strictly necessary but it is highly convenient, or neither of those. (The highly convenient case in Clojure is mostly a reference to Transients[1], which I don’t think I ever used. But the concept has been incredibly valuable when transferring what I’d learned to more imperative languages.) 2. There are correct and obvious function boundaries even for quite a lot of domain specific code, and they usually become evident while you work if the previous point is applied judiciously. 3. Some general purpose abstractions are so self-evidently useful that adopting them is never premature. (Here I’m thinking of what Clojure abstracts as `seq` and the enormous set of functions which operate on `seq`-conforming collection types. Other FP languages similarly bring their own wealth of broadly applicable abstractions.) 4. Many, maybe most, functions have a correct parameter order, which is the order you’d use for true lambdas. Once learned, it can almost always be applied subconsciously. 5. Metaprogramming is good, actually, if you have a good reason to do it. And having a good foundation for metaprogramming is invaluable even if its value is hard to elucidate. (Macros, of course. But I’d give my figurative left kidney to have time to explore the kinds of problems I could potentially solve with Racket’s language-oriented features.) For another day or at least a later comment, 6. Lack of static types in most lisps hilariously undermines each one of the points above. 1: https://clojure.org/reference/transients https://clojure.org/reference/transients