6 ms·

Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top o

Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. The great thing about Haskell and other functional programming languages is that the functional style forces the program to be created in a form that is modular and elegant. Programs become modular and composable and re-composable in the functional world because the programmer has No Choice but to build his programs in an elegant way. It's hard to explain this to a typical programmer who hasn't dived deep into functional programming but code reuse, modularity and elegance are significantly higher in functional programming languages than in procedural. This elegance, beauty and forced organization comes at a high cost though. And the cost is thinking in a way that is outside the normal paradigm of what humans are use to. I know a lot of haskellers think that humans can be taught to think in both ways equally, I disagree with them and believe that it is far Easier for a human to think about an algorithm procedurally than it is for him to think about it functionally. If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally. This I believe is the main reason why Haskell or lisps haven't taken over the programming world. Functional programming is just HARDER. It takes me 10 times longer to hack out a simple program in haskell than it does in python because haskell doesn't allow you to 'hack' together a program. In haskell the application has to be an elegant diamond or the thing won't even compile! Python allows me to hack something together quickly which is both a good and a bad thing because as we all know hacking together software is quick but easily leads to unmaintainable software.

platz 10y ago
> In haskell the application has to be an elegant diamond or the thing won't even compile! Nonsense - You only have to make things as hard/elegant as you want them to be (and fore sure, some people do play that game for better/worse). But, Haskell will happily allow you throw everything in to IO; you can side-step creating a perfect model and just hack together a list of imperative IO statements. (unless you're referring to the difference between a dynlang and a static lang; that's a difference of another category altogether)
- pekk 10y ago
  If you are going to "throw everything in IO" then what advantage does Haskell have?
  - platz 10y ago
    yes, there is a difference between "'hack' together a program" and doing proper domain modeling. However, neither should prevent the other. (i.e. "you can do X" should not be confused with "always do X"). Haskell allows you to choose. Indeed, proper domain modeling is preferred.. but it's nice to have to ability to make that choice yourself based on your own constraints. Additionally, Haskell makes it very easy/pleasant to refactor from the former to the latter. (On that note, imho the best models (in business) are arrived at iteratively rather than big-design-up-front)
  - swift 10y ago
    You can refactor it later, of course. It's even possible to opt out of static type checking if you want. GHCi also provides a REPL that makes exploratory programming easy.
  - tel 10y ago
    Even "just IO" in Haskell enjoys some very nice typing properties and is often easier to write and ensure proper operation than similar "just IO" programs in other languages. It's actually super pleasant!
  - rs86 10y ago
    Lazyness, generic programming, algebraic datatypes, inferred typing
ngrilly 10y ago
I don't understand the downvote. The main argument looks valid: > If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally. This I believe is the main reason why Haskell or lisps haven't taken over the programming world.
- platz 10y ago
  I'm not the downvoter, but I still don't understand the assertion why Haskell doesn't allow the "task list". There is nothing preventing using these "task lists" (e.g. lists/steps/procedures) in Haskell. In fact, "do notation", a core language feature every beginner learns, features it.
  - crimsonalucard 10y ago
    You are right, but no beginner truly understands do notation. It's just magic to them. Do notation is an abstraction on top of monads which is an incredibly hard to understand abstraction on top of functional programming. Functional programming in essence does not allow procedures, but with special incredibly complex abstractions you can simulate procedures. If you program using said abstractions I would argue that it makes functional programming even Harder to understand.
    - platz 10y ago
      Look, I'm not saying Haskell is easy to learn, it's one of the steepest learning curves I know of in programming. But I don't think do notation is what trips up beginners (not sure if this discussion is about beginners per se). It is explained by simple mechanical plug-and-chug transformations that I think beginners understand, but am willing to hear if there is evidence otherwise.. I just think it's the other things that will eventually trip them up (I was only responding to specific claims made earlier). Also, on the point of resting on abstractions being a problem, I don't find compelling, because I'm also sure that Python beginners don't understand what "class MyStuff(object):" is really doing, but if the abstraction isn't leaky try don't need to know right away, and they can delve later.
prance 10y ago
> Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. That is not what is usually meant by "expressiveness" of a language. You seem to be talking about types of languages (as in the Chomsky hierarchy), by implying that there are problems you can solve in assembler but not in Haskell. That is not the case, as both are Turing-complete (Type-0). In contrast, "expressiveness" usually refers to the "ease" (one may substitute conciseness in most cases) with which higher level concepts (abstractions) are expressible in the language, and here Haskell clearly wins against assembler, and many other popular languages.
- crimsonalucard 10y ago
  The set of all possible assembly instructions is bigger than the set of all possible assembly instructions that haskell can compile to. Therefore haskell is less expressive than assembly language. That is what I mean by expressive.
  - prance 10y ago
    >The set of all possible assembly instructions is bigger than the set of all possible assembly instructions that haskell can compile to. No it's not. The Haskell compiler is free to use whatever assembly instructions that it sees fit to compile the Haskell program. Maybe you mean that effectively, the set of assembly programs (i.e. sequences of assembly instructions) which existing Haskell compilers happen to produce is limited. This is true. But it is also true that you can find an equivalent Haskell program for every possible assembly program, where equivalent means they exhibit the same behavior with respect to inputs and outputs. This is because both are Turing equivalent. Now, it's also true that the way two equivalent programs get to their results may differ. For example, the assembly program might be faster. However, these are non-functional properties of the programs. And you were talking explicitly about functionality, so this point doesn't count towards your argument.
    - 10y ago
