5 ms·

Perhaps three things: * Haskell is (very) strongly and statically typed and Python isn't. Haskell's type system can prove the correctness of many functions at

Perhaps three things: * Haskell is (very) strongly and statically typed and Python isn't. Haskell's type system can prove the correctness of many functions at compile time. In contrast, Python usually waits until runtime to throw exceptions, even for something obvious like a syntax error. * Because the types are known, there's an incredibly powerful testing framework called QuickCheck that is capable of e.g. generating tens of thousands of valid inputs and seeing if it can automatically disprove your assertions about your code. Python's typing is insufficient for this. * Qualitatively, writing Python feels like writing instructions for computing something, and writing Haskell feels like simply describing what something is, and the system works out how to compute it for you. It often feels compelling and magical. Lastly, some tone stuff: Function pointers have nothing to do with functional programming. And why hate on a language you haven't studied? And why does there have to be a TLDR version of a mind-expanding experience like learning a new programming style? Why form a strong opinion about something you don't know in the first place, and why feel entitled to challenge someone to explain it all to you? It's pretty frustrating.

Ingon 13y ago
> Because the types are known, there's an incredibly powerful testing framework called QuickCheck that is capable of e.g. generating tens of thousands of valid inputs and seeing if it can automatically disprove your assertions about your code. Python's typing is insufficient for this. I think immutability also helps on this front.
- SamReidHughes 13y ago
  Just being statically typed helps, there's nothing particularly special about Haskell that makes QuickCheck possible.
  - coolsunglasses 13y ago
    Have you read the source to Haskell's QuickCheck? It can automatically derive automatic randomized generation of your data-types FOR you. No other generative testing library (such as for Clojure or Erlang) can do this. Further, the random data generation can be customized using the functional combinator API. Haskell QuickCheck's source code is a compelling example of what can be done with static types and typeclasses in Haskell.
    - SamReidHughes 13y ago
      > It can automatically derive automatic randomized generation of your data-types FOR you. There's nothing about Haskell (or some extension to Haskell, I presume) that makes this possible that wouldn't make this possible in other languages like C#, Java, or, with a bit more verbosity, C++. If I'm wrong, please say what it is, I'd love to know.
      - coolsunglasses 13y ago
        You're wrong and you should look into how typeclasses, derivation, SYB, and GHC generics work. That they aren't doing it is reason enough. Clojure and Erlang's QuickCheck libraries would derive Arbitrary if they could. :)
        SamReidHughes 13y ago
        I already know how they work. Still waiting for an explanation of what they can do that you couldn't do in Java or C# or (with some verbosity) C++. Edit: For example, to answer this question, you could define a type and explain how Haskell lets you automatically generate arbitrary instances of that type, where Java or C#, being as limited as you claim them to be, would be incapable of doing so. Edit: Also, Clojure and Erlang are irrelevant. My comment you originally replied to said that static typing was what makes QuickCheck possible.
        revcbh 13y ago
        Let's use circles and rectangels to motivate some analysis. In Haskell you might define: data Point = Point { x :: Float, y :: Float } deriving(Generic) data Shape = Circle { center :: Point, radius :: Float } | Rectangle { topLeft :: Point, bottomRight :: Point } deriving(Generic) In C# you could similarly define class Point { public float _x, _y; public Point(float x, float y) { _x = x; _y = y; } } interface Shape {} class Circle { public Point _center; public float _radius; public Circle(Point center, float radius) { _center = center _radius = radius } } // etc, for Rectangle ... Let's start from the C# end of things. Let's say we want to do some tests on random Shapes and that we want to get an instance of a random shape by calling Generate.random<Shape>(). There are a couple of different ways to do this. We could explicitly define a RandomShapeFactory and a RandomPointFactory and then wire those up into the Generate class. Maybe we could use reflection to dynamically generate instances of Points and Shapes from their definitions at runtime. It would probably end up looking like some combination of the two. Haskell doesn't let you magically generate random instances of Shape. The cool thing it gives is the "deriving(Generic)" part. Effectively, this causes the compiler to generate a description of Point and the Shape-Circle-Rectangle set of types. In many ways, it's like C#'s reflection. The QuickCheck library uses this reflection-like definition to generate random instances. The core functionality isn't very different, but Haskell's approach has a number of advantages. Most importantly, it's type-checked at compile-time. In the C# version, I could call Generate.random<Cat> and the code would blow up at run-time, whereas we would just get a compiler error in Haskell. The other major advantage in this case is the reduction of boiler-plate. There's no need to register factory instances inside of some singleton object at startup, the type system can infer which Generic components are needed where. C# and Haskell are both turning complete, so you can do anything in either language. Haskell makes certain types of programming more enjoyable by reducing boiler-plate and preventing annoying runtime errors. EDIT - code formatting
