6 ms·

I think this really gets to the core strength of Haskell, which for me has always been having code that we can rapidly prototype but migrate into production and

by rwosync 13y ago

I think this really gets to the core strength of Haskell, which for me has always been having code that we can rapidly prototype but migrate into production and have living in the codebase for a long time. I've written code in good deal of languages and haven't found a language with the power/weight ratio that Haskell has. The slight cost I have found though is that a lot of the tools he mentioned have a rather steep learning curve ( monads, parsec, repa, conduits, lens ) especially for those coming from an imperative background. But learning any of them is an investment in your programming skills that pays off ten-fold down the road.

thirsteh 13y ago
Completely agree. 9 times out 10, something compiles and works as expected, and can stay working in production for years. I don't know of any other language where I can do this and keep developing (and prototyping) the codebase. (This is not to say that testing isn't necessary--in fact Haskell offers an amazing framework for fuzz testing, QuickCheck--but 100% code coverage unit tests is a pointless endeavor in Haskell.) I will say that "rapid prototyping" of new applications is a bit tedious in Haskell (mainly because of the cabal etc. bootstrapping work you have to do), but prototyping new features in existing ones is smooth.
- gregory144 13y ago
  Why do you say that unit testing is pointless in Haskell? Edit: My bad - I missed the 100% part.
  - ehsanu1 13y ago
    thirsteh said that 100% code coverage is pointless, not that unit testing is pointless.
  - codygman 13y ago
    "100% code coverage unit tests is a pointless endeavor" Thirsteh said 100% coverage of unit tests is pointless, not that unit testing itself is pointless. I'm not totally sure what thirsteh means by "100% is a pointless endeavor" though.
  - freyrs3 13y ago
    He said that aiming for 100% code-coverage tests in Haskell is pointless, not that unit-testing itself is pointless. Which I think is a pretty reasonable given that a lot of bugs cannot exist by construction in a lot of Haskell code. Personally I very much enjoy unit-testing in Haskell especially with the new tasty library which makes combining all the Unit/QuickCheck/SmallCheck tests very pleasant. [1] http://hackage.haskell.org/package/tasty http://hackage.haskell.org/package/tasty
    - thirsteh 13y ago
      Indeed. I'm not a fan of 100% code coverage tests in any language, but it's especially apparent in Haskell where, as you said, if code compiles (and you keep most of your functions pure), there are whole classes of bugs that simply cannot exist.
- drhodes 13y ago
  For those who missed it, there's a newish project called the holy haskell project starter. It generates a skeleton project with cabal sandbox, tests and a Foo/Bar module example: http://yannesposito.com/Scratch/en/blog/Holy-Haskell-Starter/ http://yannesposito.com/Scratch/en/blog/Holy-Haskell-Starter...
- axilmar 13y ago
  > Completely agree. 9 times out 10, something compiles and works as expected, and can stay working in production for years. I don't know of any other language where I can do this and keep developing (and prototyping) the codebase. How is this even possible? Haskell can't catch the logic errors done over time and space, and these errors are the majority of errors in all programming languages, Haskell included.
  - thirsteh 13y ago
    I'm not trying to say you can't make errors in Haskell, just that, if you know what you're doing, slip-ups are extremely rare in the language. (Hence "9 times out of 10.") It's true, to some extent, with other statically checked languages, but they usually don't have separation effects, sum types, etc.
    - axilmar 13y ago
      > if you know what you're doing So it's 9 times of ten if you know what you are doing, which is hardly the most often case.
      - thirsteh 13y ago
        > So it's 9 times of ten if you know what you are doing, which is hardly the most often case. If you don't at all know what you're doing, you're gonna fail every time, anywhere. It is obviously subjective, and I don't think I implied otherwise. Do you know what sum types are? If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match? Even more so with separation of effects, and other things that only really exist in Haskell.
        axilmar 13y ago
        > If you don't at all know what you're doing, you're gonna fail every time, anywhere. Not really. In programming, most of the time you think you know what you are doing but you really don't remember all the states and all the details, which results in bugs. > Do you know what sum types are? I do. > If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match? In non object-oriented languages or in object-oriented languages without abstract methods, it's certainly possible. In object-oriented languages with abstract methods, it's not possible: for each missing case the compiler will complain with an error. > Even more so with separation of effects, and other things that only really exist in Haskell. Separation of effects doesn't really improve the situation with bugs. A bug may have its cause inside a pure computation.
QuantumChaos 13y ago
Also, it has a fairly shallow learning curve when it comes to syntax (compared to say, lisp), at least for someone coming from a C family background. I learned Haskell after a period of doing a lot of Python programming, and I find the syntax of the two very similar.
- yarrel 13y ago
  Haskell has a much more baroque syntax than Lisp and it really doesn't compare to the C family syntactically or executionally. At best it's a kind of Pythonized Prolog that thinks Perl is a model rather than a warning.
- chrismonsanto 13y ago
  I would prefer Haskell with a Lisp syntax. Haskell's syntax adds a lot of accidental complexity to the language. My #1 complaint is how infix operators can be imported and assigned precedence/associativity. It is nearly impossible for a human to parse unfamiliar code, let alone understand it. And the sheer size and complexity of the grammar also rears its head when doing non-trivial metaprogramming. We create these problems for ourselves when we write languages with complicated grammars. And for what? So people don't have to learn how to read Lisp code? A lot of the gain of Haskell is that the super strong type system constrains the form of programs, making it easier to reason about them. Well, constraining the syntax has similar benefits. One being that now my editor can more effectively "reason" about the surface syntax of a program. See Paredit, which enables functionality that isn't possible unless you can easily find the extent of an expression.
  - lgas 13y ago
    There is Liskell: https://github.com/haskell-lisp/liskell https://github.com/haskell-lisp/liskell
  - chongli 13y ago
    Lisp has a lot of syntax complexity that lies hidden under the covers. Sure, symbolic expressions appear regular and uniform but macros are often radically different from functions in syntax, despite looking otherwise identical in application. A big offender in this regard is the loop macro.

