7 ms·

OP strikes me as someone who is trying to position himself as a "moderate" but who is mistaking a caricaturized extreme (<0.25%) for "functional programmers". H

OP strikes me as someone who is trying to position himself as a "moderate" but who is mistaking a caricaturized extreme (<0.25%) for "functional programmers". Honestly, I like FP extremists better than their OOP cargo-cult counterparts, who have the same smugness but are usually better, in most companies, at getting managerial blessing. In many companies, OOP acolytes glow in the managerial sun like Dudley Dursley, despite the general crappitude of their ideas. "Functional programming" in the real world isn't about dogmatically eliminating mutable state. It's about managing it. It's about modularity. It's not far from the original vision behind OOP-- before it got taken away by the wrong crowd-- which was that when complexity is inevitable, it should be encapsulated behind simpler interfaces. For example, SQL is append-only (as functional as one can get over a growing knowledge base) if you never use DELETE or UPDATE. The inner guts of SQL are not "purely functional"-- caching and indexing cause internal state changes, for performance reasons-- but the interface is. I don't even know what endofunctors are. If it's relevant to my job, I'll learn about them, but I care more about writing good software than reciting category-theory arcana. I'm sure it's important (especially as an inspiration for design) for some people, but you don't need to know them to do functional programming. Not even close. And I was already a productive functional programmer (in Ocaml and Lisp) before I even knew what monads were.

demian 15y ago
That's the thing, FP is not only a great model for writing a CRUD or any kind data-processing system, but also things like Haskell's type system makes it incredibly powerfull to "hack away" code while controlling complexity. And both are things that FP extremists doesn't seem to like to promote. The "scientific" culture seems to revolve around using it for numerical computations, while trying to get as close as doing "formal proofs" as possible.
moldbug 15y ago
The problem is that the best, most expressive functional languages (lookin at ya Haskell) are mathematically based on this theory. If you want to use these languages, you have a choice between (a) learning the theory, and (b) not fully understanding the tool you're using. Both have significant downsides from a UI perspective. Learn You A Haskell is a classic case of (b). As a tutorial it's completely successful, and how? It tells you that you can learn Haskell without learning PL theory. It also neglects to tell you how to debug you a Haskell (without learning PL theory). But once you type in the examples, I'm sure you can figure it out. A lot of people are smart enough to program on top of mysterious black boxes. That is: a lot of people are smart enough to work past this UI problem. Moreover, the smartest people can learn Haskell by rote and then gradually, through intuition and experience, learn to grok the black box. This is not to say, I think, that it's not a problem. Of course you could just learn the theory. I'd say anyone who can graduate with a math degree from an Ivy-class university can do it. Is you a member of this set? Find out by reading the Wikipedia page for Hindley-Milner: http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner I'm sure there are simpler explanations of H-M (Haskell's type inference algorithm). But they're not on Wikipedia. I sent this link to a friend of mine with a PhD in astrophysics from Caltech. "Which seems easier to you?" I asked. "This, or special relativity?" You can probably imagine his response. So, wanted: a higher-order typed functional language whose type system is easier to understand than special relativity. Or of course a proof that such a device is impossible :-)
- lincolnq 15y ago
  Great analogy. It appears that SR and HM both benefit from great teachers. I learned HM in a couple weeks of an undergraduate course, and that knowledge has continued to pay off. A good introduction can be found in Krishnamurthi's free book PLAI in the chapters on types. http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/ http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/200...
