5 ms·

Haskell has two useful features that are missing from the languages you mentioned: 1. Strong static typing 2. Pattern matching (1) tends to make development

by rkts 18y ago

Haskell has two useful features that are missing from the languages you mentioned: 1. Strong static typing 2. Pattern matching (1) tends to make development go faster (in my experience) by catching your mistakes early and locating them more accurately than a debugger can. It's also good for performance. (2) is great for any program that does a lot of stuff with trees, such as a compiler. However, neither of these features is unique to Haskell. They're also present in OCaml, SML, F#, and Scala, all of which should be easier to learn and start using than Haskell. The main qualities that distinguish Haskell from other languages are purity and laziness. These may be worth learning about since they're theoretically interesting, but their practical value is pretty dubious.

dons 18y ago
> purity and laziness. These may be worth learning about since they're theoretically interesting, but their practical value is pretty dubious Purity is important if you care about safety, maintainability, or paralellism. Also makes transactional memory tractable.
- gensym 18y ago
  And laziness is really helpful in constructing fast data structures while maintaining purity. Purely Functional Data Structures is a great read to see how this fits together.
  - blasdel 18y ago
    Laziness also scares people away from violating purity
- rkts 18y ago
  You keep saying that, but I've never heard a justification for it that wasn't totally Kool-Aid flavored. I'm all for safety in the sense of catching errors at compile time, provided they can be caught with minimal help from the programmer. Proof of more complicated properties should be optional. Haskell requires you to embed a proof of functional purity into every program you write, and this is just not how programming should work. As to maintainability, this claim is clearly false. Pure programs become harder to change as they grow, because adding and removing side effects requires drastic restructuring. Of course, most Haskell programs (in my limited observation) seem to deal with problems that are mostly mathematical or computational in nature, like compilers and Sudoku solvers, where these issues don't arise much. But that's not really an endorsement for something that purports to be useful in the Real World.
  - barrkel 18y ago
    Re maintainability - it is not clearly false. The biggest problem with maintenance is figuring out what the code does in the first place. When you know that the code you're looking at has zero data dependencies other than its arguments, and what's more, cannot possibly introduce other data dependencies through any of its descendants in the call graph, it relieves the burden immensely. Re adding and removing side-effects: I think you're just making this up without much experience. Most programs only need side-effects in certain areas, typically in the outermost loops and top-level functions. For example, a very simple single-threaded stateful web server could be implemented only needing I/O access in its outermost loop, implementing its request -> response function in a pure way, and using tail recursion to maintain state between different iterations of the server loop. Re compilers: unless you've written several compilers, you can't make claims about techniques used in compilers not being highly useful in solving large classes of problems. In many ways, yes, compilers are the ultimate functional programs (output is a pure function of input), but guess what: the flow of a compiler - parsing input, inferring its semantic intent, performing required transformations and generating output based on recursive application of patterns - is exactly the same as the flow of an average web request.
  - dons 18y ago
    I'm not sure where this idea that it is "mostly used for sudoku solvers" comes from. While clearly insulting, it is also clearly false. The breadth of code on http://hackage.haskell.org/ http://hackage.haskell.org/ gives witness to this, with just on 1000 libraries written over the last 18 months, most heavily weighted towards networking, graphics, guis, databases, and so on. Similarly, the industrial users , http://haskell.org/haskellwiki/Haskell_in_industry http://haskell.org/haskellwiki/Haskell_in_industry , aren't writing sudoku solvers, but are finance houses, defense contractors, game companies, bioinformatics places, hardware dessign, a full range of applications, for a general purpose language.
    - davidw 18y ago
      Some of those are pretty big companies - clearly they're not using it for everything, but have decided it's the best choice for some particular problem domain. Sure, it's a general purpose language, but where's the "sweet spot"? I could write scientific number crunching stuff in Ruby, but that's definitely not its forte.
- davidw 18y ago
  So in terms of startups, what sort of business should pick Haskell to absolutely crush the competition, which is using things like Java or Ruby? What kinds of real world tasks can Haskell do, right now, so much better than other languages that it's a significant advantage?
  - miloshh 18y ago
    Especially program transformations, compilation, correctness proofs, model checking... Other ML-style languages might be good too, but Haskell feels cleaner and more modern, and seems to have a more vibrant community these days.
sethg 18y ago
I would add to that list: 3. Higher-order types (Yes, C++ has had this with templates for a while and Java has it with generics, but they bolted it on later, after the syntax and many essential libraries had been fixed.) 4. Type inference Type inference is a REALLY BIG DEAL to me, because it makes programming in a strongly-typed language much less painful, and with that pain gone, I can better appreciate the compiler using the type system to cover my ass.
jganetsk 18y ago
Erlang has lots of pattern matching.
- davidw 18y ago
  But not a type system like Haskell. I simply don't know enough about Haskell to have an opinion on how much of a good or bad thing its type system is, but it's definitely different from Erlang's. My original comment was meant to get the Haskell guys talking about what practical, real world advantages their language has. Even if I don't see it becoming the 'next big thing', I like Erlang, in that it's extremely practical for certain types of problems.

