4 ms·

> A truly open-minded position would have to continually consider that maybe Haskell and its type system are not the best options at all There are two ways tha

> A truly open-minded position would have to continually consider that maybe Haskell and its type system are not the best options at all There are two ways that I can parse this comment. The first is that you mean that there are other, newer options out there that will turn out to be better than Haskell. This, almost all Haskellers would agree with: most of us have more than a passing interest in e.g. Idris, Agda, Shen, etc. The other reading is that you mean that other established paradigms are better options (A third reading is that there is no such thing as better, but for that I'll just point you to pg's classic Blub essay). This is a good thing to consider once, but I strongly disagree with considering it continually. Once you've made the comparison, if you come to the conclusion that one tool is better than another, it doesn't make sense to continue that comparison forever. It may make sense to revisit it from time to time as you grow in your understanding of the task and the context, but at some point your posterior probability of the other tool being better must grow so low as to no longer be worth investigation. For many Haskellers, the comparison between a Haskell-like type system and dynamic typing is this kind of comparison. My posterior probability of dynamic typing being a better choice is less than one percent, so it makes no sense for me to continue reevaluating that option. If the latter is what you mean, I can't disagree that it is a truly open-minded position, I can only point you to a quote by the inimitable Tim Minchin: "If you open your mind too much, your brain will fall out."

the_af 12y ago
I mean the latter, but not because it's my position (I certainly don't think an effective use of my time would be to continually re-evaluate each of my opinions on programming languages), but because I think it would mesh better with the article's tone of "humility above all things". My own opinion is that sometimes you're right and your interlocutor is wrong, and sometimes this means you simply cannot avoid sounding condescending.
yomritoyj 12y ago
You presume that reevaluation of your position is an expensive operation that we must economise on. But sometimes it is just keeping your eyes open. For this particular question, I see lots of very good and beautiful written in imperative and dynamically-typed languages. There are many problems for which the most natural program is imperative or object-oriented. So to me at least looking at the programming language world with the presumption that Haskell-like languages are always superior seems cultish indeed.
- nbouscal 12y ago
  It's not a presumption. It's not a prior that we're holding to regardless of evidence. The superiority of Haskell is, for all the Haskellers I know, a conclusion that they came to after extensive research and experimentation. It's not like we were somehow trained in some hidden refuge where imperative and object-oriented languages aren't spoken of. I cut my teeth on PHP, of all things. I know what's out there, I've made the comparisons, and I see no reason that I should keep doing so forever.
- codygman 12y ago
  When you say "problem" you are describing something higher level than just an algorithm, yes? Could you give some examples of problems that the most natural program is imperative or object-oriented?
marcosdumay 12y ago
For a given problem, no doubt, some languages are better than others. I still doubt one can say that in general, without qualifying what kind of problem he's solving. I'm just writting a device controller in a side project (at userland - I already have enough problems to solve - the kernel sees it as a soundboard and a USB TTY). At fist I tought "wait, great time to try some serious reactive programming in Haskell", but I gave up, C++ looks much better fit to that problem. When it's done, I'll probably write some Haskell wrapper, and use it in a functional reactive program, but Haskell is just not the language for the controller itself. Also, another side project requires a CRUD web app, with some simple rules. It's in Python. No way I'm going to write it in Haskell. Another component is a TCP server with a complex behaviour and that I want to scale, it's in Haskell, no way I'm going to write it in Python. Another component is in VB.Net, go figure... Maybe there is a young and mostly unkown language that is indeed best - no strings attached. But it's certainly not Haskell and I still didn't find it.
- nbouscal 12y ago
  There's definitely a tradeoff between library maturity and language quality. There are also a few specific domains that are best-served by more domain-targeted languages. That doesn't mean we can't say that, aside from those issues, one language is better than another. I can say that Haskell is a better language than Python and then go ahead and use Python anyway because NumPy/SciPy/pandas or whatever. We can separate the issues and render judgments about language quality independent from library maturity, etc. The existence of specialized domains justifies an argument that you should use specialized languages in those domains, but that is almost never what we're discussing. Java, Python, Ruby, Haskell, Clojure... none of these are languages specialized for a given domain. They're all general-purpose languages, and if you compare them as such independent from their libraries, Haskell is the best of them. That does not mean that it's the best choice for every project, but that's a completely different question.
  - marcosdumay 12y ago
    Sorry, but I still disagree. It's the flexibility of Python that makes it great for writting CRUD applications with diverse data types, at the same time that it's the rigidity of Haskell that makes it great for writting a complex specialized server. It's the unsafety of C++ that makes it great for directly interfacing devices, but you really does not want that unsafety in any of the other examples. None of that is a matter of maturity, it's the other way around, the available libraries are good for different tasks because the languages allow them to be. You can't just compare those languages without context.