- michaelochurch 15y ago
  Monads are intellectually difficult at first, because it's hard to see how such disparate concepts (IO vs. List vs. Random vs. Async) so neatly follow the same pattern. I personally find it more useful to start by "playing with" the black-box system, and then back-filling in theoretical knowledge if I need to do so. I find that, once I understand the motivation for the problem, the mathematics itself is pretty easy to understand. Math isn't complex or hard. It's simple. The hard part is figuring out the best way to provide the tools it provides.
  - moldbug 15y ago
    Sure. I'm not saying that solving the hard problem of learning a black-box system is either impossible, or even necessarily un-fun. I'm just saying that there is no such problem when it comes to learning, say, PHP. Or any other "townie" language. So is the imposition of this arcane body of knowledge, "PL theory," whose DNA obviously originates not just in the academy but in the freakin' math department, and which has no relationship to any other body of knowledge commonly held or needed by the working programmer however 31337, essential to HOT-FP? Or could it be in some way dispensed with? If so, that would sure help out the mules on the way home, so to speak...
    - asciilifeform 15y ago
      I would say that the FP people (and yes, this includes you) are solving the wrong problem. Mathematical formalism is not a substitute for understandability. Where is the mathematical proof that your doorknob turns? No interesting property of a computer system (vs. a single algorithm) can ever be provable in the mathematical sense - because said proof, if true, can be construed as a program in its own right - and where is the proof of its correctness - which is to say, its consistency and correspondence to actual human wants? A. Perlis put this concisely: "You cannot transition from the informal to the formal by formal means." Switching between alternate mathematical models of computation will not give us better intelligence amplifiers (what the personal computer is really meant to become.) Instead, we need systems which cut the operator's OODA loop delay as close to zero as possible: http://www.loper-os.org/?p=202 http://www.loper-os.org/?p=202 Any idiot can use modelling clay. Or a child's set of blocks. These objects have no hidden state, allow for no inconsistent states, posses no "compile" switch. One can build a computer which behaves in the same way. And no mathematical wankery need be involved. Lustrate the squiggly crowd! Half a century of stagnation in computing is enough: “Throughout my life I have known people who were born with silver spoons in their mouths. You know the ones: grew up in a strong community, went to good public or private schools, were able to attend a top undergraduate school like Harvard or Caltech, and then were admitted to the best graduate schools. Their success was assured, and it seemed to come easy for them. These are the people— in many, but certainly not in all cases—who end up telling the rest of us how to go about our business in computing. They figure out the theories of computation and the semantics of our languages; they define the software methodologies we must use. It’s good to have their perspective, but it’s only a perspective, not one necessarily gained by working in the trenches or watching the struggles of people grappling with strange concepts. Worse, watching their careers can discourage the rest of us, because things don’t come easy for us, and we lose as often or more often than we win. And discouragement is the beginning of failure. Sometimes people who have not had to struggle are smug and infuriating. This is my attempt to fight back. Theirs is a proud story of privilege and success. Mine is a story of disappointment and failure; I ought to be ashamed of it, and I should try to hide it. But I learned from it, and maybe you can, too.” - Richard P. Gabriel, “A Personal Narrative: Journey to Stanford (Patterns of Software)

demian 15y ago

That's the thing, FP is not only a great model for writing a CRUD or any kind data-processing system, but also things like Haskell's type system makes it incredibly powerfull to "hack away" code while controlling complexity. And both are things that FP extremists doesn't seem to like to promote. The "scientific" culture seems to revolve around using it for numerical computations, while trying to get as close as doing "formal proofs" as possible.

moldbug 15y ago

The problem is that the best, most expressive functional languages (lookin at ya Haskell) are mathematically based on this theory. If you want to use these languages, you have a choice between (a) learning the theory, and (b) not fully understanding the tool you're using. Both have significant downsides from a UI perspective. Learn You A Haskell is a classic case of (b). As a tutorial it's completely successful, and how? It tells you that you can learn Haskell without learning PL theory. It also neglects to tell you how to debug you a Haskell (without learning PL theory). But once you type in the examples, I'm sure you can figure it out. A lot of people are smart enough to program on top of mysterious black boxes. That is: a lot of people are smart enough to work past this UI problem. Moreover, the smartest people can learn Haskell by rote and then gradually, through intuition and experience, learn to grok the black box. This is not to say, I think, that it's not a problem. Of course you could just learn the theory. I'd say anyone who can graduate with a math degree from an Ivy-class university can do it. Is you a member of this set? Find out by reading the Wikipedia page for Hindley-Milner: http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner I'm sure there are simpler explanations of H-M (Haskell's type inference algorithm). But they're not on Wikipedia. I sent this link to a friend of mine with a PhD in astrophysics from Caltech. "Which seems easier to you?" I asked. "This, or special relativity?" You can probably imagine his response. So, wanted: a higher-order typed functional language whose type system is easier to understand than special relativity. Or of course a proof that such a device is impossible :-)

