
Why I Love Haskell: An Example - apaprocki
http://thenewsh.blogspot.com/2015/04/why-i-love-haskell-example.html
======
platz
Providing type signatures on all top-level functions would've been nicer for
teaching purposes

~~~
WaxProlix
Absolutely. One of the nice things about Haskell and its type system in
general is being able to look at a function's type and induce roughly what it
does. Or, vice-versa, the ability to find pieces of functionality on hoogle by
giving a reasonable type signature for your desired code.

Skipping out on that visibility when showing how Haskell is expressive seems
like a missed opportunity.

~~~
xrstf
Is hoogle a special search engine for Haskell code or was that an
unintentional typo?

~~~
luchs
Yes, it's a special search engine:
[https://www.haskell.org/hoogle/](https://www.haskell.org/hoogle/)

You don't search for words in the documentation etc., but enter the type of
the function you want. This often works pretty well.

~~~
TJSomething
FPComplete's Hoogle is a bit more complete:
[https://www.fpcomplete.com/hoogle](https://www.fpcomplete.com/hoogle)

~~~
michaelochurch
It's good overall but sometimes the ranking is weird. For example, if you
search for "ByteString", what you'd expect is only the #3 hit.

For beginners who are likely to be searching for core libraries, the other
Hoogle might be more useful.

------
bluefox
Took 10 mins to hack a silly, inefficient version.

[https://play.golang.org/p/UPlzWR5OCO](https://play.golang.org/p/UPlzWR5OCO)

Gives the same result as [https://www.ietf.org/mail-
archive/web/tls/current/msg03416.h...](https://www.ietf.org/mail-
archive/web/tls/current/msg03416.html) SHA256 test vector.

Looks easier to understand, to me...

~~~
belovedeagle
It actually looked much more difficult to understand to me because golang just
really has no structure.

Anyways, it probably is simpler, because it doesn't solve the same problem
that the Haskell code solves. The Haskell code allows you to generate some
bytes from the infinite stream even if you don't yet know how many you need;
your go version must know how many you need before you start.

In order to do the same thing in go you're going to need to use an iterator or
a goroutine + channel. Try doing that as cleanly as the Haskell version.

~~~
azylman
This can be done very easily using an unbounded io.Reader instead of channels
or iterators.

Here's a slightly modified version of bluefox's code where the prf function
returns an unbounded io.Reader:
[https://play.golang.org/p/ZAj8q4eXEi](https://play.golang.org/p/ZAj8q4eXEi)

And here's a version that's modified a bit more, but still essentially the
same, to trade LOC for matching the spec very cleanly:
[https://play.golang.org/p/Rpy0yIwVN1](https://play.golang.org/p/Rpy0yIwVN1)

~~~
ICWiener
I don't see any kind of error handling, but if I understand correctly, in some
cases in Go it is not necessary to check for errors directly (an errorneous
output stream would do-nothing on write, for example). Do you think your
versions are fault-tolerant or is there anything you should add to gracefully
handle errors?

~~~
azylman
A Hash's Write method can't return an errors.

Writing and Reading to a pipe only errors if the pipe has been closed. We
return an io.Reader, instead of an io.ReadCloser, so consumers can't close the
Read side. Internally, the Write side is never closed either. So, in practice,
Reading and Writing also won't ever error.

------
jonnybgood
Why would this be difficult in other languages, especially other modern
languages? I wish the author expanded on it as I don't see anything special
about the use of Haskell here.

~~~
tel
Did he not?

> Haskell provided a very light-weight syntax.

> Haskell allows partial-application of functions.

> Haskell allows definitions of unbounded data structures...

> Higher-order functions like "iterate" and "map"...

> Monads allowed me to avoid having to explicitly track side effects ...
> [also] purity and strong type checking.

> Libraries of higher order functions for monads allowed me to limit the
> syntactic cost of using monads.

~~~
jonnybgood
That just tells me he did it the Haskell way. That doesn't answer the question
of why it would be more difficult in other (modern) languages.

If you're going to make an audacious claim then we need to see evidence to
support that claim. The author didn't do this. All the author did was show us
a Haskell implementation.

~~~
nothrabannosir
No, but he did say "beware, herein lies advocacy." Which is a tongue-in-cheek
version of saying "ok, I know, I didn't do my due dilligence, but it's my blog
and I love Haskell and I'm excited about this one thing I just built."

Not everything is a paper in Nature. I understand your point but he's honest
about it just being a propaganda piece.

And, frankly, what's wrong with that?

Thanks to the author for taking the time to share.

~~~
coldtea
> _And, frankly, what 's wrong with that?_

That it doesn't solve OUR problem, which is "help us chose if Haskell if
better", even though it pretends to?

~~~
tel
I don't see how it doesn't help. It might not help as much as could be asked,
but it's a cute example of "real world" Haskell use and he described the parts
of it he rather liked.

~~~
platz
Here's a follow up post from a different author, that continues on this
subject, and also explains some of the benefits of the haskell approach:
[http://nikita-volkov.github.io/a-taste-of-state-parsers-
are-...](http://nikita-volkov.github.io/a-taste-of-state-parsers-are-easy/)

------
hondo77
I salute you if you understood anything in "The Problem" section.

~~~
dopamean
This is my problem with everything I encounter when trying to learn about
Haskell. I find almost everything I come across to be completely
unapproachable. If I cant understand the problem you're solving in the blog
post then the solution makes even less sense. I don't say this as a criticism
of this author at all. It's just something I've noticed with Haskell.

~~~
jon-wood
I'm glad I'm not the only one who feels that way. I find that with many
articles on functional languages, which leaves me wondering if they attract a
certain type of person, or if they're just not well suited to the problems I
work on.

Is there anything good on doing web development in a functional style? I keep
hearing about Om and Clojurescript in relation to React, but I have no idea
where to start.

~~~
sukilot
This website is written in a Lisp dialect.

~~~
jon-wood
I'm aware of that, so clearly its possible, I just have no real idea how I'd
approach that myself.

------
Pirate-of-SV
I like Haskell because of some of the related tools.

\- HLint, a very helpful linter for ideomatic Haskell

\- QuickCheck, Fuzz-testing function's properties

\- hpc, Pretty code coverage

~~~
sgrove
I find the Haskell tooling ecosystem surprisingly terrible, given how rich the
information content of the code is. There's virtually no equivalent of most
functions from e.g. Intellij for Haskell that I know of (although I haven't
tried FPComplete's tools yet and hear good things).

The libraries you mentioned though are indeed all really fantastic, and after
learning how to use them you'll miss them dearly when they're unavailable.

~~~
platz
There are all sorts of tools, even for refactoring. Maybe not to the degree of
Java, no. Although, haskell code tends to have less boilerplate, so there is
less toolig for manipulating boilerplate. (Not to say there are other tools
that could be improved). But the situation is far from dire.

\-- Vim:

haskellmode-vim for show type and insert type, among other things.

ghcmod-vim for HLint and HCheck, also used by Syntastic and NeoComplCache.

neco-ghc uses ghcmod-vim for nifty Haskell completion, powered by
neocomplcache.

Syntastic automatic syntax checking for vim.

\--Emacs:

structured-haskell-mode: [https://github.com/chrisdone/structured-haskell-
mode](https://github.com/chrisdone/structured-haskell-mode)

haskell-emacs: [http://chrisdone.com/posts/haskell-
emacs](http://chrisdone.com/posts/haskell-emacs)

------
deeviant
Then your Haskell expert leaves and then you learn why I hate Haskell(or
insert any fringe programming language here).

~~~
sgrove
Learning Haskell isn't beyond any programmers though, and is likely to pay off
long-term. I agree that other fringe languages might have less payoff though -
Erlang/elixir, Clojure, F#/OCaml, Idris/Coq/Agda (although who would write
production code in these?) are all more likely to impart fundamental
understandings than e.g. Coffeescript, Wisp, etc.

~~~
deeviant
Learning kung fu or the violin isn't beyond most people either, but I'd rather
not have that be the prerequisite for being able to be productive on my team.

Most companies don't prioritize paying a potentially highly compensated worker
to learn an obscure language when the job can just as effectively be solved
using standard skills and languages that are much easier to acquire(hire).

Also, despite the passionate defence that many functional-first language
advocates give, I have never seen any conclusive evidence that these
languages, in general, produce better results than the standard suspects.

~~~
sacado2
This. We're still waiting for Haskell's killer app.

~~~
tome
Can you give some examples of killer apps in other languages, so I know what
sort of example you're looking for?

------
singlow
Why I Love My Left Arrow

When pressed in combination with the alt button, it can navigate back to the
previous page I was viewing. But not when someone captures onkeypress and
cancels it.

~~~
sacado2
That's because you didn't use the IO monad.

