[Haskell-cafe] How easy is it to hire Haskell programmers

[Alexander Solla]

On Jul 2, 2010, at 7:08 PM, Ivan Lazar Miljenovic wrote:

> Knowing about something /= knowing how to use it.  I own and have read
> RWH, but I've never had to use hsc2hs, or Applicative, etc.

Applicative is nice.  I had to Google for hsc2hs. This is what I get  
for learning Haskell from the Haskell 98 Report and the Gentle Intro,  
and by writing programs.  I read and commented on RWH while it was in  
beta.    But I don't even know C.  As a kid, I got tripped up by =  
meaning "binds to, for now" instead of being an equivalence relation  
(though I didn't know that at the time).  As an adult, I just didn't  
care.  I studied Mathematics and Philosophy and learned how to write  
proofs in maybe 2 dozen logics and maybe 100 algebras.

This is a common problem in "rich" languages: There is more than one  
way to solve a problem, even if the algorithmic content is essentially  
the same.  The only sane way I have found to deal with this is to just  
ignore unfamiliar combinators and focus on a function definition's  
mathematical content, as much as possible.  In particular, every  
function is a many-to-one relation made from a "join" of types (in the  
lattice of types).  Haskell's rich type theory makes this easier than  
Perl or Lisp, for example.  You can often guess the right  
interpretation for a combinator merely by looking at its type, and  
mentally deriving its free theorem (or equivalently, characterizing  
its free function), which is easy with some practice.  Put another  
way, free theorems/functions are plumbing to be ignored.  The  
mathematically interesting parts of a function definition are the  
parts that aren't free, and have to be explicitly defined, often in  
terms of pairs of values.

This mathematical approach makes these sorts of litmus tests trivial,  
in the worst sense possible.  I'm not interested in memorizing  
hundreds or thousands of combinators.  That's what Google/Haddock/text  
books are for.  I had to Google to remember what FizzBuzz was, and I  
had to try GHCi to figure out of mod was named mod or %.  And with the  
right tools, I was able to solve it in under a minute.  It took about  
10 seconds to get the logic down on paper, using arrows of the  
Categorical variety.  This does not make me a Haskell n00b.

These kinds of ideas are rather subversive in a business environment.   
In my experience, businesses want to balance this sort of flexibility  
with maintaining a common body of knowledge.  This leads to those  
brutish patterns OO people seem to love.  At least functional patterns  
are expressive and often written in terms of free functions for some  
type or type class.

I remember an incident at a previous job, where a slightly more senior  
employee told me that I should be using the factory pattern instead of  
a map to traverse a list of "logic objects".  I gave him a little  
challenge.  I told him to just write up the supporting code (i.e.,  
just the class names, imports, interfaces.  No implementations.) for  
the class hierarchy while I solved the problem my way.  It would be a  
race.  10 minutes later, I was done.  Half an hour later, he came by  
my desk, looked at the logic for traversing a list of hashes and  
writing a functor into the solution space, and agreed I was right.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100702/dedcbddc/attachment.html