- coolsunglasses 13y ago
  Immutability is good but far from enough.
LeonidasXIV 13y ago
> Python usually waits until runtime to throw exceptions, even for something obvious like a syntax error. Just a nitpick, but that is not true. Well, not completely. Python combiles its code on runtime, and at that part SyntaxError exceptions are thrown. No need to actually reach the code, since the bytecode compiler traverses the whole module anyway.
silentvoice 13y ago
*Lastly, some tone stuff: Function pointers have nothing to do with functional programming. And why hate on a language you haven't studied? And why does there have to be a TLDR version of a mind-expanding experience like learning a new programming style? .... I'm loving Haskell and am using it for all sorts of things now. I think this confusion deserves to be addressed though. When people first spoke to me about functional programming, they would say things like: "It's a paradigm shift because everything is based on functions and functions are first class citizens, you can pass them around just like anything else" Unfortunately this description of functional programming only makes sense to functional programmers. As a C programmer (what I consider myself primarily) I was inclined to simply say: "So what? Functions are perfectly easy to use in C and I can also pass them around provided I'm willing to stomach a little indirection, why do I need the unfamiliar syntax of Haskell to do something I can already accomplish in C?" So I can see where the function pointer remark is coming from. It might represent a misunderstanding of functional programming, but it's a misunderstanding potentially created by uncareful exposition. In my case I was thinking exactly the same thing before I started to understand the value of FP, and having approached FP many times in the past and failed to understand the point of it, could easily lead to an attitude of: "This is needlessly complicated, time to give up."
- csense 13y ago
  > why hate on a language you haven't studied I've studied it well enough to understand its drawbacks. I don't understand Haskell's benefits very clearly, but I'm skeptical that the benefits of Haskell outweigh its drawbacks in the context it was being discussed. > "So what? Functions are perfectly easy to use in C and I can also pass them around provided I'm willing to stomach a little indirection, why do I need the unfamiliar syntax of Haskell to do something I can already accomplish in C?" So I can see where the function pointer remark is coming from. It might represent a misunderstanding of functional programming, but it's a misunderstanding It sounds like you understand exactly the mindset I have and the question I'm trying to ask. But you don't answer the question -- and neither does anybody else in this thread, even though obtaining an answer to this question was supposed to be the point of the original posting. I suppose rephrasing it should be: "What does Haskell accomplish with functions that passing around function pointers in C does not?" Your answer is, "Something totally different that I did not understand before I knew Haskell, and which I understood after I knew Haskell." This does not answer the question!
AnimalMuppet 13y ago
I'm not the guy you're replying to, but: It's going to take me months of my spare time to really get Haskell. I've got a lot going on in my life; I've got plenty of other uses for that time. If I'm going to use that time to learn Haskell, I want to know that the payoff is going to be there. And saying "once you learn it, you will become enlightened", as if Haskell were Zen Buddhism and the benefits cannot be rationally discussed, well, that's not a very useful reply. On the other hand, trying to explain to people the benefits of something they don't understand is really hard, because they don't understand it well enough to understand the benefits. I think a big part of the OP's attitude might be in response to the attitude of a number of Haskell adherents: Our language is the greatest, and if you don't get why, it's because you're ignorant. If you've looked into Haskell and still don't get it, then you must not be bright enough to see the greatness of Haskell. I exaggerate, but only a little. That kind of attitude makes the non-Haskell people resent the Haskell crowd, even if it's only a minority of the Haskell crowd that reeks of arrogance. [Edit: I should state more strongly that the arrogant types are by far the minority, especially on HN.]
- LBarret 13y ago
  it is quite well explained in pg' blub language text. The reason to learn haskell is twofold : make you a better programmer (functional programming breds good habits in any language and help you think differently about problems), learn something interesting (puzzle your brain for the pleasure of solving the puzzle).