jaegerpicker 10y ago
I don't believe this is true for Haskell but I'm not a great Haskell dev. I do know Ocaml (mostly F# actually but it's super close) and this isn't at all true for OCaml which has a ton in common with Haskell. In OCaml I make lists of functions as pipe based expressions, where each step in the pipeline is a function. It's incredibly easy to reason about and matches the lists of functions view of development extraordinarily well. I know Elm (a simplified version of Haskell) supports pipe based programming also. Functional languages haven't taken over because OO and Java are still the primary way of teaching beginners to code. Very few beginners start with functional programming.
- crimsonalucard 10y ago
  function composition sort of emulates a list of procedures but it's not really the same thing. There's restrictions on function composition that aren't intuitive. A typical task list has tons of side effects, which is not the case with your "pipe lines."

platz 10y ago

> In haskell the application has to be an elegant diamond or the thing won't even compile! Nonsense - You only have to make things as hard/elegant as you want them to be (and fore sure, some people do play that game for better/worse). But, Haskell will happily allow you throw everything in to IO; you can side-step creating a perfect model and just hack together a list of imperative IO statements. (unless you're referring to the difference between a dynlang and a static lang; that's a difference of another category altogether)

pekk 10y ago
If you are going to "throw everything in IO" then what advantage does Haskell have?
- platz 10y ago
  yes, there is a difference between "'hack' together a program" and doing proper domain modeling. However, neither should prevent the other. (i.e. "you can do X" should not be confused with "always do X"). Haskell allows you to choose. Indeed, proper domain modeling is preferred.. but it's nice to have to ability to make that choice yourself based on your own constraints. Additionally, Haskell makes it very easy/pleasant to refactor from the former to the latter. (On that note, imho the best models (in business) are arrived at iteratively rather than big-design-up-front)
- swift 10y ago
  You can refactor it later, of course. It's even possible to opt out of static type checking if you want. GHCi also provides a REPL that makes exploratory programming easy.
- tel 10y ago
  Even "just IO" in Haskell enjoys some very nice typing properties and is often easier to write and ensure proper operation than similar "just IO" programs in other languages. It's actually super pleasant!
- rs86 10y ago
  Lazyness, generic programming, algebraic datatypes, inferred typing

ngrilly 10y ago

I don't understand the downvote. The main argument looks valid: > If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally. This I believe is the main reason why Haskell or lisps haven't taken over the programming world.

platz 10y ago
I'm not the downvoter, but I still don't understand the assertion why Haskell doesn't allow the "task list". There is nothing preventing using these "task lists" (e.g. lists/steps/procedures) in Haskell. In fact, "do notation", a core language feature every beginner learns, features it.
- crimsonalucard 10y ago
  You are right, but no beginner truly understands do notation. It's just magic to them. Do notation is an abstraction on top of monads which is an incredibly hard to understand abstraction on top of functional programming. Functional programming in essence does not allow procedures, but with special incredibly complex abstractions you can simulate procedures. If you program using said abstractions I would argue that it makes functional programming even Harder to understand.
  - platz 10y ago
    Look, I'm not saying Haskell is easy to learn, it's one of the steepest learning curves I know of in programming. But I don't think do notation is what trips up beginners (not sure if this discussion is about beginners per se). It is explained by simple mechanical plug-and-chug transformations that I think beginners understand, but am willing to hear if there is evidence otherwise.. I just think it's the other things that will eventually trip them up (I was only responding to specific claims made earlier). Also, on the point of resting on abstractions being a problem, I don't find compelling, because I'm also sure that Python beginners don't understand what "class MyStuff(object):" is really doing, but if the abstraction isn't leaky try don't need to know right away, and they can delve later.

prance 10y ago

> Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. That is not what is usually meant by "expressiveness" of a language. You seem to be talking about types of languages (as in the Chomsky hierarchy), by implying that there are problems you can solve in assembler but not in Haskell. That is not the case, as both are Turing-complete (Type-0). In contrast, "expressiveness" usually refers to the "ease" (one may substitute conciseness in most cases) with which higher level concepts (abstractions) are expressible in the language, and here Haskell clearly wins against assembler, and many other popular languages.

crimsonalucard 10y ago
The set of all possible assembly instructions is bigger than the set of all possible assembly instructions that haskell can compile to. Therefore haskell is less expressive than assembly language. That is what I mean by expressive.
- prance 10y ago
  >The set of all possible assembly instructions is bigger than the set of all possible assembly instructions that haskell can compile to. No it's not. The Haskell compiler is free to use whatever assembly instructions that it sees fit to compile the Haskell program. Maybe you mean that effectively, the set of assembly programs (i.e. sequences of assembly instructions) which existing Haskell compilers happen to produce is limited. This is true. But it is also true that you can find an equivalent Haskell program for every possible assembly program, where equivalent means they exhibit the same behavior with respect to inputs and outputs. This is because both are Turing equivalent. Now, it's also true that the way two equivalent programs get to their results may differ. For example, the assembly program might be faster. However, these are non-functional properties of the programs. And you were talking explicitly about functionality, so this point doesn't count towards your argument.
  - 10y ago

jaegerpicker 10y ago

I don't believe this is true for Haskell but I'm not a great Haskell dev. I do know Ocaml (mostly F# actually but it's super close) and this isn't at all true for OCaml which has a ton in common with Haskell. In OCaml I make lists of functions as pipe based expressions, where each step in the pipeline is a function. It's incredibly easy to reason about and matches the lists of functions view of development extraordinarily well. I know Elm (a simplified version of Haskell) supports pipe based programming also. Functional languages haven't taken over because OO and Java are still the primary way of teaching beginners to code. Very few beginners start with functional programming.

crimsonalucard 10y ago
function composition sort of emulates a list of procedures but it's not really the same thing. There's restrictions on function composition that aren't intuitive. A typical task list has tons of side effects, which is not the case with your "pipe lines."