4 ms·

A different way of thinking of abstraction or just a feeling of elegance or a feeling of power is not a sufficient explanation for why Haskell is so great. Peo

A different way of thinking of abstraction or just a feeling of elegance or a feeling of power is not a sufficient explanation for why Haskell is so great. People want definitive and theoretically correct answers not talking points for a philosophical debate on programming styles. Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences.

solomonb 7y ago
Why does "Typed Functional Programming" have to be measurably "better" then OOP or procedural programming in order for Haskell to be considered a good language? All those questions at the end of your comment can be turned around the other way and are equally valid and unanswerable.
- crimsonalucard 7y ago
  Why use it if it's not measure-ably better on some metric? It's important because we should only use things if they are better or the same. Not if they are worse. Sure, there are tradeoffs but if you quantify all tradeoffs something usually comes out better.
  - bawolff 7y ago
    If you can objectively measure the quality of a program (in a non-bs) way, you could probably make millions. There are whole industries around code health metrics.
    - crimsonalucard 7y ago
      I doubt I could make billions. I don't think it's that hard.
dpatru 7y ago
> Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences. Functional code tends to be shorter than procedural code. This allows you to think in bigger steps. For example, to read whitespace-separated numbers from stdin and print out their sum, in haskell you could write: main = interact $ show . sum . map read . words This uses very generic haskell functions to put the input into a list of strings, read each string as a number, sum the numbers and show the sum as a string. It seems to me that the equivalent procedural code would be much longer. Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense. For example, if you leave out the "read" function above, you would be trying to sum strings instead of numbers. Haskell's type checker would complain at compile time. This enables you to program at a high level without having to debug run-time errors because of type mistakes.
- crimsonalucard 7y ago
  >Functional code tends to be shorter than procedural code Shorter is one metric that FP "tends" to be better at. But it's not definitive. Who says procedural programs can't be shorter? And also is shorter necessarily better? Also does it come at the cost of readability? Actually let's not get into readability as it's not exactly measure-able. >Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense. Algebraic Type systems are indeed a measure-able metric when you measure correctness, amount of errors or total possible programs you can write. It restricts the code you can compile to be correct from a typed perspective. Meaning that out of all the possible programs you can write, Haskell allows you to write less programs in the sense that it stops you from writing certain incorrect programs. However, ADT's can be used in procedural programs or OOP programs as well. See Rust. What I want to know is specifically about the functional programs. In the functional programming paradigm what is the quantify-able metric that makes it definitively better?
  - nimih 7y ago
    > In the functional programming paradigm what is the quantify-able metric that makes it definitively better? It seems extremely unlikely that you'll ever find a satisfactory answer to this, because any advantage a programming language paradigm gives you is either going to be in terms of programming language theory (which you rejected up-thread), or in terms of developer experience and productivity (whatever _that_ means). However, any rigorous study of those latter categories is likely going to be seriously confounded by their variability due to things which are _not_ related to language paradigm, such as organizational concerns, the language's tooling and ecosystem, the problem domain, the skill and experience of individual developers, &c &c. None of these things is straightforward to control for, and I'd be extremely skeptical of any quantifiable metric someone shows me that purports to show clear wins in real-world software development based on language paradigm of all things.
