4 ms·

> The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. This is an instance of begging the question

> The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. This is an instance of begging the question too. Newer, less popular languages will always have fewer libraries and bindings relative to more popular languages. It might be an argument against using Haskell at the current point in time, but it has nothing to do with the merits of the language itself. But the reality is that Haskell is actually doing quite well in terms of libraries and bindings. Pick anything you can think of...odds are probably pretty good that Haskell has bindings to it. As an example, let's look at the two projects you mentioned: ZooKeeper and Hadoop. Yep, there are Haskell bindings to both of them. For ZooKeeper there's hzk (http://hackage.haskell.org/package/hzk http://hackage.haskell.org/package/hzk), and for Hadoop there's hadron (https://github.com/Soostone/hadron https://github.com/Soostone/hadron) and there's even a nice presentation about it (http://vimeo.com/90189610 http://vimeo.com/90189610).

pron 12y ago
> It might be an argument against using Haskell at the current point in time, but it has nothing to do with the merits of the language itself. The merits of the language itself don't matter that much. A language isn't a piece of art to be admired. And as long as Haskell is used by such a tiny group of people, the merits of the language itself can't even be argued well, because it's unclear how they work in practice for different kinds of software and different kinds of developers. And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language.
- mightybyte 12y ago
  > And as long as Haskell is used by such a tiny group of people I'm guessing Haskell is used by more people than you think. There are 6500 packages on hackage. The Haskell subreddit has more than 16,000 subscribers. And there are usually more than 1300 people in the #haskell IRC channel at any given time. That's more than #ruby and ##javascript and about the same as #python. Also, Standard Chartered bank has roughly 1.3 million lines of Haskell code running in production. > And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language. This statement applies equally to pretty much every language out there. We don't understand the tradeoffs between mainstream languages either. We have no idea how those choices are actually going to end up affecting our projects. To claim otherwise is intellectually dishonest. How do you know that Ruby or Perl would be better than Brainfuck? The tradeoffs and merits aren't clear. They're at best hypotheses of potential merits. So how do we actually make these decisions in practice? We look at the language features and think about how they can help us manage common situations in software development, then we go with our best guess. We can do that for Haskell just as well as we can do that for Java, C, Ruby, etc.
  - pron 12y ago
    > We look at the language features and think about how they can help us manage common situations in software development Maybe some people do, but when I pick a programming language, language features are among the last things on my mind. I look at the available tools (profilers etc.), available libraries (particularly in the domain that interests me), quality of documentation, the size of the community and its vibrancy. I also look at similar projects done in the language. Only after all these do I look at the language features, but they don't matter so much, because I know I'll be very productive in a language with a very large selection of libraries and a large user community. I'm saying this after 20 years of developing software in languages like BASIC, Pascal, x86 asm, C, C++, Matlab, Java, Clojure, Scheme and more. I can't think of a single case where language features mattered more than any one of the things I listed. All this is, of course, for serious projects intended for production. For a toy project I might look at the language features first.
    - nbouscal 12y ago
      If there were superb tooling, libraries, and documentation available for Brainfuck or INTERCAL, you would not find that sufficient reason to program in those languages. Of course, you will say, such a situation would never exist, because nobody is going to write libraries for INTERCAL. With this argument, though, you concede that language features are important. You just estimate them by proxy: languages with features that encourage library authorship pass your test. Rather than use this proxy test, some of us who are well informed about PLT choose to judge languages on their merits directly. Nobody in this thread is talking about toy projects. Developers who use mainstream programming languages do not have a monopoly on real work. The consistent assumption made in these discussions that FP practitioners don't work on "serious projects intended for production" is misguided and insulting.
      - pron 12y ago
        I think your cause and effect are reversed. I think that the biggest difference between "pragmatic" languages and research languages, is that pragmatic languages are driven by actual need, and with consideration for current practices and workflow. The language features are designed around that. Research languages, OTOH, are made to explore an idea, or conduct an experiment, usually made to answer the question "how would these language features affect development" (they could increase productivity, reduce bugs, improve performance etc). The result of the experiment are very valuable, and the successful, proven, ideas are then integrated into pragmatic languages. It is very rare that a research language achieves mainstream adoption. In fact, I would argue that if it does, it's failed as a research language because its widespread adoption probably means it wasn't adventurous enough. Haskell is a prime example of a rather adventurous research language. It's an experiment that's been run for about 15 years now. First the early steps, and now people are experimenting with real world applicability. I'm really interested in the results, so I'd really like more people to run the experiment, but I have no doubt that Haskell itself will never gain widespread adoption. If it does its job well, its best ideas will be copied by other, non-research languages. Now, I'm certainly not saying that Haskellers don't work on serious projects. But it is a fact that Haskell is much more common in academia than it is in the industry. Again, this is intentional. Haskell is meant to venture into unchartered territory and explore. Some of the things it aims to do work well and might be adopted in the industry, and others don't and won't. If Haskell teaches us even a few things, then it is a great success. What I don't like is that some Haskellers deny the true purpose of the language, and instead of examining it as researchers should do, they preach it.
- nbouscal 12y ago
  Merit is not exclusively a characteristic of art. Tools have merits, and awareness of those merits is very important for any practitioner who seeks to use those tools in their work. If I went into my father's woodshop and sought to use his lathe to attempt to plane a board, he would rightfully yell at me. Merits of programming languages can be argued well, because there is an entire theoretical discipline dedicated to the understanding of programming languages (PLT). Your lack of knowledge of this field does not mean that it does not exist.

pron 12y ago

> It might be an argument against using Haskell at the current point in time, but it has nothing to do with the merits of the language itself. The merits of the language itself don't matter that much. A language isn't a piece of art to be admired. And as long as Haskell is used by such a tiny group of people, the merits of the language itself can't even be argued well, because it's unclear how they work in practice for different kinds of software and different kinds of developers. And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language.

mightybyte 12y ago
> And as long as Haskell is used by such a tiny group of people I'm guessing Haskell is used by more people than you think. There are 6500 packages on hackage. The Haskell subreddit has more than 16,000 subscribers. And there are usually more than 1300 people in the #haskell IRC channel at any given time. That's more than #ruby and ##javascript and about the same as #python. Also, Standard Chartered bank has roughly 1.3 million lines of Haskell code running in production. > And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language. This statement applies equally to pretty much every language out there. We don't understand the tradeoffs between mainstream languages either. We have no idea how those choices are actually going to end up affecting our projects. To claim otherwise is intellectually dishonest. How do you know that Ruby or Perl would be better than Brainfuck? The tradeoffs and merits aren't clear. They're at best hypotheses of potential merits. So how do we actually make these decisions in practice? We look at the language features and think about how they can help us manage common situations in software development, then we go with our best guess. We can do that for Haskell just as well as we can do that for Java, C, Ruby, etc.
- pron 12y ago
  > We look at the language features and think about how they can help us manage common situations in software development Maybe some people do, but when I pick a programming language, language features are among the last things on my mind. I look at the available tools (profilers etc.), available libraries (particularly in the domain that interests me), quality of documentation, the size of the community and its vibrancy. I also look at similar projects done in the language. Only after all these do I look at the language features, but they don't matter so much, because I know I'll be very productive in a language with a very large selection of libraries and a large user community. I'm saying this after 20 years of developing software in languages like BASIC, Pascal, x86 asm, C, C++, Matlab, Java, Clojure, Scheme and more. I can't think of a single case where language features mattered more than any one of the things I listed. All this is, of course, for serious projects intended for production. For a toy project I might look at the language features first.
  - nbouscal 12y ago
    If there were superb tooling, libraries, and documentation available for Brainfuck or INTERCAL, you would not find that sufficient reason to program in those languages. Of course, you will say, such a situation would never exist, because nobody is going to write libraries for INTERCAL. With this argument, though, you concede that language features are important. You just estimate them by proxy: languages with features that encourage library authorship pass your test. Rather than use this proxy test, some of us who are well informed about PLT choose to judge languages on their merits directly. Nobody in this thread is talking about toy projects. Developers who use mainstream programming languages do not have a monopoly on real work. The consistent assumption made in these discussions that FP practitioners don't work on "serious projects intended for production" is misguided and insulting.
    - pron 12y ago
      I think your cause and effect are reversed. I think that the biggest difference between "pragmatic" languages and research languages, is that pragmatic languages are driven by actual need, and with consideration for current practices and workflow. The language features are designed around that. Research languages, OTOH, are made to explore an idea, or conduct an experiment, usually made to answer the question "how would these language features affect development" (they could increase productivity, reduce bugs, improve performance etc). The result of the experiment are very valuable, and the successful, proven, ideas are then integrated into pragmatic languages. It is very rare that a research language achieves mainstream adoption. In fact, I would argue that if it does, it's failed as a research language because its widespread adoption probably means it wasn't adventurous enough. Haskell is a prime example of a rather adventurous research language. It's an experiment that's been run for about 15 years now. First the early steps, and now people are experimenting with real world applicability. I'm really interested in the results, so I'd really like more people to run the experiment, but I have no doubt that Haskell itself will never gain widespread adoption. If it does its job well, its best ideas will be copied by other, non-research languages. Now, I'm certainly not saying that Haskellers don't work on serious projects. But it is a fact that Haskell is much more common in academia than it is in the industry. Again, this is intentional. Haskell is meant to venture into unchartered territory and explore. Some of the things it aims to do work well and might be adopted in the industry, and others don't and won't. If Haskell teaches us even a few things, then it is a great success. What I don't like is that some Haskellers deny the true purpose of the language, and instead of examining it as researchers should do, they preach it.
nbouscal 12y ago
Merit is not exclusively a characteristic of art. Tools have merits, and awareness of those merits is very important for any practitioner who seeks to use those tools in their work. If I went into my father's woodshop and sought to use his lathe to attempt to plane a board, he would rightfully yell at me. Merits of programming languages can be argued well, because there is an entire theoretical discipline dedicated to the understanding of programming languages (PLT). Your lack of knowledge of this field does not mean that it does not exist.