lectrick 13y ago
Randomizing inputs is not "unit testing". Unit testing is deterministic. Similarly, type checking does not eliminate the need for unit testing. What worries me is that between type checking and thinking QuickCheck is some kind of magical logic checker (it is not), Haskell people will generally be more discouraged from writing good, valid unit tests, vs. for example Ruby people. We don't want this endgame.

Ingon 13y ago

> Because the types are known, there's an incredibly powerful testing framework called QuickCheck that is capable of e.g. generating tens of thousands of valid inputs and seeing if it can automatically disprove your assertions about your code. Python's typing is insufficient for this. I think immutability also helps on this front.

SamReidHughes 13y ago
Just being statically typed helps, there's nothing particularly special about Haskell that makes QuickCheck possible.
- coolsunglasses 13y ago
  Have you read the source to Haskell's QuickCheck? It can automatically derive automatic randomized generation of your data-types FOR you. No other generative testing library (such as for Clojure or Erlang) can do this. Further, the random data generation can be customized using the functional combinator API. Haskell QuickCheck's source code is a compelling example of what can be done with static types and typeclasses in Haskell.
  - SamReidHughes 13y ago
    > It can automatically derive automatic randomized generation of your data-types FOR you. There's nothing about Haskell (or some extension to Haskell, I presume) that makes this possible that wouldn't make this possible in other languages like C#, Java, or, with a bit more verbosity, C++. If I'm wrong, please say what it is, I'd love to know.
    - coolsunglasses 13y ago
      You're wrong and you should look into how typeclasses, derivation, SYB, and GHC generics work. That they aren't doing it is reason enough. Clojure and Erlang's QuickCheck libraries would derive Arbitrary if they could. :)
      - SamReidHughes 13y ago
        I already know how they work. Still waiting for an explanation of what they can do that you couldn't do in Java or C# or (with some verbosity) C++. Edit: For example, to answer this question, you could define a type and explain how Haskell lets you automatically generate arbitrary instances of that type, where Java or C#, being as limited as you claim them to be, would be incapable of doing so. Edit: Also, Clojure and Erlang are irrelevant. My comment you originally replied to said that static typing was what makes QuickCheck possible.
        revcbh 13y ago
        Let's use circles and rectangels to motivate some analysis. In Haskell you might define: data Point = Point { x :: Float, y :: Float } deriving(Generic) data Shape = Circle { center :: Point, radius :: Float } | Rectangle { topLeft :: Point, bottomRight :: Point } deriving(Generic) In C# you could similarly define class Point { public float _x, _y; public Point(float x, float y) { _x = x; _y = y; } } interface Shape {} class Circle { public Point _center; public float _radius; public Circle(Point center, float radius) { _center = center _radius = radius } } // etc, for Rectangle ... Let's start from the C# end of things. Let's say we want to do some tests on random Shapes and that we want to get an instance of a random shape by calling Generate.random<Shape>(). There are a couple of different ways to do this. We could explicitly define a RandomShapeFactory and a RandomPointFactory and then wire those up into the Generate class. Maybe we could use reflection to dynamically generate instances of Points and Shapes from their definitions at runtime. It would probably end up looking like some combination of the two. Haskell doesn't let you magically generate random instances of Shape. The cool thing it gives is the "deriving(Generic)" part. Effectively, this causes the compiler to generate a description of Point and the Shape-Circle-Rectangle set of types. In many ways, it's like C#'s reflection. The QuickCheck library uses this reflection-like definition to generate random instances. The core functionality isn't very different, but Haskell's approach has a number of advantages. Most importantly, it's type-checked at compile-time. In the C# version, I could call Generate.random<Cat> and the code would blow up at run-time, whereas we would just get a compiler error in Haskell. The other major advantage in this case is the reduction of boiler-plate. There's no need to register factory instances inside of some singleton object at startup, the type system can infer which Generic components are needed where. C# and Haskell are both turning complete, so you can do anything in either language. Haskell makes certain types of programming more enjoyable by reducing boiler-plate and preventing annoying runtime errors. EDIT - code formatting
