10 ms·

Things in Haskell which don't exist elsewhere at all

170 points by mietek 13y ago

tel 13y ago
The entirety of that thread has some very interesting discussion (http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_some_killer_libraries_and_frameworks/ http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_som...)
joe_the_user 13y ago
I played with reflection in Ruby for a short time and found it really fascinating, until I realized everything got pathologically slow quite quickly - especially if you add one reflection effect on another. All this stuff sounds cool. Is it fast and scalable?
- dmytrish 13y ago
  Generally, yes. An experienced Haskell guru can optimize the heck out of everything (see [1], for example), sometimes even beating C. But still there is a lot of traps, a lot of situations where high-level nature of the language makes writing an efficient implementation harder and obscures that (unless you're an expert in GHC internals). For example, darcs is known for accidental problems on large projects (though I can't corroborate this from my experience), maybe of algorithmic nature. From my experience: choosing a right library matters much. Choosing one numeric library from cabal instead of another had drastically boosted performance of a number-crushing task for a crypto course. A simple program using HXT (xml processing library with beautiful mind-boggling API based on arrows) has exploded on a large input. Also, I am interested pretty much what's the largest site written in Yesod/Happstack/Snap and how well they behave there (these frameworks' benchmarks are mostly good and promising). [1] - http://benchmarksgame.alioth.debian.org/u32/haskell.php http://benchmarksgame.alioth.debian.org/u32/haskell.php
- fusiongyro 13y ago
  The two things aren't especially commensurate. A lot of the fun of Haskell is type-level stuff, which is resolved by the compiler at compile-time. There are no direct run-time artifacts. Moreover, several of the things Ed talks about have to do with concurrency, which isn't even something you can do with Ruby. Speculative execution and STM both enable real multicore concurrent processing. Even if it did perform as badly as Ruby, without the GIL and with real concurrency it's in a better position. Adding complexity in the type level does have one major performance effect though, which is on compile time. Does it count as fast and scalable if the compile time reaches into the minutes? In terms of compilation time, Ruby will always beat Haskell, because it doesn't have any. This is a meaningful difference when you're trying to iterate rapidly on your webapp, but most of the web frameworks for Haskell separate out templating to help with this problem. Most people eventually complain that high-performance Haskell doesn't resemble the Haskell we're taught to program. This is less and less true as things like iteratee-based I/O and really advanced libraries like bytestring and text displace older facilities, but it is still something to think about. Haskell tends to perform well by sacrificing lots of memory. This is why you see discussion about "space leaks" rather than "memory leaks" and whatnot. There are a lot of ways to address the problems that come up, but you need to have a strong handle on the way Haskell works before you can accurately diagnose and treat the problem. This is a significant barrier to using Haskell in production. It doesn't take long to acquire the expertise to throw Ruby into production. The road with Haskell is a bit longer and a bit more taxing, because it's so very foreign.
  - danieldk 13y ago
    Haskell tends to perform well by sacrificing lots of memory. This is why you see discussion about "space leaks" rather than "memory leaks" and whatnot. I agree with your comment, but these sentences are a bit weird. Usually space leaks occur where you should have evaluated things strictly rather than lazily or the other way around. It's a bug (with the amount of memory that we have now). But I don't agree that Haskell tends to perform well by sacrificing lots of memory. For example, you mention the iteratee proposals/libraries. Iteratees are well-known to be fast and can be used to do constant-space I/O. Bytestrings are much more performant than their precursor (lists of characters, aka String), but are also not demanding in terms of memory use.
    - fusiongyro 13y ago
      Thanks for clarifying that. What I am trying to say with those two sentences is pretty unclear as worded. I'm trying to convey that the kind of Haskell you write as a beginner tends to perform well despite being wasteful. As you get better, you worry more about the waste and use more sophisticated stuff that's less wasteful. It obviously performs better, which isn't really what comes across. But it is usually a little more complex. The penalty is really slight for things like strict folds, strictness annotations and using better libraries like ByteString, but I'm sure you'll agree that it has a much more substantial effect on the look and feel of the code when you get to things like unboxing, using "raw" iteratees, and so forth.
      - chii 13y ago
        can't the same be said for pretty much any language? If you did C++, and found performance problems, you'd drop down to assembly, which imho, is even more unwieldy than using more advanced haskell libraries.
  - tome 13y ago
    > Haskell tends to perform well by sacrificing lots of memory Not more so than any other garbage-collected language
