4 ms·

>The nice thing about a language like Haskell, then, is that you have to be really smart to use it I'm living proof that you are mistaken. >Actually, many com

>The nice thing about a language like Haskell, then, is that you have to be really smart to use it I'm living proof that you are mistaken. >Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers If by "many" you mean "a couple", then it depends what you mean by "low end programmers". Asking for haskell is decent at weeding out people who have no interest in learning new things and improving themselves. It isn't particularly useful for filtering out people who aren't "really smart". >OO is accessible because it is much more naturalistic than FP It is interesting that you pre-suppose that is the case. My experience with teaching people programming with no prior experience is that OOP is not accessible at all, and FP comes quite naturally.

seanmcdirmid 14y ago
Asking for Haskell is actually good for weeding out most American programmers, but whatever. The point is that you'll get a better programmer if they know lots of programming language paradigms. But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part. I'm using naturalistic here as a real term related to natural language and humanistic fuzzy thinking that we seem to be born with as opposed to the logical mathematical thinking that we must learn at school. The idea that we think (or at least most of us) in terms of objects rather than formulas biases us towards object thinking when designing systems. Its sort of preverse, but I agree with you: its easier to teach FP to people with no programming experience, since you can focus on simple stateless computations. Without objects, you can't even broach the harder topics that teachers carelessly throw into 101 courses. But even if you are using the SICP, you'll see object thinking introduced in Chapter 3. But now we seem to be arguing about languages, of course you can have objects in an FPL and you can have lambdas on an OOPL. The best programmers will be able to apply both of course when applicable, and won't be ideologically biased. The not so great programmers are probably better off with OOP since that's what they'll need for their jobs, though a dose of FP can help them become better programmers.
- papsosouid 14y ago
  >But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part. Ironically, it actually indicates a severe ideological bias on your part, not theirs. The rest of your post seems like it is entirely platitudes intended to say nothing. No, people don't think in terms of objects, that is why the leaky metaphor used to teach OOP traditionally causes so much confusion, and makes OOP harder to learn than FP. Thinking in terms of FP is not thinking in terms of "formulas", and it appears you are basing all the rest of your assumptions on top of that one faulty assumption. People intuitively understand "I make a thing that transforms other things" much easier than they understand "I make my things know how to transform themselves, or maybe other things, or maybe both, but sometimes neither and I make different things to do the transforming instead, but those things are wrapped inside an "object" that doesn't represent anything for no discernable reason".
  - seanmcdirmid 14y ago
    I'm not sure I understand, do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. And I didn't even mean they have to do most of their programming in an OOPL. For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm! I definitely meant to say something, I think the platitude remark is uncalled for. People don't talk in terms of transformations, they talk in terms of instructions, recipes, responsibilities, parts and pieces, and lots of encapsulated processes. Again, check out chapter 3 of the SCIP, which you already probably know about if you are teaching programming from an FP perspective.
    - papsosouid 14y ago
      >do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. No? How would you get to that interpretation when I didn't even say anything about this theoretical person, but rather about you? >For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm! Unless you are doing programming language research, yes you can. Almost everyone already does, it is just that the only paradigm in question is imperative, rather than functional. That's not a significant barrier for the vast majority of roles, especially not PhD students. >People don't talk in terms of transformations, they talk in terms of instructions, That's the same thing. People think "beat the egg". Beating is a transformation, egg is a thing. People do not think "send the egg a message requesting it to change itself to the beaten state", which is why the OOP metaphor fails so badly. Functional programming directly maps to the normal way people think, as does traditional imperative programming. OOP does not.

seanmcdirmid 14y ago

Asking for Haskell is actually good for weeding out most American programmers, but whatever. The point is that you'll get a better programmer if they know lots of programming language paradigms. But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part. I'm using naturalistic here as a real term related to natural language and humanistic fuzzy thinking that we seem to be born with as opposed to the logical mathematical thinking that we must learn at school. The idea that we think (or at least most of us) in terms of objects rather than formulas biases us towards object thinking when designing systems. Its sort of preverse, but I agree with you: its easier to teach FP to people with no programming experience, since you can focus on simple stateless computations. Without objects, you can't even broach the harder topics that teachers carelessly throw into 101 courses. But even if you are using the SICP, you'll see object thinking introduced in Chapter 3. But now we seem to be arguing about languages, of course you can have objects in an FPL and you can have lambdas on an OOPL. The best programmers will be able to apply both of course when applicable, and won't be ideologically biased. The not so great programmers are probably better off with OOP since that's what they'll need for their jobs, though a dose of FP can help them become better programmers.

papsosouid 14y ago
>But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part. Ironically, it actually indicates a severe ideological bias on your part, not theirs. The rest of your post seems like it is entirely platitudes intended to say nothing. No, people don't think in terms of objects, that is why the leaky metaphor used to teach OOP traditionally causes so much confusion, and makes OOP harder to learn than FP. Thinking in terms of FP is not thinking in terms of "formulas", and it appears you are basing all the rest of your assumptions on top of that one faulty assumption. People intuitively understand "I make a thing that transforms other things" much easier than they understand "I make my things know how to transform themselves, or maybe other things, or maybe both, but sometimes neither and I make different things to do the transforming instead, but those things are wrapped inside an "object" that doesn't represent anything for no discernable reason".
- seanmcdirmid 14y ago
  I'm not sure I understand, do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. And I didn't even mean they have to do most of their programming in an OOPL. For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm! I definitely meant to say something, I think the platitude remark is uncalled for. People don't talk in terms of transformations, they talk in terms of instructions, recipes, responsibilities, parts and pieces, and lots of encapsulated processes. Again, check out chapter 3 of the SCIP, which you already probably know about if you are teaching programming from an FP perspective.
  - papsosouid 14y ago
    >do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. No? How would you get to that interpretation when I didn't even say anything about this theoretical person, but rather about you? >For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm! Unless you are doing programming language research, yes you can. Almost everyone already does, it is just that the only paradigm in question is imperative, rather than functional. That's not a significant barrier for the vast majority of roles, especially not PhD students. >People don't talk in terms of transformations, they talk in terms of instructions, That's the same thing. People think "beat the egg". Beating is a transformation, egg is a thing. People do not think "send the egg a message requesting it to change itself to the beaten state", which is why the OOP metaphor fails so badly. Functional programming directly maps to the normal way people think, as does traditional imperative programming. OOP does not.