coolsunglasses 13y ago
Immutability is good but far from enough.

LeonidasXIV 13y ago

> Python usually waits until runtime to throw exceptions, even for something obvious like a syntax error. Just a nitpick, but that is not true. Well, not completely. Python combiles its code on runtime, and at that part SyntaxError exceptions are thrown. No need to actually reach the code, since the bytecode compiler traverses the whole module anyway.

silentvoice 13y ago

*Lastly, some tone stuff: Function pointers have nothing to do with functional programming. And why hate on a language you haven't studied? And why does there have to be a TLDR version of a mind-expanding experience like learning a new programming style? .... I'm loving Haskell and am using it for all sorts of things now. I think this confusion deserves to be addressed though. When people first spoke to me about functional programming, they would say things like: "It's a paradigm shift because everything is based on functions and functions are first class citizens, you can pass them around just like anything else" Unfortunately this description of functional programming only makes sense to functional programmers. As a C programmer (what I consider myself primarily) I was inclined to simply say: "So what? Functions are perfectly easy to use in C and I can also pass them around provided I'm willing to stomach a little indirection, why do I need the unfamiliar syntax of Haskell to do something I can already accomplish in C?" So I can see where the function pointer remark is coming from. It might represent a misunderstanding of functional programming, but it's a misunderstanding potentially created by uncareful exposition. In my case I was thinking exactly the same thing before I started to understand the value of FP, and having approached FP many times in the past and failed to understand the point of it, could easily lead to an attitude of: "This is needlessly complicated, time to give up."

csense 13y ago
> why hate on a language you haven't studied I've studied it well enough to understand its drawbacks. I don't understand Haskell's benefits very clearly, but I'm skeptical that the benefits of Haskell outweigh its drawbacks in the context it was being discussed. > "So what? Functions are perfectly easy to use in C and I can also pass them around provided I'm willing to stomach a little indirection, why do I need the unfamiliar syntax of Haskell to do something I can already accomplish in C?" So I can see where the function pointer remark is coming from. It might represent a misunderstanding of functional programming, but it's a misunderstanding It sounds like you understand exactly the mindset I have and the question I'm trying to ask. But you don't answer the question -- and neither does anybody else in this thread, even though obtaining an answer to this question was supposed to be the point of the original posting. I suppose rephrasing it should be: "What does Haskell accomplish with functions that passing around function pointers in C does not?" Your answer is, "Something totally different that I did not understand before I knew Haskell, and which I understood after I knew Haskell." This does not answer the question!

AnimalMuppet 13y ago

I'm not the guy you're replying to, but: It's going to take me months of my spare time to really get Haskell. I've got a lot going on in my life; I've got plenty of other uses for that time. If I'm going to use that time to learn Haskell, I want to know that the payoff is going to be there. And saying "once you learn it, you will become enlightened", as if Haskell were Zen Buddhism and the benefits cannot be rationally discussed, well, that's not a very useful reply. On the other hand, trying to explain to people the benefits of something they don't understand is really hard, because they don't understand it well enough to understand the benefits. I think a big part of the OP's attitude might be in response to the attitude of a number of Haskell adherents: Our language is the greatest, and if you don't get why, it's because you're ignorant. If you've looked into Haskell and still don't get it, then you must not be bright enough to see the greatness of Haskell. I exaggerate, but only a little. That kind of attitude makes the non-Haskell people resent the Haskell crowd, even if it's only a minority of the Haskell crowd that reeks of arrogance. [Edit: I should state more strongly that the arrogant types are by far the minority, especially on HN.]

LBarret 13y ago
it is quite well explained in pg' blub language text. The reason to learn haskell is twofold : make you a better programmer (functional programming breds good habits in any language and help you think differently about problems), learn something interesting (puzzle your brain for the pleasure of solving the puzzle).

lectrick 13y ago

Randomizing inputs is not "unit testing". Unit testing is deterministic. Similarly, type checking does not eliminate the need for unit testing. What worries me is that between type checking and thinking QuickCheck is some kind of magical logic checker (it is not), Haskell people will generally be more discouraged from writing good, valid unit tests, vs. for example Ruby people. We don't want this endgame.