4 ms·

> This is a problem with functional programming in general, it is fundamentally anti-human I would argue that the "anything goes" dynamic procedural languages

by freyrs3 13y ago

> This is a problem with functional programming in general, it is fundamentally anti-human I would argue that the "anything goes" dynamic procedural languages ( like Ruby, Python ) are far more anti-human, in that human ability to reason about large masses of code scales orders of magnitude worse than in languages that provide a strong theoretic framework for reasoning about code.

Edmond 13y ago
Sure if it was easy for people to think functionally then functional programming is without a doubt more elegant. But elegance doesn't negate the fact that the reasoning model demanded by functional programming isn't friendly to the way we think. The elegance argument is something proponents always bring up, but it misses the point. While dynamic procedural languages have their problems, I think they work for the most part, hence their success Vis-à-vis functional languages. As far as the issue of scale, that's why modular constructs as added to manage large code bases.
- freyrs3 13y ago
  I don't know how you're coming to this result, but it /is/ easy for people to think functionally. You can teach intro-CS classes in both functional and imperative styles and generally they pick up both styles at the same rate. I've seen it year after year of teaching these courses. The myth that functional programming doesn't match human thought is just flat out FUD, there's no evidence to support it. The adoption of programming languages is more influenced by economic factors than informed by solid engineering.
  - Edmond 13y ago
    I wont argue about your experience in the class room but both styles of programming have been around for about the same length of time and yet their adoption rates speak volume. We can debate this ad infinitum and probably wont come to an agreement.
    - freyrs3 13y ago
      The adoption rates do say a lot of things, but not about the claims you're making about human reasoning.
seanmcdirmid 13y ago
You should read up on flow and how it applies to programming, start here: http://en.wikipedia.org/wiki/Flow_(psychology) http://en.wikipedia.org/wiki/Flow_(psychology) The reason straight jackets lead to poor usability is that human minds are fairly diverse in the way they solve problems, and rigid constraints imposed by a tool are likely to trip up your thinking. There is a tension between flow and feedback, but its not clear at all that one dominates the other as you've stated.
- tel 13y ago
  I find dynamic languages break my flow badly by eventually losing clarity on what things are supposed to do. Haskell is annoying as he'll to begin with but eventually those constraints give very tight, very fast feedback that's very flow-compatible.
  - Edmond 13y ago
    Were you at the social innovation lab kickoff at Hopkins a few weeks back? I thought I saw a booth for Reify Health.
    - tel 13y ago
      I wasn't personally, but I another guy on the team made it. Let me know if you'd like to say hi and grab a beer!
      - Edmond 13y ago
        sure, will be in touch!
- freyrs3 13y ago
  Constraints are what prevent fallacious reasoning. It's better to have a tool/framework tell you you're wrong then not knowing about problems or believing falsehoods.
  - 13y ago
rm82 13y ago
>I would argue that the "anything goes" dynamic procedural languages ( like Ruby, Python ) are far more anti-human, Is it anti-human to be able to interact with the code, and explore what it actually does? A run-time type error is one that has real example data. The assumption we can write perfect code immediately and easily, or that a type analysis can just guide us through, is not the case. And it's breaks down even worse, when 99% of your code is interacting with systems outside of the scope of the typing system. (database servers, client-side browsers, network connections, file-systems). Dynamically typed language are good fits, when the code is mostly glue-code between multiple systems outside of the scope of any type analysis. But let's not equate functional programming with static typing. >in languages that provide a strong theoretic framework for reasoning about code. You act like many of us are ever writing complicated algorithms. We're not. We're writing simple algorithms that deal with complex structures of information. And in the few cases where the algorithms get so complicated you want your invariants to be formally proven, anything less than a full blown theory prover, will be insuffient anyway.

by freyrs3 13y ago

Edmond 13y ago

Sure if it was easy for people to think functionally then functional programming is without a doubt more elegant. But elegance doesn't negate the fact that the reasoning model demanded by functional programming isn't friendly to the way we think. The elegance argument is something proponents always bring up, but it misses the point. While dynamic procedural languages have their problems, I think they work for the most part, hence their success Vis-à-vis functional languages. As far as the issue of scale, that's why modular constructs as added to manage large code bases.

freyrs3 13y ago
I don't know how you're coming to this result, but it /is/ easy for people to think functionally. You can teach intro-CS classes in both functional and imperative styles and generally they pick up both styles at the same rate. I've seen it year after year of teaching these courses. The myth that functional programming doesn't match human thought is just flat out FUD, there's no evidence to support it. The adoption of programming languages is more influenced by economic factors than informed by solid engineering.
- Edmond 13y ago
  I wont argue about your experience in the class room but both styles of programming have been around for about the same length of time and yet their adoption rates speak volume. We can debate this ad infinitum and probably wont come to an agreement.
  - freyrs3 13y ago
    The adoption rates do say a lot of things, but not about the claims you're making about human reasoning.

seanmcdirmid 13y ago

You should read up on flow and how it applies to programming, start here: http://en.wikipedia.org/wiki/Flow_(psychology) http://en.wikipedia.org/wiki/Flow_(psychology) The reason straight jackets lead to poor usability is that human minds are fairly diverse in the way they solve problems, and rigid constraints imposed by a tool are likely to trip up your thinking. There is a tension between flow and feedback, but its not clear at all that one dominates the other as you've stated.

tel 13y ago
I find dynamic languages break my flow badly by eventually losing clarity on what things are supposed to do. Haskell is annoying as he'll to begin with but eventually those constraints give very tight, very fast feedback that's very flow-compatible.
- Edmond 13y ago
  Were you at the social innovation lab kickoff at Hopkins a few weeks back? I thought I saw a booth for Reify Health.
  - tel 13y ago
    I wasn't personally, but I another guy on the team made it. Let me know if you'd like to say hi and grab a beer!
    - Edmond 13y ago
      sure, will be in touch!
freyrs3 13y ago
Constraints are what prevent fallacious reasoning. It's better to have a tool/framework tell you you're wrong then not knowing about problems or believing falsehoods.
- 13y ago

rm82 13y ago

>I would argue that the "anything goes" dynamic procedural languages ( like Ruby, Python ) are far more anti-human, Is it anti-human to be able to interact with the code, and explore what it actually does? A run-time type error is one that has real example data. The assumption we can write perfect code immediately and easily, or that a type analysis can just guide us through, is not the case. And it's breaks down even worse, when 99% of your code is interacting with systems outside of the scope of the typing system. (database servers, client-side browsers, network connections, file-systems). Dynamically typed language are good fits, when the code is mostly glue-code between multiple systems outside of the scope of any type analysis. But let's not equate functional programming with static typing. >in languages that provide a strong theoretic framework for reasoning about code. You act like many of us are ever writing complicated algorithms. We're not. We're writing simple algorithms that deal with complex structures of information. And in the few cases where the algorithms get so complicated you want your invariants to be formally proven, anything less than a full blown theory prover, will be insuffient anyway.