3 ms·

Interesting claim implied here, and maybe some truth in it, that there are highbrow code cultures that attract 'better' types of hacker to the club. Personally

Interesting claim implied here, and maybe some truth in it, that there are highbrow code cultures that attract 'better' types of hacker to the club. Personally I've never felt ashamed to roll up my sleeves and get some oil in my beard with C++. Perl, Python or really filthy Bash scripting. But having learned Lisp (SICP) back in the 80s, It does sometimes feel like I took Latin and Greek at prep-school, and ever since have been slumming it with my working class coder pals. Total geek snobbery for sure. But is there anything in it? Please say no.

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
rad_gruchalski 4y ago
I wouldn’t call it snobbery. I consider Lisp, Prolog, and Erlang to be the three most profound programming languages of all time. Maybe they lack some utility for certain problem domains, maybe they don’t have vast ecosystems today, but all three teach how to arrive at solutions in the most logical, pure, functional way, without using global state. This knowledge is then applicable to any other programming language.

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

rad_gruchalski 4y ago

I wouldn’t call it snobbery. I consider Lisp, Prolog, and Erlang to be the three most profound programming languages of all time. Maybe they lack some utility for certain problem domains, maybe they don’t have vast ecosystems today, but all three teach how to arrive at solutions in the most logical, pure, functional way, without using global state. This knowledge is then applicable to any other programming language.