Things in Haskell which don't exist elsewhere at all

http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_some_killer_libraries_and_frameworks/cbldpgy

by mietek • 13 years ago

170 87 13 years ago

tel16• 13 years ago

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

joe_the_user• 13 years 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• 13 years 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

fusiongyro4• 13 years 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.

microtonal• 13 years 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.

tome2• 13 years ago

Haskell tends to perform well by sacrificing lots of memory

Not more so than any other garbage-collected language

vidarh11• 13 years ago

several of the things Ed talks about have to do with concurrency, which isn't even something you can do with Ruby.

Concurrency has always been possible to do with Ruby just fine. There's just been a limit on system level threads until 1.9 (and there still is a limitation in terms of the interpreter lock). There's on the other hand nothing that has ever stopped us from multi-process concurrency, including using shared memory (though with the caveat that Ruby won't let us put Ruby objects there).

vidarh11• 13 years 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.

sspiff5• 13 years 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• 13 years ago

Actually, the full title is "Things I love in Haskell that don't exist elsewhere at all"

sspiff5• 13 years ago

... followed by a list of (mostly his own) libraries, which is what my comment was getting at.

fusiongyro4• 13 years ago

That's pretty ungenerous of you. There are factual differences between languages, and Ed's list is full of illuminating examples. You've wandered into a conversation on /r/haskell between Haskell users about why they like Haskell. It's insane to expect them to be less excited or biased.

sspiff5• 13 years ago

I'm not complaining about /r/haskell posters making pro-Haskell posts. I'm guilty of similar things.

I'm just not sure what it's doing on the HN front page, and I find the contents of the post lacking in terms of convincing outsiders into a favourable opinion on the language.

There's nothing wrong with such a comment on /r/haskell, but I think it's out of place here. I realize the fact that it is voted up to the front page proves that many people think otherwise, but when I last checked, people were allowed to voice contrary opinions on the Internet.

mbrock• 13 years ago

No, you've exactly missed the point of the thread and of Kmett's reply. Every single thing he lists (except perhaps the containers library) uses some unique features of Haskell, or is uniquely well done in their Haskell implementations. Read it again!

vidarh11• 13 years ago

Maybe, but the response doesn't really explain for most of the cases why that is the case or why we should care for anyone that doesn't already use Haskell.

dasil003• 13 years ago

Yes, if we only look at things with a naive high-level generalization then we can force anything to be constrained by our existing world-view. However, as it turns out, there are some details worth paying attention to here.

tomp• 13 years ago

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

boothead4• 13 years 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• 13 years 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• 13 years ago

Could you please elaborate on this perturbation problem? It's the first time I hear that term.

vidarh11• 13 years 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).

mietek• 13 years 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.

When do you determine you've gotten it to execute correctly? Achievement Unlocked: You Can Stop Testing Now?

tel16• 13 years ago

I think it's a genuine weakness of static types that they inhibit prototyping when you first begin. HM type systems tend to be liberal and powerful enough that once you learn them well they're easier to prototype in—but that comes with time.

In particular, type-driven-development is wonderful. You can write light, compiler-checked specifications of code you haven't bothered to write yet and see if your logic all typechecks even without implementation. I can run through lots of ideas that way very quickly since the only thing I have to produce is the high-level type skeleton of my program.

Then I just go through and implement it all.

It's a lot like test driven development except that your executable tests are much more lightweight and carry a strong sense of the logic of your program. If your tests don't hang together, you'll find out eventually. If your types don't hang together, your compiler tells you immediately.

dllthomas2• 13 years ago

I think better guidance and inspection in figuring out type errors would be of huge value in Haskell.

6d0debc071• 13 years ago

Any other language I've used

Have you tried Lisp? I've always found that to be a really friendly environment when it comes to working out why something doesn't work. :)

tel16• 13 years ago

Haskell doesn't need to provide a nice environment for working out why something didn't work—the compiler tends to just tell you precisely why your program isn't working. It's a bit cryptic to learn its language to start, but I seriously executed a 10 module refactoring yesterday by just going in, changing the core code, and then letting the compiler spit out a categorical list of each place that broke and the exact fix needed.

Edit: that said, it still has one. GHCi is a nice Repl.

nawitus3• 13 years ago

Isin't that true for statically typed languageS?

boothead4• 13 years ago

Partially, but not the the same level as Haskell. It's pretty easy to get broken code past the compiler in C# for example.

dragonwriter• 13 years ago

Its not in generally; statically-typed languages (e.g., C, C++, Java) make impossible certain classes of runtime errors that occur in dynamically-typed languages, but don't actually reduce the need to test each path through the code you've written to assure correct results, nor do they reduce the number of defined paths through the code assuming that the defined interface is adhered to (they make it impossible to not adhere to certain parts of the advertised interface, but even in a dynamic language you don't need to test undefined cases, as there is nothing to verify, so that doesn't actually narrow the test surface.)

Haskell's type system and syntax are richer in ways which I think makes it possible to unambiguously describe more results in code in ways which makes unit testing certain aspects superfluous. I'm skeptical of most "you don't have to test" claims, but I can see more of a case for reducing the need for testing with Haskell than with many other statically-typed languages.

arh68• 13 years ago

Though it won't surprise you, OCaml development is very similar. You're right: it's like shining a UV light on my code and seeing all the type mismatch bugs.

warsheep• 13 years 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-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_som...

mjn• 13 years ago

Re: applications for automatic differentiation, there's a list of applications here: http://www.autodiff.org/?module=Applications. That's a list for the approach generally though, not the Haskell version.

andolanra• 13 years 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.

tel16• 13 years ago

Lenses begin with getting and setting. Since Haskell is immutable, setting is a little different—it's a method of quickly generating a mutation function for a type. Lenses keep getting and setting bound together as a first-class value which creates the idea of it being a value representing a "focus" on a particular field in a complex, nested value.

Then you can compose these lenses together and retain these properties. You can also pick lenses which operate with different multiplicities from 0 to infinity. Finally, you can use their seemless connection to object isomorphisms to create a very general interface for working with various kinds of "similar" objects in Haskell.

At the end of the day you can write a first-class lens which represents getting and setting over a set of parameterized Map keys deeply inside of a stateful computation, mapping over anything that looks like a string, and viewing/modifying it as decoded JSON.

   obj . ix "aKey" . each . _Object . ix "3" . _Number .~ 4

might modify a record in a type like this

   IsString s => SomeState { obj :: Map s s }

where the string values of the Map have a JSON schema like

   {"1" ..., "2" ..., "3": <aNumber> }

bjourne3• 13 years ago

But you haven't presented anything that is special about lenses. For example, your lens expression would be trivially translated to this Python:

    for o in obj["aKey"]: o["3"] = 4

The OP:s point was that lenses seem like a workaround for Haskell's lack of mutable state.

EDIT: What I'm meaning is that to show lenses unique benefits, you would have to come up with an example in which the code is more succinct than the equivalent code implemented without lenses in another language.

33a• 13 years 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.

tel16• 13 years ago

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

Things in Haskell which don't exist elsewhere at all

Related Stories