
On Hiring Haskell People - withoutasound
http://www.well-typed.com/blog/43
======
chancho
This is an interesting read. One part jumped out at me (sorry for the long
quote)

 _The purpose of the technical problem was to assess more directly candidates
ability to write Haskell programs that can be used to solve real world
problems, where memory usage and performance are important. The problem was
all about evaluation order and memory behaviour. We started by asking
candidates to look at a short program and say what shape they would expect the
heap profile to be. That would then lead on to a discussion of what things are
evaluated at what stage and how much memory they are taking in the meantime.
For the final step we asked candidates to rewrite the program to run in
constant space. We felt overall that the technical problem was quite useful
and we allowed it to become a significant factor in our final decision making
process._

 _The choice of problem is based on our belief that a good understanding of
evaluation order is very important for writing practical Haskell programs.
People learning Haskell often have the idea that evaluation order is not
important because it does not affect the calculated result. It is no
coincidence that beginners end up floundering around with space leaks that
they do not understand._

I've written a lot of C++ and a fair amount of Haskell, and this kind
reasoning about the evaluation order and space usage of Haskell a program is
no less of a black art than pointer arithmetic or manual memory management in
C++. In both cases, it's too steep of a learning curve to just be able to
write practical programs, which is why garbage collected languages have
displaced C++ in many domains.

It's particularly damning to say that "good understanding of evaluation order
is very important for writing practical Haskell programs" because the easiest
evaluation order to understand is strict evaluation order. In that sense, lazy
evaluation is to strict evaluation as manual memory management is to garbage
collection, except that the latter is supposed to be an improvement on the
former.

~~~
prodigal_erik
I see one major difference: a Haskell program with optimization mistakes will
run slowly and waste memory, its performance will improve as you fix them, and
eventually you can stop because it's sufficient. A C++ program with any memory
mistakes whatsoever will blow up randomly, and will continue doing so after
you give up trying to make it perfect (which is hardly ever feasible) and ship
unstable crap like the rest of the industry.

~~~
cageface
That's not entirely true. A haskell program can also fail in unpredictable
ways thanks to lazy evaluation and memory exhaustion. It's probably still
easier to pinpoint the source of the problem than it is to track down memory
corruption in C++.

~~~
prodigal_erik
Yeah, it's true that performance can be so poor that the Haskell program can't
get any useful work done. I was trying to express the spectrum from "perfect"
to "tolerable" to "pretty bad" (and "unusable" does belong at the far end),
where all the old unchecked languages only offer a cliff between "perfect" and
SIGSEGV (or "random output" if you're really unlucky).

------
codexon
_The next Haskell will be strict_

-Simon Peyton Jones

[http://www.cs.nott.ac.uk/%7Egmh/appsem-
slides/peytonjones.pp...](http://www.cs.nott.ac.uk/%7Egmh/appsem-
slides/peytonjones.ppt)

The latest research fads in CS aren't always beneficial.

~~~
plinkplonk
"The next Haskell will be strict

-Simon Peyton Jones"

True, he does say that but the slides you reference show a more nuanced
position than implied by that isolated quote.

Insisting on laziness forced the Haskell designers not to add side effects,
eventually resulting in monads (slides 22 and 23), which ended up with Haskell
programs having a "thin imperative shell over a fat pure core" internal
structure. (slide 32).

SPJ _then_ concludes that (1)purity is more important than laziness, (2)the
next ML will be pure with effectful programming only via monads and (3) the
next Haskell will be strict, but still pure (slides 39 , 40). (the differences
between "the next ML" and the "next Haskell" are worth pondering)

It is _through_ insisting on laziness as default and solving some of the
problems encountered (via monads for e.g) that he arrived at the position that
"the next Haskell will be strict". He also notes some open problems with
adding laziness into a statically typed strict language (slide 40 "Still
unclear exactly how to add laziness to a strict language. For example, do we
want a type distinction between (say) a lazy Int and a strict Int?").

So yes, you are right that "The latest research fads in CS aren't always
beneficial." but in this case it seems to have been (beneficial).

As someone maintaining a 20 k+ line Haskell codebase on my "day job" ("20,000
lines of Haskell is enough to bootstrap SkyNet" - OH on Twitter), I would
appreciate a "strict-by-default-Haskell" (with an ML like module system too,
while you are at it, thanks in advance!), but really Haskell is certainly more
"beneficial" than any other language I've seen to date for certain types of
programs .

Not contradicting your position,just qualifying it a bit.

~~~
iamelgringo
_Haskell is certainly more "beneficial" than any other language I've seen to
date for certain types of programs_

Could you unpack that? I'd love to hear what types of programs Haskell
phenomenal at, in comparison to others.

~~~
plinkplonk
This (<http://news.ycombinator.com/item?id=1909331>) is what I am doing - a
"type of program" suited to Haskell, very algorithmic, lots of data munging,
distribution, parts with proofs of correctness, compiler like pieces and so
on.Can't be more specific in public - sorry about that .

As for Haskell the language vs others in general, I personally like the
combination of high abstraction, static typing and raw speed. Besides (like
lisp?) it seems to be a productivity amplifier for very small teams of very
sharp people, which is my situation.

~~~
iamelgringo
No worries, thanks.

------
noelwelsh
They were looking for someone with experience in a client-facing role, but
conducted the interview over IRC. This means they couldn't assess that
person's body language etc. An odd decision IMO.

~~~
jrockway
If Well Typed is like other consulting shops I know of, "client-facing" means
"email and IRC".

------
smackay
I am surprised that such quality control would be required with Haskell
developers. I would have thought that people with such a skillset would
clearly be sufficiently motivated and capable such that filtering based on
fairly rigorous criteria would seem to be unnecessary.

------
plesn
Maybe it would be usefull to gather this kind of commented experience about
evaluation order and memory behaviour in a little book of case studies (or
several blog posts). There are some slides by dons and book chapters in RWH,
but it is still something difficult.

