4 ms·

It is somewhat of a shame that learning curve plays such a significant role for career programmers. You would expect that people that spend years and years wor

by Peaker 15y ago

It is somewhat of a shame that learning curve plays such a significant role for career programmers. You would expect that people that spend years and years working with their tools would be willing to put a few weeks or months into learning their most important tool: the programming language. It seems most programmers get frustrated and abandon learning of different programming paradigms very quickly.

Jach 15y ago
Maybe most programmers who bother to look up different paradigms. My experience is that most programmers overall aren't even aware of different paradigms, let alone that things could be better: they're taught what they're taught in school or at home and don't move beyond. I've heard the phrase "Well if you know C++ you know it all" at least three times.
- danieldk 15y ago
  You must have never done any meta-programming in C++ ;). It's pretty much a functional language. Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.
  - deleted 15y ago
    [deleted]
  - dtbx 15y ago
    Yeah, but the syntax and the verbosity hides your aim. In the obscure years previous to c++11, meta-programming in c++ would have required a language lawyer. In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.
    - danieldk 15y ago
      In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way. Unless you want if-then-else in the do notation (yes, I know that there is a GHC extension for this), disagree with its whitespace rules, or like record syntax (which subsequently pollutes your namespace). Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. Yeah, but the syntax and the verbosity hides your aim. Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight.
      - eru 15y ago
        > Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. That's why it's called point-less style. It's too seductive. > Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight. In a sense. But at least Haskell is parseable. And overloading is only done in a very systematic manner. So if something fishy's going on, you at least see strange symbols you haven't seen before.
  - Jach 15y ago
    > You must have never done any meta-programming in C++ ;). It's pretty much a functional language. I've done enough to scream in terror and run towards a Lisp should anyone suggest such an awful thing! I think there's a huge, huge gap between your 'pretty much a functional language' and standard 'a functional language' [with proper meta-programming capabilities].