- vidarh 13y ago
  What in the world did you do? If you are defining method_missing all over the place, then yes, it will be slow, because you're effectively adding an extra indirection through an interpreted method lookup.
sspiff 13y ago
I can write libraries in COBOL and then proceed to claim "these libraries only exist in COBOL, therefore COBOL is better than other languages", which is to me exactly what this post reads like.
- jnhnum1 13y ago
  Actually, the full title is "Things I love in Haskell that don't exist elsewhere at all"
  - sspiff 13y ago
    ... followed by a list of (mostly his own) libraries, which is what my comment was getting at.
    - Doji 13y ago
      edwardkmett is a bit of a Haskell guru, so it's natural he would have a lot of his own work to point to.
      - sspiff 13y ago
        Regardless, his argument makes little sense.
        marshray 13y ago
        I eagerly await your COBOL lenses library.
        fusiongyro 13y ago
        Perhaps his "argument" doesn't make sense because it isn't an argument, it's a list of examples. Of course, insinuating that you don't trust the comment because the author points to his own libraries is a golden example of an ad-hominem fallacy, but in order for such fallacies to be relevant, this would have to be a debate, and it isn't, it's just you aimlessly complaining. If you wanted to make it into a meaningful debate, perhaps you could furnish us with a non-Haskell example of: - A differentiation library that avoids the perturbation problem at compilation time, - A library for defining compositional uniform access across structured data types, - A dependency injection framework with an algebraic basis, - A speculative evaluation library that can safely discard running processes, - A name binding library free of ordering effects While I'm quite sure with some searching you could find one or two of these, most of them depend on the strong safety guarantee provided by Haskell isolating side-effectful processing in the I/O monad. Other languages can do this (or have other ways to do this) but none are popular enough to have such a wealth of libraries as to have these problems already solved. Unless, you know, I'm factually off-base. I look forward to seeing what you have to show us.
deleted 13y ago
[deleted]
tomp 13y ago
Wow, that's awesome! Makes me really want to learn Haskell, something I have been putting off for far too long.
boothead 13y ago
The best thing that exists in Haskell and nowhere else I've found isn't a library at all: It's the experience of grubbing around in unfamiliar libraries (in my case a database lib and a visualization lib), not knowing much Haskell and struggling to get the damn thing to compile. The very first time I got the types to line up, the program ran and I had my timeseries graph from the database. This is a magical, life changing experience. Any other language I've used would have been many iterations of, "this is null", "you passed a string where it was supposed to be a list of strings" (looking at you python)! Now that I know it's possible, I much prefer to do my thinking up front, and know that there's a compiler out there that's got my back :-)
- alipang 13y ago
  That's a property of libraries as well, for instance avoiding the perturbation problem at compile time with with ekmett's AD library. Many Haskell libraries are focused on allowing you to define entities that correspond to your desired semantics, while many libs in OO-languages are just about constructing the correct object-graph that happens to give you the result you want.
  - gnuvince 13y ago
    Could you please elaborate on this perturbation problem? It's the first time I hear that term.
    - eru 13y ago
      http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differentiation/ http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differenti... was linked in the reddit comment.
- vidarh 13y ago
  I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly. I tend to prefer dynamic typing these days as a lot of what I do feels easier to achieve when I can throw something together to test ideas without thinking about types, and then refine the idea based on actually using a cobbled together prototype, and I feel static typing often got in the way of that. Especially coupled with Smalltalk style runtime inspection / modification on error (e.g. for Ruby I use "pry" which lets me drop into a shell anywhere in the program and modify or inspect state and then continue execution).
warsheep 13y ago
I've read most of LYAH, and I have no problem understanding mathematical concepts, but man, Haskell people truely don't know how to convey this "awesomeness" they keep talking about. 1. Where do you use automatic differentiation? I've done machine learning, signal processing, etc., but never even heard of it until now. Why should I care? Your pitch should include that (especially when the wikipedia article doesn't really provide real use cases). 2. What's special about lenses? I tried reading http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html http://www.haskellforall.com/2013/05/program-imperatively-us... but there's no summary of what this is about, and from the first paragraphs it seems like a Haskell workaround for setters and immutability. Again, I feel like the community is not pitching these things correctly. People like me start reading, don't understand the point of it all, and give up. And I can go on... What is the target audience of these features (or Haskell itself)? Is it people like me, or is it more hardware validation engineers, automatic proof system developers, database people? EDIT: If anyone is interested, edwardkmett has replied to me in http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_some_killer_libraries_and_frameworks/cbm1ic6 http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_som...
- mjn 13y ago
  Re: applications for automatic differentiation, there's a list of applications here: http://www.autodiff.org/?module=Applications http://www.autodiff.org/?module=Applications. That's a list for the approach generally though, not the Haskell version.