lincolnq 15y ago
Great analogy. It appears that SR and HM both benefit from great teachers. I learned HM in a couple weeks of an undergraduate course, and that knowledge has continued to pay off. A good introduction can be found in Krishnamurthi's free book PLAI in the chapters on types. http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/ http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/200...
michaelochurch 15y ago
Monads are intellectually difficult at first, because it's hard to see how such disparate concepts (IO vs. List vs. Random vs. Async) so neatly follow the same pattern. I personally find it more useful to start by "playing with" the black-box system, and then back-filling in theoretical knowledge if I need to do so. I find that, once I understand the motivation for the problem, the mathematics itself is pretty easy to understand. Math isn't complex or hard. It's simple. The hard part is figuring out the best way to provide the tools it provides.
- moldbug 15y ago
  Sure. I'm not saying that solving the hard problem of learning a black-box system is either impossible, or even necessarily un-fun. I'm just saying that there is no such problem when it comes to learning, say, PHP. Or any other "townie" language. So is the imposition of this arcane body of knowledge, "PL theory," whose DNA obviously originates not just in the academy but in the freakin' math department, and which has no relationship to any other body of knowledge commonly held or needed by the working programmer however 31337, essential to HOT-FP? Or could it be in some way dispensed with? If so, that would sure help out the mules on the way home, so to speak...
  - asciilifeform 15y ago
    I would say that the FP people (and yes, this includes you) are solving the wrong problem. Mathematical formalism is not a substitute for understandability. Where is the mathematical proof that your doorknob turns? No interesting property of a computer system (vs. a single algorithm) can ever be provable in the mathematical sense - because said proof, if true, can be construed as a program in its own right - and where is the proof of its correctness - which is to say, its consistency and correspondence to actual human wants? A. Perlis put this concisely: "You cannot transition from the informal to the formal by formal means." Switching between alternate mathematical models of computation will not give us better intelligence amplifiers (what the personal computer is really meant to become.) Instead, we need systems which cut the operator's OODA loop delay as close to zero as possible: http://www.loper-os.org/?p=202 http://www.loper-os.org/?p=202 Any idiot can use modelling clay. Or a child's set of blocks. These objects have no hidden state, allow for no inconsistent states, posses no "compile" switch. One can build a computer which behaves in the same way. And no mathematical wankery need be involved. Lustrate the squiggly crowd! Half a century of stagnation in computing is enough: “Throughout my life I have known people who were born with silver spoons in their mouths. You know the ones: grew up in a strong community, went to good public or private schools, were able to attend a top undergraduate school like Harvard or Caltech, and then were admitted to the best graduate schools. Their success was assured, and it seemed to come easy for them. These are the people— in many, but certainly not in all cases—who end up telling the rest of us how to go about our business in computing. They figure out the theories of computation and the semantics of our languages; they define the software methodologies we must use. It’s good to have their perspective, but it’s only a perspective, not one necessarily gained by working in the trenches or watching the struggles of people grappling with strange concepts. Worse, watching their careers can discourage the rest of us, because things don’t come easy for us, and we lose as often or more often than we win. And discouragement is the beginning of failure. Sometimes people who have not had to struggle are smug and infuriating. This is my attempt to fight back. Theirs is a proud story of privilege and success. Mine is a story of disappointment and failure; I ought to be ashamed of it, and I should try to hide it. But I learned from it, and maybe you can, too.” - Richard P. Gabriel, “A Personal Narrative: Journey to Stanford (Patterns of Software)