eyegor 7y ago
Definitive answer: sum/union types [0] and currying/partial function application [1]. Between the two, almost anything you write becomes very easy to adapt to new requirements. Anyone who has done a medium to large scale fp project can attest to this. If you want to be pedantic, currying and partial application are separate concepts, but I've never seen an fp lang implement one without the other. Note that I linked to this f# blog because I think its example-forward approach is clearer than most fp documentation I've read. [0] https://fsharpforfunandprofit.com/posts/discriminated-unions/ https://fsharpforfunandprofit.com/posts/discriminated-unions... [1] https://fsharpforfunandprofit.com/posts/currying/ https://fsharpforfunandprofit.com/posts/currying/
leshow 7y ago
Sum and product types are essential for programming. After you have used a language with them you will miss them dearly in any other language you use. Typeclasses and traits (if you're writing Rust) coupled with ad hoc polymorphism are a succinct and beautiful method of abstraction. You will miss them also in almost any other language. Those features in a language (functional or not) will let you confidently refactor code, and (IMO) will lead to less mistakes and better abstractions.
- deleted 7y ago
  [deleted]

solomonb 7y ago

Why does "Typed Functional Programming" have to be measurably "better" then OOP or procedural programming in order for Haskell to be considered a good language? All those questions at the end of your comment can be turned around the other way and are equally valid and unanswerable.

crimsonalucard 7y ago
Why use it if it's not measure-ably better on some metric? It's important because we should only use things if they are better or the same. Not if they are worse. Sure, there are tradeoffs but if you quantify all tradeoffs something usually comes out better.
- bawolff 7y ago
  If you can objectively measure the quality of a program (in a non-bs) way, you could probably make millions. There are whole industries around code health metrics.
  - crimsonalucard 7y ago
    I doubt I could make billions. I don't think it's that hard.

dpatru 7y ago

> Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences. Functional code tends to be shorter than procedural code. This allows you to think in bigger steps. For example, to read whitespace-separated numbers from stdin and print out their sum, in haskell you could write: main = interact $ show . sum . map read . words This uses very generic haskell functions to put the input into a list of strings, read each string as a number, sum the numbers and show the sum as a string. It seems to me that the equivalent procedural code would be much longer. Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense. For example, if you leave out the "read" function above, you would be trying to sum strings instead of numbers. Haskell's type checker would complain at compile time. This enables you to program at a high level without having to debug run-time errors because of type mistakes.

crimsonalucard 7y ago
>Functional code tends to be shorter than procedural code Shorter is one metric that FP "tends" to be better at. But it's not definitive. Who says procedural programs can't be shorter? And also is shorter necessarily better? Also does it come at the cost of readability? Actually let's not get into readability as it's not exactly measure-able. >Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense. Algebraic Type systems are indeed a measure-able metric when you measure correctness, amount of errors or total possible programs you can write. It restricts the code you can compile to be correct from a typed perspective. Meaning that out of all the possible programs you can write, Haskell allows you to write less programs in the sense that it stops you from writing certain incorrect programs. However, ADT's can be used in procedural programs or OOP programs as well. See Rust. What I want to know is specifically about the functional programs. In the functional programming paradigm what is the quantify-able metric that makes it definitively better?
- nimih 7y ago
  > In the functional programming paradigm what is the quantify-able metric that makes it definitively better? It seems extremely unlikely that you'll ever find a satisfactory answer to this, because any advantage a programming language paradigm gives you is either going to be in terms of programming language theory (which you rejected up-thread), or in terms of developer experience and productivity (whatever _that_ means). However, any rigorous study of those latter categories is likely going to be seriously confounded by their variability due to things which are _not_ related to language paradigm, such as organizational concerns, the language's tooling and ecosystem, the problem domain, the skill and experience of individual developers, &c &c. None of these things is straightforward to control for, and I'd be extremely skeptical of any quantifiable metric someone shows me that purports to show clear wins in real-world software development based on language paradigm of all things.

eyegor 7y ago

Definitive answer: sum/union types [0] and currying/partial function application [1]. Between the two, almost anything you write becomes very easy to adapt to new requirements. Anyone who has done a medium to large scale fp project can attest to this. If you want to be pedantic, currying and partial application are separate concepts, but I've never seen an fp lang implement one without the other. Note that I linked to this f# blog because I think its example-forward approach is clearer than most fp documentation I've read. [0] https://fsharpforfunandprofit.com/posts/discriminated-unions/ https://fsharpforfunandprofit.com/posts/discriminated-unions... [1] https://fsharpforfunandprofit.com/posts/currying/ https://fsharpforfunandprofit.com/posts/currying/

leshow 7y ago

Sum and product types are essential for programming. After you have used a language with them you will miss them dearly in any other language you use. Typeclasses and traits (if you're writing Rust) coupled with ad hoc polymorphism are a succinct and beautiful method of abstraction. You will miss them also in almost any other language. Those features in a language (functional or not) will let you confidently refactor code, and (IMO) will lead to less mistakes and better abstractions.

deleted 7y ago
[deleted]