- andolanra 13y ago
  Haskell's great contributions to its users are quite often advantages conferred by the type system. A number of the libraries mentioned (e.g. ad, lens, mtl, QuickCheck, MTL, among others) are made either possible or efficient by Haskell's ability to work with static types in a sophisticated and nuanced way. Users of dynamically typed languages talk about "fighting" the type system—and yes, there can be a bit of that, espencially early on—but once you become a proficient Haskell user, you learn to use the type system and the guarantees provided you by the language to enforce properties you want to be true, and thereby effectively use the compiler as a pre-emptive, exhaustive testing mechanism for the correctness of your code. A good Haskell programmer will set up types in such a way that the logic errors of their program will be translated into type errors, so an incorrect program cannot even be compiled. So, I suppose, the target audience of Haskell is people for whom program correctness is a stronger motivation than, say, the speed gains of C/C++ or the development time increases of dynamic languages[1] or the like. (EDIT: To avoid the charge of excessive language zealotry, I should clarify that I don't think program correctness is the overriding factor in all cases, and consequently I don't think Haskell is the correct tool in all situations, as well.) [1]: I personally don't find Haskell particularly slow to develop in—in fact, I find it much faster and easier to develop in than the dynamic languages I know—but I do use it literally daily, and, to be frank, a new programmer will likely find it tricky and confusing until familiarity sets in. Similarly, Haskell can—used correctly—have spectacular performance, sometimes matching C and beating out C++, but again, it takes experience and understanding to milk the best performance out of Haskell.
33a 13y ago
There are plenty of automatic differentiation libraries out there for C++, python, Matlab etc. Not sure how you spin that as a unique feature of Haskell.
- tel 13y ago
  The Haskell type system allows for avoidance of the perturbation problem (combining mismatched infinitesimals is a type error) for one.

170 points by mietek 13y ago

tel 13y ago

The entirety of that thread has some very interesting discussion (http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_some_killer_libraries_and_frameworks/ http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_som...)

joe_the_user 13y ago

I played with reflection in Ruby for a short time and found it really fascinating, until I realized everything got pathologically slow quite quickly - especially if you add one reflection effect on another. All this stuff sounds cool. Is it fast and scalable?

