4 ms·

I always wonder, if languages like Haskell are so good, why don't we see a lot of amazing open source projects built with these languages? If you can get things

by jshen 12y ago

I always wonder, if languages like Haskell are so good, why don't we see a lot of amazing open source projects built with these languages? If you can get things done faster with fewer bugs it should be reflected in real life code bases. Yet I haven't seen it. "The only arguments that hold water, in terms of programming language suitability, are bold, finished projects." http://t.co/ahOBAnXZ18 http://t.co/ahOBAnXZ18

bunderbunder 12y ago
I think maybe it's just another example of the worse-is-better principle. Great as it is, the language itself (and functional programming in general) tends to be pretty opaque to most programmers. Purity is powerful; we've all heard it before so I'll spare us yet another apologia. But, as my time spent TAing an introductory course in Scheme taught me in agonizing detail, purity is painful, too. Most people just don't naturally think of processes as a composition of mappings from values in a domain to values in a codomain. For better or for worse, the "process as widget-fiddling" way of thinking comes much more easily.
- loup-vaillant 12y ago
  > Most people just don't naturally think of processes as a composition of mappings from values in a domain to values in a codomain. This is most difficult to accept, because I do. It's like programmers are divided into two camps: those who think procedurally, and those who think mathematically. I have noticed lately how this can influence API design, down to things as simple as this: void latin9_to_utf8( std::string& latin9str); std::string latin9_to_utf8(const std::string& latin9str); The first interface is a design mistake: it encourages side effects, and requires more code to use in practice. But it is also a very natural one: you want to convert strings, so you write a function that converts strings (KISS). The second interface is better, but more convoluted: instead of just converting strings, it returns converted strings. Guess which ended up in a real program I worked on…
  - bunderbunder 12y ago
    Cases like that are fairly straightforward. Where things really fall apart is using recursion instead of loops. Especially when the time comes to mention tail recursion.
    - loup-vaillant 12y ago
      Case like that are straightforward, and people still manage to botch them. Which is why I suspect there is something deeply wrong, or at least fundamentally different, about the minds that produce such mistakes. Though for this particular mistake, it may have come from some misguided notion about performance (like perceived overhead of constructing a string then passing it up the stack). As for things like recursion and closures… I just avoid them because I know my colleagues will recoil in horror with such uselessly indecipherable excess of cleverness.
ssmoot 12y ago
I think maybe you do. The size of Sonatype Snapshots and Central is roughly around Rubygems.org size I think. But so so so many Ruby projects are half baked, while so many public JARs are so much more mature (if often not very pleasant to work with).
Joeri 12y ago
Programmers write the same number of debugged lines (or expressions) of code per day, regardless of the language they write in. A language only enables faster development if it requires fewer expressions to say the same thing. That is why high-level languages trounce low-level languages when it comes to productivity. I admit to not being very familiar with Haskell, but if it is not more concise it's not likely to be more productive.
- NateDad 12y ago
  I don't believe that. The speed of producing code is not relative to typing speed. LOC per day depends on the complexity of the lines. I can write 500 simple lines or 50 complex lines of code in a day. I'd agree that higher level languages deal with some of the complexity for you, like memory management. But I bet the business logic takes a similar amount of time in almost any language, assuming the developer has the same amount of experience in each language.
  - Joeri 12y ago
    I don't think typing speed factors into it. It's more a factor of cognitive load. While programming you are working at the level of "expressions", and your speed is limited to how quickly you can turn business logic into appropriate sets of expressions. Programming languages that are lower level require more expressions to say the same thing, hence are slower to program in. I don't think it's a controversial notion to say that assembly is less productive than C, which is less productive than Python. The reason is the number of lines (or rather expressions) needed to achieve a piece of functionality. The business logic most definitely does not take the same amount of time when written in assembly compared to python. The higher level languages tend to be more productive, but it is only a given if the higher level language is actually more concise. Here are some papers that underbuild this argument: http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer2000.pdf http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer... https://files.ifi.uzh.ch/rerg/amadeus/teaching/seminars/seminar_ws0203/Seminar_3.pdf https://files.ifi.uzh.ch/rerg/amadeus/teaching/seminars/semi...
  - jshen 12y ago