by rwosync 13y ago

thirsteh 13y ago

Completely agree. 9 times out 10, something compiles and works as expected, and can stay working in production for years. I don't know of any other language where I can do this and keep developing (and prototyping) the codebase. (This is not to say that testing isn't necessary--in fact Haskell offers an amazing framework for fuzz testing, QuickCheck--but 100% code coverage unit tests is a pointless endeavor in Haskell.) I will say that "rapid prototyping" of new applications is a bit tedious in Haskell (mainly because of the cabal etc. bootstrapping work you have to do), but prototyping new features in existing ones is smooth.

gregory144 13y ago
Why do you say that unit testing is pointless in Haskell? Edit: My bad - I missed the 100% part.
- ehsanu1 13y ago
  thirsteh said that 100% code coverage is pointless, not that unit testing is pointless.
- codygman 13y ago
  "100% code coverage unit tests is a pointless endeavor" Thirsteh said 100% coverage of unit tests is pointless, not that unit testing itself is pointless. I'm not totally sure what thirsteh means by "100% is a pointless endeavor" though.
- freyrs3 13y ago
  He said that aiming for 100% code-coverage tests in Haskell is pointless, not that unit-testing itself is pointless. Which I think is a pretty reasonable given that a lot of bugs cannot exist by construction in a lot of Haskell code. Personally I very much enjoy unit-testing in Haskell especially with the new tasty library which makes combining all the Unit/QuickCheck/SmallCheck tests very pleasant. [1] http://hackage.haskell.org/package/tasty http://hackage.haskell.org/package/tasty
  - thirsteh 13y ago
    Indeed. I'm not a fan of 100% code coverage tests in any language, but it's especially apparent in Haskell where, as you said, if code compiles (and you keep most of your functions pure), there are whole classes of bugs that simply cannot exist.
drhodes 13y ago
For those who missed it, there's a newish project called the holy haskell project starter. It generates a skeleton project with cabal sandbox, tests and a Foo/Bar module example: http://yannesposito.com/Scratch/en/blog/Holy-Haskell-Starter/ http://yannesposito.com/Scratch/en/blog/Holy-Haskell-Starter...
axilmar 13y ago
> Completely agree. 9 times out 10, something compiles and works as expected, and can stay working in production for years. I don't know of any other language where I can do this and keep developing (and prototyping) the codebase. How is this even possible? Haskell can't catch the logic errors done over time and space, and these errors are the majority of errors in all programming languages, Haskell included.
- thirsteh 13y ago
  I'm not trying to say you can't make errors in Haskell, just that, if you know what you're doing, slip-ups are extremely rare in the language. (Hence "9 times out of 10.") It's true, to some extent, with other statically checked languages, but they usually don't have separation effects, sum types, etc.
  - axilmar 13y ago
    > if you know what you're doing So it's 9 times of ten if you know what you are doing, which is hardly the most often case.
    - thirsteh 13y ago
      > So it's 9 times of ten if you know what you are doing, which is hardly the most often case. If you don't at all know what you're doing, you're gonna fail every time, anywhere. It is obviously subjective, and I don't think I implied otherwise. Do you know what sum types are? If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match? Even more so with separation of effects, and other things that only really exist in Haskell.
      - axilmar 13y ago
        > If you don't at all know what you're doing, you're gonna fail every time, anywhere. Not really. In programming, most of the time you think you know what you are doing but you really don't remember all the states and all the details, which results in bugs. > Do you know what sum types are? I do. > If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match? In non object-oriented languages or in object-oriented languages without abstract methods, it's certainly possible. In object-oriented languages with abstract methods, it's not possible: for each missing case the compiler will complain with an error. > Even more so with separation of effects, and other things that only really exist in Haskell. Separation of effects doesn't really improve the situation with bugs. A bug may have its cause inside a pure computation.

QuantumChaos 13y ago

Also, it has a fairly shallow learning curve when it comes to syntax (compared to say, lisp), at least for someone coming from a C family background. I learned Haskell after a period of doing a lot of Python programming, and I find the syntax of the two very similar.

yarrel 13y ago
Haskell has a much more baroque syntax than Lisp and it really doesn't compare to the C family syntactically or executionally. At best it's a kind of Pythonized Prolog that thinks Perl is a model rather than a warning.
chrismonsanto 13y ago
I would prefer Haskell with a Lisp syntax. Haskell's syntax adds a lot of accidental complexity to the language. My #1 complaint is how infix operators can be imported and assigned precedence/associativity. It is nearly impossible for a human to parse unfamiliar code, let alone understand it. And the sheer size and complexity of the grammar also rears its head when doing non-trivial metaprogramming. We create these problems for ourselves when we write languages with complicated grammars. And for what? So people don't have to learn how to read Lisp code? A lot of the gain of Haskell is that the super strong type system constrains the form of programs, making it easier to reason about them. Well, constraining the syntax has similar benefits. One being that now my editor can more effectively "reason" about the surface syntax of a program. See Paredit, which enables functionality that isn't possible unless you can easily find the extent of an expression.
- lgas 13y ago
  There is Liskell: https://github.com/haskell-lisp/liskell https://github.com/haskell-lisp/liskell
- chongli 13y ago
  Lisp has a lot of syntax complexity that lies hidden under the covers. Sure, symbolic expressions appear regular and uniform but macros are often radically different from functions in syntax, despite looking otherwise identical in application. A big offender in this regard is the loop macro.