dmytrish 13y ago
Generally, yes. An experienced Haskell guru can optimize the heck out of everything (see [1], for example), sometimes even beating C. But still there is a lot of traps, a lot of situations where high-level nature of the language makes writing an efficient implementation harder and obscures that (unless you're an expert in GHC internals). For example, darcs is known for accidental problems on large projects (though I can't corroborate this from my experience), maybe of algorithmic nature. From my experience: choosing a right library matters much. Choosing one numeric library from cabal instead of another had drastically boosted performance of a number-crushing task for a crypto course. A simple program using HXT (xml processing library with beautiful mind-boggling API based on arrows) has exploded on a large input. Also, I am interested pretty much what's the largest site written in Yesod/Happstack/Snap and how well they behave there (these frameworks' benchmarks are mostly good and promising). [1] - http://benchmarksgame.alioth.debian.org/u32/haskell.php http://benchmarksgame.alioth.debian.org/u32/haskell.php
fusiongyro 13y ago
The two things aren't especially commensurate. A lot of the fun of Haskell is type-level stuff, which is resolved by the compiler at compile-time. There are no direct run-time artifacts. Moreover, several of the things Ed talks about have to do with concurrency, which isn't even something you can do with Ruby. Speculative execution and STM both enable real multicore concurrent processing. Even if it did perform as badly as Ruby, without the GIL and with real concurrency it's in a better position. Adding complexity in the type level does have one major performance effect though, which is on compile time. Does it count as fast and scalable if the compile time reaches into the minutes? In terms of compilation time, Ruby will always beat Haskell, because it doesn't have any. This is a meaningful difference when you're trying to iterate rapidly on your webapp, but most of the web frameworks for Haskell separate out templating to help with this problem. Most people eventually complain that high-performance Haskell doesn't resemble the Haskell we're taught to program. This is less and less true as things like iteratee-based I/O and really advanced libraries like bytestring and text displace older facilities, but it is still something to think about. Haskell tends to perform well by sacrificing lots of memory. This is why you see discussion about "space leaks" rather than "memory leaks" and whatnot. There are a lot of ways to address the problems that come up, but you need to have a strong handle on the way Haskell works before you can accurately diagnose and treat the problem. This is a significant barrier to using Haskell in production. It doesn't take long to acquire the expertise to throw Ruby into production. The road with Haskell is a bit longer and a bit more taxing, because it's so very foreign.
- danieldk 13y ago
  Haskell tends to perform well by sacrificing lots of memory. This is why you see discussion about "space leaks" rather than "memory leaks" and whatnot. I agree with your comment, but these sentences are a bit weird. Usually space leaks occur where you should have evaluated things strictly rather than lazily or the other way around. It's a bug (with the amount of memory that we have now). But I don't agree that Haskell tends to perform well by sacrificing lots of memory. For example, you mention the iteratee proposals/libraries. Iteratees are well-known to be fast and can be used to do constant-space I/O. Bytestrings are much more performant than their precursor (lists of characters, aka String), but are also not demanding in terms of memory use.
  - fusiongyro 13y ago
    Thanks for clarifying that. What I am trying to say with those two sentences is pretty unclear as worded. I'm trying to convey that the kind of Haskell you write as a beginner tends to perform well despite being wasteful. As you get better, you worry more about the waste and use more sophisticated stuff that's less wasteful. It obviously performs better, which isn't really what comes across. But it is usually a little more complex. The penalty is really slight for things like strict folds, strictness annotations and using better libraries like ByteString, but I'm sure you'll agree that it has a much more substantial effect on the look and feel of the code when you get to things like unboxing, using "raw" iteratees, and so forth.
    - chii 13y ago
      can't the same be said for pretty much any language? If you did C++, and found performance problems, you'd drop down to assembly, which imho, is even more unwieldy than using more advanced haskell libraries.
- tome 13y ago
  > Haskell tends to perform well by sacrificing lots of memory Not more so than any other garbage-collected language
vidarh 13y ago
What in the world did you do? If you are defining method_missing all over the place, then yes, it will be slow, because you're effectively adding an extra indirection through an interpreted method lookup.

sspiff 13y ago

I can write libraries in COBOL and then proceed to claim "these libraries only exist in COBOL, therefore COBOL is better than other languages", which is to me exactly what this post reads like.

jnhnum1 13y ago
Actually, the full title is "Things I love in Haskell that don't exist elsewhere at all"
- sspiff 13y ago
  ... followed by a list of (mostly his own) libraries, which is what my comment was getting at.
  - Doji 13y ago
    edwardkmett is a bit of a Haskell guru, so it's natural he would have a lot of his own work to point to.
    - sspiff 13y ago
      Regardless, his argument makes little sense.
      - marshray 13y ago
        I eagerly await your COBOL lenses library.
      - fusiongyro 13y ago
        Perhaps his "argument" doesn't make sense because it isn't an argument, it's a list of examples. Of course, insinuating that you don't trust the comment because the author points to his own libraries is a golden example of an ad-hominem fallacy, but in order for such fallacies to be relevant, this would have to be a debate, and it isn't, it's just you aimlessly complaining. If you wanted to make it into a meaningful debate, perhaps you could furnish us with a non-Haskell example of: - A differentiation library that avoids the perturbation problem at compilation time, - A library for defining compositional uniform access across structured data types, - A dependency injection framework with an algebraic basis, - A speculative evaluation library that can safely discard running processes, - A name binding library free of ordering effects While I'm quite sure with some searching you could find one or two of these, most of them depend on the strong safety guarantee provided by Haskell isolating side-effectful processing in the I/O monad. Other languages can do this (or have other ways to do this) but none are popular enough to have such a wealth of libraries as to have these problems already solved. Unless, you know, I'm factually off-base. I look forward to seeing what you have to show us.

deleted 13y ago

[deleted]

tomp 13y ago

Wow, that's awesome! Makes me really want to learn Haskell, something I have been putting off for far too long.

boothead 13y ago