by jshen 12y ago

bunderbunder 12y ago

I think maybe it's just another example of the worse-is-better principle. Great as it is, the language itself (and functional programming in general) tends to be pretty opaque to most programmers. Purity is powerful; we've all heard it before so I'll spare us yet another apologia. But, as my time spent TAing an introductory course in Scheme taught me in agonizing detail, purity is painful, too. Most people just don't naturally think of processes as a composition of mappings from values in a domain to values in a codomain. For better or for worse, the "process as widget-fiddling" way of thinking comes much more easily.

loup-vaillant 12y ago
> Most people just don't naturally think of processes as a composition of mappings from values in a domain to values in a codomain. This is most difficult to accept, because I do. It's like programmers are divided into two camps: those who think procedurally, and those who think mathematically. I have noticed lately how this can influence API design, down to things as simple as this: void latin9_to_utf8( std::string& latin9str); std::string latin9_to_utf8(const std::string& latin9str); The first interface is a design mistake: it encourages side effects, and requires more code to use in practice. But it is also a very natural one: you want to convert strings, so you write a function that converts strings (KISS). The second interface is better, but more convoluted: instead of just converting strings, it returns converted strings. Guess which ended up in a real program I worked on…
- bunderbunder 12y ago
  Cases like that are fairly straightforward. Where things really fall apart is using recursion instead of loops. Especially when the time comes to mention tail recursion.
  - loup-vaillant 12y ago
    Case like that are straightforward, and people still manage to botch them. Which is why I suspect there is something deeply wrong, or at least fundamentally different, about the minds that produce such mistakes. Though for this particular mistake, it may have come from some misguided notion about performance (like perceived overhead of constructing a string then passing it up the stack). As for things like recursion and closures… I just avoid them because I know my colleagues will recoil in horror with such uselessly indecipherable excess of cleverness.

ssmoot 12y ago

I think maybe you do. The size of Sonatype Snapshots and Central is roughly around Rubygems.org size I think. But so so so many Ruby projects are half baked, while so many public JARs are so much more mature (if often not very pleasant to work with).

Joeri 12y ago

Programmers write the same number of debugged lines (or expressions) of code per day, regardless of the language they write in. A language only enables faster development if it requires fewer expressions to say the same thing. That is why high-level languages trounce low-level languages when it comes to productivity. I admit to not being very familiar with Haskell, but if it is not more concise it's not likely to be more productive.

NateDad 12y ago
I don't believe that. The speed of producing code is not relative to typing speed. LOC per day depends on the complexity of the lines. I can write 500 simple lines or 50 complex lines of code in a day. I'd agree that higher level languages deal with some of the complexity for you, like memory management. But I bet the business logic takes a similar amount of time in almost any language, assuming the developer has the same amount of experience in each language.
- Joeri 12y ago
  I don't think typing speed factors into it. It's more a factor of cognitive load. While programming you are working at the level of "expressions", and your speed is limited to how quickly you can turn business logic into appropriate sets of expressions. Programming languages that are lower level require more expressions to say the same thing, hence are slower to program in. I don't think it's a controversial notion to say that assembly is less productive than C, which is less productive than Python. The reason is the number of lines (or rather expressions) needed to achieve a piece of functionality. The business logic most definitely does not take the same amount of time when written in assembly compared to python. The higher level languages tend to be more productive, but it is only a given if the higher level language is actually more concise. Here are some papers that underbuild this argument: http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer2000.pdf http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer... https://files.ifi.uzh.ch/rerg/amadeus/teaching/seminars/seminar_ws0203/Seminar_3.pdf https://files.ifi.uzh.ch/rerg/amadeus/teaching/seminars/semi...
- jshen 12y ago