[Haskell-cafe] How easy is it to hire Haskell programmers
ajs at 2piix.com
Fri Jul 2 23:23:06 EDT 2010
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...
More information about the Haskell-Cafe