by rkts 18y ago

dons 18y ago

> purity and laziness. These may be worth learning about since they're theoretically interesting, but their practical value is pretty dubious Purity is important if you care about safety, maintainability, or paralellism. Also makes transactional memory tractable.

gensym 18y ago
And laziness is really helpful in constructing fast data structures while maintaining purity. Purely Functional Data Structures is a great read to see how this fits together.
- blasdel 18y ago
  Laziness also scares people away from violating purity
rkts 18y ago
You keep saying that, but I've never heard a justification for it that wasn't totally Kool-Aid flavored. I'm all for safety in the sense of catching errors at compile time, provided they can be caught with minimal help from the programmer. Proof of more complicated properties should be optional. Haskell requires you to embed a proof of functional purity into every program you write, and this is just not how programming should work. As to maintainability, this claim is clearly false. Pure programs become harder to change as they grow, because adding and removing side effects requires drastic restructuring. Of course, most Haskell programs (in my limited observation) seem to deal with problems that are mostly mathematical or computational in nature, like compilers and Sudoku solvers, where these issues don't arise much. But that's not really an endorsement for something that purports to be useful in the Real World.
- barrkel 18y ago
  Re maintainability - it is not clearly false. The biggest problem with maintenance is figuring out what the code does in the first place. When you know that the code you're looking at has zero data dependencies other than its arguments, and what's more, cannot possibly introduce other data dependencies through any of its descendants in the call graph, it relieves the burden immensely. Re adding and removing side-effects: I think you're just making this up without much experience. Most programs only need side-effects in certain areas, typically in the outermost loops and top-level functions. For example, a very simple single-threaded stateful web server could be implemented only needing I/O access in its outermost loop, implementing its request -> response function in a pure way, and using tail recursion to maintain state between different iterations of the server loop. Re compilers: unless you've written several compilers, you can't make claims about techniques used in compilers not being highly useful in solving large classes of problems. In many ways, yes, compilers are the ultimate functional programs (output is a pure function of input), but guess what: the flow of a compiler - parsing input, inferring its semantic intent, performing required transformations and generating output based on recursive application of patterns - is exactly the same as the flow of an average web request.
- dons 18y ago
  I'm not sure where this idea that it is "mostly used for sudoku solvers" comes from. While clearly insulting, it is also clearly false. The breadth of code on http://hackage.haskell.org/ http://hackage.haskell.org/ gives witness to this, with just on 1000 libraries written over the last 18 months, most heavily weighted towards networking, graphics, guis, databases, and so on. Similarly, the industrial users , http://haskell.org/haskellwiki/Haskell_in_industry http://haskell.org/haskellwiki/Haskell_in_industry , aren't writing sudoku solvers, but are finance houses, defense contractors, game companies, bioinformatics places, hardware dessign, a full range of applications, for a general purpose language.
  - davidw 18y ago
    Some of those are pretty big companies - clearly they're not using it for everything, but have decided it's the best choice for some particular problem domain. Sure, it's a general purpose language, but where's the "sweet spot"? I could write scientific number crunching stuff in Ruby, but that's definitely not its forte.
davidw 18y ago
So in terms of startups, what sort of business should pick Haskell to absolutely crush the competition, which is using things like Java or Ruby? What kinds of real world tasks can Haskell do, right now, so much better than other languages that it's a significant advantage?
- miloshh 18y ago
  Especially program transformations, compilation, correctness proofs, model checking... Other ML-style languages might be good too, but Haskell feels cleaner and more modern, and seems to have a more vibrant community these days.

sethg 18y ago

I would add to that list: 3. Higher-order types (Yes, C++ has had this with templates for a while and Java has it with generics, but they bolted it on later, after the syntax and many essential libraries had been fixed.) 4. Type inference Type inference is a REALLY BIG DEAL to me, because it makes programming in a strongly-typed language much less painful, and with that pain gone, I can better appreciate the compiler using the type system to cover my ass.

jganetsk 18y ago

Erlang has lots of pattern matching.

davidw 18y ago
But not a type system like Haskell. I simply don't know enough about Haskell to have an opinion on how much of a good or bad thing its type system is, but it's definitely different from Erlang's. My original comment was meant to get the Haskell guys talking about what practical, real world advantages their language has. Even if I don't see it becoming the 'next big thing', I like Erlang, in that it's extremely practical for certain types of problems.