AnimalMuppet 12y ago
You point us to the Blub essay as if that settles the matter. It doesn't. I think the Blub essay is wrong. Here's the Lisp people. They're sure that they are at the top of the power curve (including compared to Haskell), and they can tell you exactly why. "How can you get anything done in Haskell? It doesn't even have macros." Over here are the Haskell types (pun intended). They're sure that they are at the top of the power curve (including compared to Lisp), and they can tell you exactly why. "How can you get anything done in Lisp? It doesn't even have a decent type system." This situation - two different languages each looking down at the other - reveals the problem in pg's Blub Paradox. The problem is this: The idea that all languages can be ranked on a one-dimensional axis called "power" is wrong. You can see this with hardware, for instance. We know what power is in hardware - it's MIPS. But once you think a bit deeper, you might remember that your workload contains a fair amount of floating point, so you have to worry about FLOPS... and there's that one data set that doesn't fit into cache, so you have to worry about memory bandwidth... or would it be worth lower MIPS to have a bigger cache? Now "power" has at least four dimensions (MIPS, FLOPS, memory bandwidth, and cache size). Even more (but for the same reasons), it's naive to say that programming languages can be strictly ordered according to on a one-dimensional "power" axis. So now you have to start asking "power for what"? I think this is the right question, because nobody ever writes a general computer program. We always write specific ones. We want a programming language that has the most power for that specific problem we're trying to solve. Once you crack open that door, in walks (for example) a Fortran person, who asks, "How can you get anything done in Haskell or Lisp? They don't even have decent matrix packages!" And before you say "of course they can do matrix math", by "decent" the Fortran person meant a package that can, for example, efficiently handle a banded hermitian matrix with complex elements, and still get good answers even if it turns out to be a stiff problem. I strongly suspect that Lisp and Haskell matrix packages aren't yet up to that standard. (And if you're going to say, "Well, that's just a niche", I suspect that niche is at least as big as the entire Haskell universe.) Then a hard-real-time embedded programmer comes through the door, and says that their world needs a language that not only doesn't garbage collect, but doesn't cons either. (That niche is probably also as big as the Haskell or Lisp universe.) And so on. Think of programming languages as a tree. Think of your problem as a vector. Use whatever branch of the tree gets you the furthest along the vector of your problem. In other words, the best tool for the job. It's not always Haskell. It's not always anything. Learn more than one tool.

the_af 12y ago

I mean the latter, but not because it's my position (I certainly don't think an effective use of my time would be to continually re-evaluate each of my opinions on programming languages), but because I think it would mesh better with the article's tone of "humility above all things". My own opinion is that sometimes you're right and your interlocutor is wrong, and sometimes this means you simply cannot avoid sounding condescending.

yomritoyj 12y ago

You presume that reevaluation of your position is an expensive operation that we must economise on. But sometimes it is just keeping your eyes open. For this particular question, I see lots of very good and beautiful written in imperative and dynamically-typed languages. There are many problems for which the most natural program is imperative or object-oriented. So to me at least looking at the programming language world with the presumption that Haskell-like languages are always superior seems cultish indeed.

nbouscal 12y ago
It's not a presumption. It's not a prior that we're holding to regardless of evidence. The superiority of Haskell is, for all the Haskellers I know, a conclusion that they came to after extensive research and experimentation. It's not like we were somehow trained in some hidden refuge where imperative and object-oriented languages aren't spoken of. I cut my teeth on PHP, of all things. I know what's out there, I've made the comparisons, and I see no reason that I should keep doing so forever.
codygman 12y ago
When you say "problem" you are describing something higher level than just an algorithm, yes? Could you give some examples of problems that the most natural program is imperative or object-oriented?

marcosdumay 12y ago

