5 ms·

> As you can probably tell - this problem doesn't even make sense in mathematical terms. Because remember, math is not an ordered execution of statements, it’s

> As you can probably tell - this problem doesn't even make sense in mathematical terms. Because remember, math is not an ordered execution of statements, it’s equality. You are not describing what to do, you’re describing what is. I think this is my fundamental concern with Haskell. "Describing what is", aka mathematics, has two fundamental problems: 1) It is hard to reason about. After all, the entirety of mathematics, including problems outstanding for hundreds of years, concern these problems. 2) Describing what is does not give you what is. In math you first describe what is, then work really hard to prove that it actually is, and after all of that work you still don't actually have the thing that is. Obviously Haskell is concerned with what actually is, and obviously the compiler can't do arbitrarily difficult mathematical analysis, so in practice you're left with a "describe what is" language that is arbitrarily less powerful than real math, and arbitrarily more concerned with laying things out so a computer can do it (being imperative, essentially). Haskell sits between pure math and imperative languages, but exactly where it sits doesn't feel elegantly prescribed to me, whereas math and imperative languages do.

nanolith 11y ago
You're right. It's not as pure as mathematics. But, it is much purer and cleaner than a lot of languages in use today. It lends itself well to translating into formal proofs, and it is a great testing bed for ideas. Haskell has a certain beauty to it that sets it apart from other languages. There is no perfect programming language, and Haskell has its weak points. However, I find that it is great for prototyping and reference designs. I can take advantage of its clarity and strong type system to build simulators for protocols, algorithms, services, and even operating systems. I can then use these simulators as integration testbeds for building solid components in lower level languages. Haskell also makes a great language for compiler writing and text processing. I think that the language fills an important niche. It's probably never going to be a mainstream language, as it does have a certain erudite aura about it, but it is a language well worth learning.
rbehrends 11y ago
I don't have so much a problem with the intent of the statement, but that it is misleading. Ordered execution is basically function composition, which is one of the most fundamental parts of math you'll learn. That function composition isn't commutative is nothing new, and it's something that mathematicians have to deal with every day (automorphism groups, linear algebra, functional analysis, the Collatz conjecture, whatever). Nor is it dangerous, and you aren't going to avoid function composition in a functional programming language, either. The reason why it can become problematic is that the simple way of having mutable state is to model it as having a huge global ball of state that just gets threaded through every function as an argument. But you don't have to do it this way, and methods have been developed to do it better. See, e.g., schemas in Z (the specification language) and its refinement calculus. That very few languages (other than Eiffel and Ada/SPARK) have tried to actively go down that path is a different issue. You can also have non-functional programming that only ever modifies a function's local state, which makes reasoning about mutability much easier. Object capability languages do this (for pretty much the obvious reasons) and ParaSail is an example of a language trying to exploit this property for concurrency. And, of course, you can do it voluntarily in any decent imperative programming language, too. You can also relax functional programming's requirement for referential transparency a bit and get other interesting trade-offs. For example, if you have write once semantics rather than full immutability, you get a different concurrency model (what several concurrent logic programming languages have tried to exploit), which is in many ways more interesting than one based on immutability. And, of course, logic programming is also an attempt of "describing what is".

nanolith 11y ago

You're right. It's not as pure as mathematics. But, it is much purer and cleaner than a lot of languages in use today. It lends itself well to translating into formal proofs, and it is a great testing bed for ideas. Haskell has a certain beauty to it that sets it apart from other languages. There is no perfect programming language, and Haskell has its weak points. However, I find that it is great for prototyping and reference designs. I can take advantage of its clarity and strong type system to build simulators for protocols, algorithms, services, and even operating systems. I can then use these simulators as integration testbeds for building solid components in lower level languages. Haskell also makes a great language for compiler writing and text processing. I think that the language fills an important niche. It's probably never going to be a mainstream language, as it does have a certain erudite aura about it, but it is a language well worth learning.

rbehrends 11y ago

I don't have so much a problem with the intent of the statement, but that it is misleading. Ordered execution is basically function composition, which is one of the most fundamental parts of math you'll learn. That function composition isn't commutative is nothing new, and it's something that mathematicians have to deal with every day (automorphism groups, linear algebra, functional analysis, the Collatz conjecture, whatever). Nor is it dangerous, and you aren't going to avoid function composition in a functional programming language, either. The reason why it can become problematic is that the simple way of having mutable state is to model it as having a huge global ball of state that just gets threaded through every function as an argument. But you don't have to do it this way, and methods have been developed to do it better. See, e.g., schemas in Z (the specification language) and its refinement calculus. That very few languages (other than Eiffel and Ada/SPARK) have tried to actively go down that path is a different issue. You can also have non-functional programming that only ever modifies a function's local state, which makes reasoning about mutability much easier. Object capability languages do this (for pretty much the obvious reasons) and ParaSail is an example of a language trying to exploit this property for concurrency. And, of course, you can do it voluntarily in any decent imperative programming language, too. You can also relax functional programming's requirement for referential transparency a bit and get other interesting trade-offs. For example, if you have write once semantics rather than full immutability, you get a different concurrency model (what several concurrent logic programming languages have tried to exploit), which is in many ways more interesting than one based on immutability. And, of course, logic programming is also an attempt of "describing what is".