4 ms·

To be fair, those become simpler once you approach things from a constructivist-theoretical point of view. So it's a matter of which you're familiar with. (Damm

by rplacd 14y ago

To be fair, those become simpler once you approach things from a constructivist-theoretical point of view. So it's a matter of which you're familiar with. (Dammnit, beaten!) But I have a big problem with any statement of the form "reasons not to learn X". (Or, for that matter, the idea that imperative and functional styles are two different beasts, and neither the twain shall meet.)

_delirium 14y ago
I do think which you've spent more time with has a big influence, but I'm not sure it's purely an issue of where you started in programming. Procedural programming, especially for beginners, benefits from fairly widespread familiarity with procedures in a more general sense: recipes, flow charts, mechanical devices, job protocols, assembly lines. So procedural programming can seem natural as just the computer version of these existing ideas, whereas functional programming tends to attach itself more to a mathematical rather than mechanical description of the world.
- rplacd 14y ago
  You're right - we start with that analogy, presumably because it's more concrete. But I'd argue that basis is only popular by convention (and in any case, it breaks down soon enough) - SICP-like intro courses start at expressions combining, being abstracted, simplifying and evaluating, and steal intuition from (and here you're very right) math. They do just fine - I think that's just as accessible; it's just that the former is preferred because it's less abstract. (And, to be fair, I'd rather spend my time learning how programming a computer is different from what I already know - the point, in the end, is learn what programming is all about, and not just what it's like.) But what was the original point? Programming can be just as abstract or as nitty-gritty as you like, and I'd rather have a feel for the breadth of programming, and more bits and pieces in my toolkit of expression, than simply limiting myself just because I won't be earning big bucks directly from it.

by rplacd 14y ago

_delirium 14y ago

I do think which you've spent more time with has a big influence, but I'm not sure it's purely an issue of where you started in programming. Procedural programming, especially for beginners, benefits from fairly widespread familiarity with procedures in a more general sense: recipes, flow charts, mechanical devices, job protocols, assembly lines. So procedural programming can seem natural as just the computer version of these existing ideas, whereas functional programming tends to attach itself more to a mathematical rather than mechanical description of the world.

rplacd 14y ago
You're right - we start with that analogy, presumably because it's more concrete. But I'd argue that basis is only popular by convention (and in any case, it breaks down soon enough) - SICP-like intro courses start at expressions combining, being abstracted, simplifying and evaluating, and steal intuition from (and here you're very right) math. They do just fine - I think that's just as accessible; it's just that the former is preferred because it's less abstract. (And, to be fair, I'd rather spend my time learning how programming a computer is different from what I already know - the point, in the end, is learn what programming is all about, and not just what it's like.) But what was the original point? Programming can be just as abstract or as nitty-gritty as you like, and I'd rather have a feel for the breadth of programming, and more bits and pieces in my toolkit of expression, than simply limiting myself just because I won't be earning big bucks directly from it.