For a given problem, no doubt, some languages are better than others. I still doubt one can say that in general, without qualifying what kind of problem he's solving. I'm just writting a device controller in a side project (at userland - I already have enough problems to solve - the kernel sees it as a soundboard and a USB TTY). At fist I tought "wait, great time to try some serious reactive programming in Haskell", but I gave up, C++ looks much better fit to that problem. When it's done, I'll probably write some Haskell wrapper, and use it in a functional reactive program, but Haskell is just not the language for the controller itself. Also, another side project requires a CRUD web app, with some simple rules. It's in Python. No way I'm going to write it in Haskell. Another component is a TCP server with a complex behaviour and that I want to scale, it's in Haskell, no way I'm going to write it in Python. Another component is in VB.Net, go figure... Maybe there is a young and mostly unkown language that is indeed best - no strings attached. But it's certainly not Haskell and I still didn't find it.

nbouscal 12y ago
There's definitely a tradeoff between library maturity and language quality. There are also a few specific domains that are best-served by more domain-targeted languages. That doesn't mean we can't say that, aside from those issues, one language is better than another. I can say that Haskell is a better language than Python and then go ahead and use Python anyway because NumPy/SciPy/pandas or whatever. We can separate the issues and render judgments about language quality independent from library maturity, etc. The existence of specialized domains justifies an argument that you should use specialized languages in those domains, but that is almost never what we're discussing. Java, Python, Ruby, Haskell, Clojure... none of these are languages specialized for a given domain. They're all general-purpose languages, and if you compare them as such independent from their libraries, Haskell is the best of them. That does not mean that it's the best choice for every project, but that's a completely different question.
- marcosdumay 12y ago
  Sorry, but I still disagree. It's the flexibility of Python that makes it great for writting CRUD applications with diverse data types, at the same time that it's the rigidity of Haskell that makes it great for writting a complex specialized server. It's the unsafety of C++ that makes it great for directly interfacing devices, but you really does not want that unsafety in any of the other examples. None of that is a matter of maturity, it's the other way around, the available libraries are good for different tasks because the languages allow them to be. You can't just compare those languages without context.

AnimalMuppet 12y ago

You point us to the Blub essay as if that settles the matter. It doesn't. I think the Blub essay is wrong. Here's the Lisp people. They're sure that they are at the top of the power curve (including compared to Haskell), and they can tell you exactly why. "How can you get anything done in Haskell? It doesn't even have macros." Over here are the Haskell types (pun intended). They're sure that they are at the top of the power curve (including compared to Lisp), and they can tell you exactly why. "How can you get anything done in Lisp? It doesn't even have a decent type system." This situation - two different languages each looking down at the other - reveals the problem in pg's Blub Paradox. The problem is this: The idea that all languages can be ranked on a one-dimensional axis called "power" is wrong. You can see this with hardware, for instance. We know what power is in hardware - it's MIPS. But once you think a bit deeper, you might remember that your workload contains a fair amount of floating point, so you have to worry about FLOPS... and there's that one data set that doesn't fit into cache, so you have to worry about memory bandwidth... or would it be worth lower MIPS to have a bigger cache? Now "power" has at least four dimensions (MIPS, FLOPS, memory bandwidth, and cache size). Even more (but for the same reasons), it's naive to say that programming languages can be strictly ordered according to on a one-dimensional "power" axis. So now you have to start asking "power for what"? I think this is the right question, because nobody ever writes a general computer program. We always write specific ones. We want a programming language that has the most power for that specific problem we're trying to solve. Once you crack open that door, in walks (for example) a Fortran person, who asks, "How can you get anything done in Haskell or Lisp? They don't even have decent matrix packages!" And before you say "of course they can do matrix math", by "decent" the Fortran person meant a package that can, for example, efficiently handle a banded hermitian matrix with complex elements, and still get good answers even if it turns out to be a stiff problem. I strongly suspect that Lisp and Haskell matrix packages aren't yet up to that standard. (And if you're going to say, "Well, that's just a niche", I suspect that niche is at least as big as the entire Haskell universe.) Then a hard-real-time embedded programmer comes through the door, and says that their world needs a language that not only doesn't garbage collect, but doesn't cons either. (That niche is probably also as big as the Haskell or Lisp universe.) And so on. Think of programming languages as a tree. Think of your problem as a vector. Use whatever branch of the tree gets you the furthest along the vector of your problem. In other words, the best tool for the job. It's not always Haskell. It's not always anything. Learn more than one tool.