The best thing that exists in Haskell and nowhere else I've found isn't a library at all: It's the experience of grubbing around in unfamiliar libraries (in my case a database lib and a visualization lib), not knowing much Haskell and struggling to get the damn thing to compile. The very first time I got the types to line up, the program ran and I had my timeseries graph from the database. This is a magical, life changing experience. Any other language I've used would have been many iterations of, "this is null", "you passed a string where it was supposed to be a list of strings" (looking at you python)! Now that I know it's possible, I much prefer to do my thinking up front, and know that there's a compiler out there that's got my back :-)

alipang 13y ago
That's a property of libraries as well, for instance avoiding the perturbation problem at compile time with with ekmett's AD library. Many Haskell libraries are focused on allowing you to define entities that correspond to your desired semantics, while many libs in OO-languages are just about constructing the correct object-graph that happens to give you the result you want.
- gnuvince 13y ago
  Could you please elaborate on this perturbation problem? It's the first time I hear that term.
  - eru 13y ago
    http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differentiation/ http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differenti... was linked in the reddit comment.
vidarh 13y ago
I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly. I tend to prefer dynamic typing these days as a lot of what I do feels easier to achieve when I can throw something together to test ideas without thinking about types, and then refine the idea based on actually using a cobbled together prototype, and I feel static typing often got in the way of that. Especially coupled with Smalltalk style runtime inspection / modification on error (e.g. for Ruby I use "pry" which lets me drop into a shell anywhere in the program and modify or inspect state and then continue execution).

warsheep 13y ago

I've read most of LYAH, and I have no problem understanding mathematical concepts, but man, Haskell people truely don't know how to convey this "awesomeness" they keep talking about. 1. Where do you use automatic differentiation? I've done machine learning, signal processing, etc., but never even heard of it until now. Why should I care? Your pitch should include that (especially when the wikipedia article doesn't really provide real use cases). 2. What's special about lenses? I tried reading http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html http://www.haskellforall.com/2013/05/program-imperatively-us... but there's no summary of what this is about, and from the first paragraphs it seems like a Haskell workaround for setters and immutability. Again, I feel like the community is not pitching these things correctly. People like me start reading, don't understand the point of it all, and give up. And I can go on... What is the target audience of these features (or Haskell itself)? Is it people like me, or is it more hardware validation engineers, automatic proof system developers, database people? EDIT: If anyone is interested, edwardkmett has replied to me in http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_some_killer_libraries_and_frameworks/cbm1ic6 http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_som...

mjn 13y ago
Re: applications for automatic differentiation, there's a list of applications here: http://www.autodiff.org/?module=Applications http://www.autodiff.org/?module=Applications. That's a list for the approach generally though, not the Haskell version.
andolanra 13y ago
Haskell's great contributions to its users are quite often advantages conferred by the type system. A number of the libraries mentioned (e.g. ad, lens, mtl, QuickCheck, MTL, among others) are made either possible or efficient by Haskell's ability to work with static types in a sophisticated and nuanced way. Users of dynamically typed languages talk about "fighting" the type system—and yes, there can be a bit of that, espencially early on—but once you become a proficient Haskell user, you learn to use the type system and the guarantees provided you by the language to enforce properties you want to be true, and thereby effectively use the compiler as a pre-emptive, exhaustive testing mechanism for the correctness of your code. A good Haskell programmer will set up types in such a way that the logic errors of their program will be translated into type errors, so an incorrect program cannot even be compiled. So, I suppose, the target audience of Haskell is people for whom program correctness is a stronger motivation than, say, the speed gains of C/C++ or the development time increases of dynamic languages[1] or the like. (EDIT: To avoid the charge of excessive language zealotry, I should clarify that I don't think program correctness is the overriding factor in all cases, and consequently I don't think Haskell is the correct tool in all situations, as well.) [1]: I personally don't find Haskell particularly slow to develop in—in fact, I find it much faster and easier to develop in than the dynamic languages I know—but I do use it literally daily, and, to be frank, a new programmer will likely find it tricky and confusing until familiarity sets in. Similarly, Haskell can—used correctly—have spectacular performance, sometimes matching C and beating out C++, but again, it takes experience and understanding to milk the best performance out of Haskell.

33a 13y ago

There are plenty of automatic differentiation libraries out there for C++, python, Matlab etc. Not sure how you spin that as a unique feature of Haskell.

tel 13y ago
The Haskell type system allows for avoidance of the perturbation problem (combining mismatched infinitesimals is a type error) for one.