stonemetal 15y ago
Not to be to contrarian but until I see proof to the contrary I think Norvig put said it best: In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you;
- thesz 15y ago
  Architecture heavily depends on the language. You have to make different choices for C++ than for Java, not mentioning Haskell. Also, I think that comma before "the right" in Norvig statements means logical AND. If we rewrite that statement it will look like that: if you have the right overall architecture AND the right team of programmers AND the right development process that allows for rapid development with continuous improvement, then many languages will work for you. I think it is too many AND's here. In most realistic situations you cannot have such luxury. Also, choice of Haskell (or similar language) allows you to address at least two points from Norvig statement: the right team and right development process. Those who learned and applied Haskell almost cannot form the wrong team. Almost - as we cannot rule out failure completely. The right development process is almost ensured by strong type system. Type systems like Haskell's can be viewed as a tool to spread requirement changes through complete program. (that's why it is seemed hard to introduce or change a constructor in a data type) So all in all I think that languages make a difference here. For many languages you should fulfill those three points, for some languages those points fulfill themselves.
  - eru 15y ago
    As much as I loath Java and co, I have to give them that their mature development tools make up a bit for their weakness. I.e. in Haskell you make a change to a type and propagate it, until the compiler stops complaining. In Java you click some `refactor' button in your IDE, and your changes will propagate through the code base automatically. That's less of a comment on the languages, since Haskell will probably grow better tools some day, but more a comment on the relative stages of maturity.
Someone 15y ago
The problem is not why one "would be willing to put a few weeks or months into learning their most important tool", but why one would be willing to put a few weeks or months into learning the next silver bullet, and repeat that two or three times a year. Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the whole domain. Instead, language evolution typically is a matter of two steps forward, ten sideways, and one step back. Also, experience tells that new languages often get overhyped as making only forward steps. Given that, it does not make sense to switch horses too often, or one would be forever learning, and never be productive.
- Peaker 15y ago
  I don't think anyone has been advocating any programming language as the "next silver bullet". Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn. Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who knows Python and does not think learning Perl/Ruby/Lua will teach him anything substantial/new. But I think even a cursory look at Haskell will remove any doubt about whether it contains novel ideas to learn. Learning about programming languages enriches you as a programmer, and I can't imagine spending a few weeks learning novel languages and the reward not far-outweighing the costs.
  - SwellJoe 15y ago
    "Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn." The question then raised is whether any given new programming language or paradigm will bring that 5% productivity gain, and in what circumstances. If it were an obvious and clear path to greater productivity, and superior to other paths to greater productivity (such as spending more time learning your editor and shell and environment, or learning about a new library in the language your work is written in, or learning new tricks in your current language), no one would hesitate to increase their productivity in this way. You seem to assume that people are choosing not to become more productive by opting not to switch to Haskell or learn Haskell or something about Haskell. There are thousands of programming languages. Shall we learn them all to become five thousand percent more productive? I'm not opposed to learning new languages. I think folks should tinker. But, I don't think it is provable that learning Haskell will make you more productive than other activities.

by Peaker 15y ago

Jach 15y ago

Maybe most programmers who bother to look up different paradigms. My experience is that most programmers overall aren't even aware of different paradigms, let alone that things could be better: they're taught what they're taught in school or at home and don't move beyond. I've heard the phrase "Well if you know C++ you know it all" at least three times.

danieldk 15y ago
You must have never done any meta-programming in C++ ;). It's pretty much a functional language. Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.
- deleted 15y ago
  [deleted]
- dtbx 15y ago
  Yeah, but the syntax and the verbosity hides your aim. In the obscure years previous to c++11, meta-programming in c++ would have required a language lawyer. In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.
  - danieldk 15y ago
    In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way. Unless you want if-then-else in the do notation (yes, I know that there is a GHC extension for this), disagree with its whitespace rules, or like record syntax (which subsequently pollutes your namespace). Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. Yeah, but the syntax and the verbosity hides your aim. Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight.
    - eru 15y ago
      > Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. That's why it's called point-less style. It's too seductive. > Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight. In a sense. But at least Haskell is parseable. And overloading is only done in a very systematic manner. So if something fishy's going on, you at least see strange symbols you haven't seen before.
- Jach 15y ago
  > You must have never done any meta-programming in C++ ;). It's pretty much a functional language. I've done enough to scream in terror and run towards a Lisp should anyone suggest such an awful thing! I think there's a huge, huge gap between your 'pretty much a functional language' and standard 'a functional language' [with proper meta-programming capabilities].

stonemetal 15y ago

Not to be to contrarian but until I see proof to the contrary I think Norvig put said it best: In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you;

thesz 15y ago
Architecture heavily depends on the language. You have to make different choices for C++ than for Java, not mentioning Haskell. Also, I think that comma before "the right" in Norvig statements means logical AND. If we rewrite that statement it will look like that: if you have the right overall architecture AND the right team of programmers AND the right development process that allows for rapid development with continuous improvement, then many languages will work for you. I think it is too many AND's here. In most realistic situations you cannot have such luxury. Also, choice of Haskell (or similar language) allows you to address at least two points from Norvig statement: the right team and right development process. Those who learned and applied Haskell almost cannot form the wrong team. Almost - as we cannot rule out failure completely. The right development process is almost ensured by strong type system. Type systems like Haskell's can be viewed as a tool to spread requirement changes through complete program. (that's why it is seemed hard to introduce or change a constructor in a data type) So all in all I think that languages make a difference here. For many languages you should fulfill those three points, for some languages those points fulfill themselves.
- eru 15y ago
  As much as I loath Java and co, I have to give them that their mature development tools make up a bit for their weakness. I.e. in Haskell you make a change to a type and propagate it, until the compiler stops complaining. In Java you click some `refactor' button in your IDE, and your changes will propagate through the code base automatically. That's less of a comment on the languages, since Haskell will probably grow better tools some day, but more a comment on the relative stages of maturity.

Someone 15y ago

The problem is not why one "would be willing to put a few weeks or months into learning their most important tool", but why one would be willing to put a few weeks or months into learning the next silver bullet, and repeat that two or three times a year. Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the whole domain. Instead, language evolution typically is a matter of two steps forward, ten sideways, and one step back. Also, experience tells that new languages often get overhyped as making only forward steps. Given that, it does not make sense to switch horses too often, or one would be forever learning, and never be productive.

Peaker 15y ago
I don't think anyone has been advocating any programming language as the "next silver bullet". Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn. Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who knows Python and does not think learning Perl/Ruby/Lua will teach him anything substantial/new. But I think even a cursory look at Haskell will remove any doubt about whether it contains novel ideas to learn. Learning about programming languages enriches you as a programmer, and I can't imagine spending a few weeks learning novel languages and the reward not far-outweighing the costs.
- SwellJoe 15y ago
  "Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn." The question then raised is whether any given new programming language or paradigm will bring that 5% productivity gain, and in what circumstances. If it were an obvious and clear path to greater productivity, and superior to other paths to greater productivity (such as spending more time learning your editor and shell and environment, or learning about a new library in the language your work is written in, or learning new tricks in your current language), no one would hesitate to increase their productivity in this way. You seem to assume that people are choosing not to become more productive by opting not to switch to Haskell or learn Haskell or something about Haskell. There are thousands of programming languages. Shall we learn them all to become five thousand percent more productive? I'm not opposed to learning new languages. I think folks should tinker. But, I don't think it is provable that learning Haskell will make you more productive than other activities.