How easy is it to hire Haskell programmers

I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with. However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this. * How many applications did you get? * How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell? Thanks, Paul.

On Wed, Jun 30, 2010 at 4:34 PM, Paul Johnson
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
I guess it must be a lot easier to find applicants if you don't require them to live in the same city/country as you. Cheers, -- Felipe.

On Wed, Jun 30, 2010 at 4:34 PM, Paul Johnson
wrote: I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
I guess it must be a lot easier to find applicants if you don't require them to live in the same city/country as you.
"Objection!" My experience (circa 2005) had shown that it is easy to hire Haskell programmers (in Moscow). We've got about ten resumes from single post in FIDO conference, most of them tried Haskell for small projects and were glad to use it for paying job. Only one or two of them had substantial previous Haskell experience but all resumes were from quite capable programmers. I think "Haskell is nice to have" is a convenient filter for good programmers. At least it was then.

paul:
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
* How many applications did you get?
* How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell?
Galois has had no trouble hiring Haskell programmers for a few years now. Generally, if we advertise a position, we'll have 20-50 applicants within a few weeks, with often extremely high skill sets. I've heard anecdotes from other commercial users, with similar experiences. The open source training people are getting in Haskell seems to really be paying off. For those interested in getting hired, I'd encourage you to distinguish yourselves in the market as much as you can: write libraries and get them used by others, blog about what you're doing, be visible in the community. -- Don

It depends on the type of a position. If it is a "one-shot"/contract job then you are looking for the concrete skillset/expertise, i.e. "Haskell". For relatively longterm or permanent positions I think it is better to give a priority to smart and "getting things done" type of persons rather than specific skills. But they should have some relevant experience. For instance, if you're looking for the functional programmers, you should consider ML/SML/OCaml, Scheme, Erlang, ... (Well, in case of these two, better to check that person has some grasp of static typing :)) programmers as well. And learning (fun) should be an important aspect of the position. Regards, Zura Paul Johnson-2 wrote:
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
* How many applications did you get?
* How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell?
Thanks,
Paul. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- View this message in context: http://old.nabble.com/How-easy-is-it-to-hire-Haskell-programmers-tp29038634p... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

And learning (fun) should be an important aspect of the position. Whatever FP you're coming from, I don't think you can pick up Haskell on the job. Haskell seems to require you to disappear into a cave for a while, then again I haven't had the pleasure of working with experienced Haskell programmers.
-deech
Regards, Zura
Paul Johnson-2 wrote:
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
* How many applications did you get?
* How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell?
Thanks,
Paul. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- View this message in context: http://old.nabble.com/How-easy-is-it-to-hire-Haskell-programmers-tp29038634p... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

That's not really true. We train people at Galois in Haskell, on the job. Often they have prior FP experience, but not always. aditya.siram:
And learning (fun) should be an important aspect of the position. Whatever FP you're coming from, I don't think you can pick up Haskell on the job. Haskell seems to require you to disappear into a cave for a while, then again I haven't had the pleasure of working with experienced Haskell programmers.
-deech
Regards, Zura
Paul Johnson-2 wrote:
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
* How many applications did you get?
* How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell?
Thanks,
Paul. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- View this message in context: http://old.nabble.com/How-easy-is-it-to-hire-Haskell-programmers-tp29038634p... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Right, but I assume you have local experts who are willing to teach on
site. In most companies I've worked for there is minimal training.
Haskell really needs someone who can patiently walk alongside.
I'm picturing a non-Haskell developer getting thrown into the deep
end. Now that I think about it I think that's part of why companies
choose Java/C# etc. - they can just let Google train their people.
-deech
On Thu, Jul 1, 2010 at 12:18 PM, Don Stewart
That's not really true. We train people at Galois in Haskell, on the job. Often they have prior FP experience, but not always.
aditya.siram:
And learning (fun) should be an important aspect of the position. Whatever FP you're coming from, I don't think you can pick up Haskell on the job. Haskell seems to require you to disappear into a cave for a while, then again I haven't had the pleasure of working with experienced Haskell programmers.
-deech
Regards, Zura
Paul Johnson-2 wrote:
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
* How many applications did you get?
* How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell?
Thanks,
Paul. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- View this message in context: http://old.nabble.com/How-easy-is-it-to-hire-Haskell-programmers-tp29038634p... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/1/10 13:41 , aditya siram wrote:
I'm picturing a non-Haskell developer getting thrown into the deep end. Now that I think about it I think that's part of why companies choose Java/C# etc. - they can just let Google train their people.
...and now you know why so many programs are buggy. (says the human fuzzer) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkws15wACgkQIn7hlCsL25U8DgCeMgexWRbRqbI8pjqBlTnG+3RQ iisAnjbG0PhjHcrfxsnrkKOPNogRv58w =JOUe -----END PGP SIGNATURE-----

On Wed, 2010-06-30 at 20:34 +0100, Paul Johnson wrote:
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
We have been doing this very recently, in fact we are currently half way through interviewing.
* How many applications did you get?
* How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell?
When we are done we intend to write up a blog post more details, e.g. numbers and the range/distribution of experience among candidates. I hope that will be useful to people who are interested in hiring Haskell programmers. We don't know how many can do FizzBuzz or equivalent because we picked a shortlist before doing interviewing. In general we have been very impressed with both the number and quality of candidates. As Felipe says, not restricting to applicants in the same country helps. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On Fri, Jul 2, 2010 at 12:34 PM, Duncan Coutts
When we are done we intend to write up a blog post more details, e.g. numbers and the range/distribution of experience among candidates. I hope that will be useful to people who are interested in hiring Haskell programmers.
It would also be useful to people who are interested in being hired as a Haskell programmer, so they know where to send the hitmen, I mean, what to do to improve. -- JP Moresmau http://jpmoresmau.blogspot.com/

On 2 July 2010 11:56, JP Moresmau
On Fri, Jul 2, 2010 at 12:34 PM, Duncan Coutts
wrote: When we are done we intend to write up a blog post more details, e.g. numbers and the range/distribution of experience among candidates. I hope that will be useful to people who are interested in hiring Haskell programmers.
It would also be useful to people who are interested in being hired as a Haskell programmer, so they know where to send the hitmen,
:-)
I mean, what to do to improve.
Yes, I hope it will also serve the purpose of providing useful feedback to those people who want it. For the majority of candidates who receive rejection letters it's always going to be hard and a disappointment. Some people will want details and others will just want to forget about it. In our recent recruitment we decided to go for relatively terse letters and we will provide more information about the kind of applications we got via our blog. So people who are interested will be able to see roughly where they were in the field and what kind of decision procedures were used. I've never done recruitment before so I don't know for sure, but hopefully that is a reasonable compromise between providing no feedback and forcing candidates to read long rejection letters with too much painful detail. Duncan

On Wed, Jun 30, 2010 at 3:34 PM, Paul Johnson
I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with.
However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this.
I've had a fairly easy time of hiring Haskell programmers. However, when I do, I am actively recruiting particular candidates, who are active in the community, and who have particular skills that I am looking for rather than throwing out a net. The blogosphere, reddit, #haskell and stackoverflow all make pretty decent filters to identify and build relationships with good Haskell programmers -- especially if you are plugged into the community yourself. * How many applications did you get?
I tend to actively recruit rather than throw open the floodgates. * How many of those applicants knew what a monad is, or how to write
FizzBuzz in Haskell?
"Knowledge of Haskell" means very different things to different people. I'd be somewhat leery of blindly hiring someone based on their ability to answer a couple of pop Haskell quiz questions. A better test might be if they really understood Applicative and Traversable, or if they knew how to use hsc2hs; Talk about unboxing and when to apply strictness annotations, finger trees, stream fusion, purely functional data structures or ways to implement memoization in a purely functional setting, or how to abuse side effects to do so in a less pure way. Those are the kinds of things you get exposed to through actually using Haskell, rather than through reading a monad tutorial. -Edward Kmett

A better test might be if they really understood Applicative and Traversable, or if they knew how to use hsc2hs; Talk about unboxing and when to apply strictness annotations, finger trees, stream fusion, purely functional data structures or ways to implement memoization in a purely functional setting, or how to abuse side effects to do so in a less pure way. Those are the kinds of things you get exposed to through actually using Haskell, rather than through reading a monad tutorial.
Sonuds good. And please don't ask about specific GHC compiler flags. (I had to answer such questions once. Fortunately the other bits of the Haskell parts of the interview were more relevant.)

Edward Kmett wrote:
"Knowledge of Haskell" means very different things to different people. I'd be somewhat leery of blindly hiring someone based on their ability to answer a couple of pop Haskell quiz questions.
A better test might be if they really understood Applicative and Traversable, or if they knew how to use hsc2hs; Talk about unboxing and when to apply strictness annotations, finger trees, stream fusion, purely functional data structures or ways to implement memoization in a purely functional setting, or how to abuse side effects to do so in a less pure way. Those are the kinds of things you get exposed to through actually using Haskell, rather than through reading a monad tutorial.
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-( On the other hand, I could talk for hours about stream fusion or STM. (Hell, I've even had a go at implementing both of these; the latter made it into The Monad Reader.) All of which conclusively demonstrates... something.

On Fri, Jul 02, 2010 at 06:03:31PM +0100, Andrew Coppin wrote:
Edward Kmett wrote:
"Knowledge of Haskell" means very different things to different people. I'd be somewhat leery of blindly hiring someone based on their ability to answer a couple of pop Haskell quiz questions.
A better test might be if they really understood Applicative and Traversable, or if they knew how to use hsc2hs; Talk about unboxing and when to apply strictness annotations, finger trees, stream fusion, purely functional data structures or ways to implement memoization in a purely functional setting, or how to abuse side effects to do so in a less pure way. Those are the kinds of things you get exposed to through actually using Haskell, rather than through reading a monad tutorial.
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
On the other hand, I could talk for hours about stream fusion or STM. (Hell, I've even had a go at implementing both of these; the latter made it into The Monad Reader.) All of which conclusively demonstrates... something.
One thing it might demonstrate is the inherent deficiency of using litmus tests in evaluating applicants. -- Darrin Chandler | Phoenix BSD User Group | MetaBUG dwchandler@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation

Maybe the codebase he's hiring for makes heavy use of Applicative,
Traversable, unboxing etc.
-deech
On Fri, Jul 2, 2010 at 12:03 PM, Andrew Coppin
Edward Kmett wrote:
"Knowledge of Haskell" means very different things to different people. I'd be somewhat leery of blindly hiring someone based on their ability to answer a couple of pop Haskell quiz questions.
A better test might be if they really understood Applicative and Traversable, or if they knew how to use hsc2hs; Talk about unboxing and when to apply strictness annotations, finger trees, stream fusion, purely functional data structures or ways to implement memoization in a purely functional setting, or how to abuse side effects to do so in a less pure way. Those are the kinds of things you get exposed to through actually using Haskell, rather than through reading a monad tutorial.
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
On the other hand, I could talk for hours about stream fusion or STM. (Hell, I've even had a go at implementing both of these; the latter made it into The Monad Reader.) All of which conclusively demonstrates... something.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

aditya siram
Maybe the codebase he's hiring for makes heavy use of Applicative, Traversable, unboxing etc.
Nah, I talked to him about it last night (because like Andrew I've never really used either of those classes, though I do know what hsc2hs is, just never used it). Edward just figured that topics like that give an indication of someone's relative Haskell knowledge. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Andrew Coppin wrote:
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of.
Their main purpose is to avoid the list bias so prevalent from the Lispish side of FP. Namely, there are many different kinds of collections which can be traversed or folded in ways similar to lists, the Foldable and Traversable classes give a common interface for all those collections thereby removing the excuse of using lists because they have a nicer/more-FP interface than Set, Map, Sequence,... More abstractly, they capture essential properties of concrete functors which represent containers. So for folks who think of functors as (only) being containers, these are the methods they expect to have.
I have no idea what hsc2hs is.
One of the libraries for facilitating bindings between C and Haskell. Edward Yang is giving a general discussion[0] of the many libraries for C--Haskell binding and how they compare.
I keep hearing finger trees mentioned, but only in connection to papers that I can't access.
Check out Data.Sequence[1] and Data.FingerTree[2] for canonical examples. There's also Edward Kmett's Data.Rope[3] (not to be confused with Pierre-Etienne Meunier's Data.Rope[3']). Also, see apfelmus's post [4] about finger trees and monoids for a more general perspective. [0] http://blog.ezyang.com/2010/06/the-haskell-preprocessor-hierarchy/ [1] http://hackage.haskell.org/package/containers [2] http://hackage.haskell.org/package/fingertree [3] http://hackage.haskell.org/package/rope [3'] http://hackage.haskell.org/package/Data-Rope [4] http://apfelmus.nfshost.com/articles/monoid-fingertree.html -- Live well, ~wren

andrewcoppin:
Edward Kmett wrote:
"Knowledge of Haskell" means very different things to different people. I'd be somewhat leery of blindly hiring someone based on their ability to answer a couple of pop Haskell quiz questions.
A better test might be if they really understood Applicative and Traversable, or if they knew how to use hsc2hs; Talk about unboxing and when to apply strictness annotations, finger trees, stream fusion, purely functional data structures or ways to implement memoization in a purely functional setting, or how to abuse side effects to do so in a less pure way. Those are the kinds of things you get exposed to through actually using Haskell, rather than through reading a monad tutorial.
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-) -- Don

Don Stewart
andrewcoppin:
Edward Kmett wrote:
"Knowledge of Haskell" means very different things to different people. I'd be somewhat leery of blindly hiring someone based on their ability to answer a couple of pop Haskell quiz questions.
A better test might be if they really understood Applicative and Traversable, or if they knew how to use hsc2hs; Talk about unboxing and when to apply strictness annotations, finger trees, stream fusion, purely functional data structures or ways to implement memoization in a purely functional setting, or how to abuse side effects to do so in a less pure way. Those are the kinds of things you get exposed to through actually using Haskell, rather than through reading a monad tutorial.
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-)
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. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

ivan.miljenovic:
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-)
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.
Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-) But in this case, the OP didn't even know *about* the something. -- Don

On 3 Jul 2010, at 03:39, Don Stewart wrote:
ivan.miljenovic:
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-)
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.
Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-)
Alternatively, they're already busy contributing lots of purely functional libraries, instead of doing (still valuable) work getting C cludges working. Bob

Don Stewart wrote:
So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-)
I was about to say "yeah, but RWH isn't that good" - and then I noticed who I'm speaking to. ;-) So let me rephrase that: RWH isn't as good as I was hoping it would be. Still, since I haven't written anything better myself, I guess I don't get to criticise... In any case, surely the Typeclassopedia would be a far better place to comprehend Applicative?
Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-)
So hsc2hs is related to writing C bindings? Well, that'll be why I've never heard of it then; I don't understand C. (Nor do I particularly want to... I chose Haskell.) Besides, why in the world do Haskell libraries have to involve C? I've written and released several libraries on Hackage, none of which are in any way related to C. Not every library is just a C binding, you know...

So hsc2hs is related to writing C bindings? Well, that'll be why I've never heard of it then; I don't understand C. (Nor do I particularly want to... I chose Haskell.)
Besides, why in the world do Haskell libraries have to involve C? I've written and released several libraries on Hackage, none of which are in any way related to C. Not every library is just a C binding, you know...
I completely agree with this. Even in implementing something as complex as a refactoring tool we never once needed to touch C. (nor Applicative, for that matter :) )... Chris.

On Sat, Jul 3, 2010 at 12:30 PM, Chris BROWN
So hsc2hs is related to writing C bindings? Well, that'll be why I've never heard of it then; I don't understand C. (Nor do I particularly want to... I chose Haskell.)
Besides, why in the world do Haskell libraries have to involve C? I've written and released several libraries on Hackage, none of which are in any way related to C. Not every library is just a C binding, you know...
I completely agree with this. Even in implementing something as complex as a refactoring tool we never once needed to touch C. (nor Applicative, for that matter :) )...
As a matter of fact, all of my Haskell codes didn't even touch monads. I always tried to write code as simple as possible and as understandable as possible (mainly for teaching purposes) and not as optimized as possible. -- Mihai

Mihai Maruseac
As a matter of fact, all of my Haskell codes didn't even touch monads. I always tried to write code as simple as possible and as understandable as possible (mainly for teaching purposes) and not as optimized as possible.
I take it you don't use IO then? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/3/10 07:25 , Ivan Lazar Miljenovic wrote:
Mihai Maruseac
writes: As a matter of fact, all of my Haskell codes didn't even touch monads. I always tried to write code as simple as possible and as understandable as possible (mainly for teaching purposes) and not as optimized as possible.
I take it you don't use IO then?
You can do quite a lot with "interact". - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvaz8ACgkQIn7hlCsL25UvsgCfS3vvQ4zvauC1Qef42pVqW3s2 7J8AoNgCfP+cp+D/E5VJaVrXoEqQUIJG =zLVd -----END PGP SIGNATURE-----

Back to initial topic, I have a sudden fear: do you have to master Template Haskell so as to be regarded as a guru :-{ ? Let it be no, please, let it be no...

I suppose that what qualifies as a good Haskell candidate depends on what you are looking for in a software engineer in general. For my part, having hired engineers into various groups over the last 20+ years, I've always preferred to hire people who demonstrate a broad understanding of computing rather than a deep knowledge of the particular domain at hand. So, for example, when hiring into a C++ shop, I expect a medium level applicant to know templates, STL, iostreams, boost, etc..., but I don't expect them to be able to rattle them off off the top of their head. What I want is for them to be able to know what tools are available, when they should consider using them, and where to go get the details if they need them. An expert C++ programmer, who can rattle off complicated template structures is not that useful to me if they don't have a broader sense of what libraries are out there, or where to look, or even when to use Python (or Haskell) instead! On Jul 3, 2010, at 11:29 AM, Yves Parès wrote:
Back to initial topic, I have a sudden fear: do you have to master Template Haskell so as to be regarded as a guru :-{ ? Let it be no, please, let it be no... Well, perhaps one doesn't really want that kind of guru! I've used Template Haskell, I've written a Quasi-Quoter, but I've by no means mastered it. I've got 77 packages installed in --user above and beyond Haskell Platform and while I've not mastered all of them, what I know is what is there, and where to look when needed. I've by no means mastered the various GHC extensions, but I've written code with dependent types and know where to find the papers if I need a deeper understanding. So, I think of myself as a general programming guru - one who knows a pretty broad swath of computer science, and w.r.t. to many programing languages one who knows enough about the language and libraries to be able to find what I need to write excellent code. I suppose for Haskell I'd call myself guru-in-training. Those are the kinds of gurus (or gurus-in-training) that I've always looked to hire.
- Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/3/10 05:22 , Andrew Coppin wrote:
Besides, why in the world do Haskell libraries have to involve C? I've written and released several libraries on Hackage, none of which are in any way related to C. Not every library is just a C binding, you know...
Mainly because they're complex and already exist (and are often heavily optimized already); consider gtk2hs for the former and BLAS/LAPACK for the latter. You *really, really* don't want to have to reimplement any of those as pure Haskell, trust me on this :) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvBu4ACgkQIn7hlCsL25UYmgCcCBXIk7MY51onQ8H/jPdSE9Hg BgsAmwZFRt8ryjI+jk5K4KrzCfhSRQZn =vdia -----END PGP SIGNATURE-----

Brandon S Allbery KF8NH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/3/10 05:22 , Andrew Coppin wrote:
Besides, why in the world do Haskell libraries have to involve C? I've written and released several libraries on Hackage, none of which are in any way related to C. Not every library is just a C binding, you know...
Mainly because they're complex and already exist (and are often heavily optimized already); consider gtk2hs for the former and BLAS/LAPACK for the latter. You *really, really* don't want to have to reimplement any of those as pure Haskell, trust me on this :)
Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-) (I suppose I'm just bitter because any Haskell libraries involving C are almost guaranteed to not work on Windows...)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/3/10 05:57 , Andrew Coppin wrote:
Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-)
Who says they do, or should? AFAIK it's only done for the reasons I mentioned (or, sometimes, for library compatibility; a native XCB library has been considered, for example, but it wouldn't share state with the XCB used by OpenGL, WxWindows, or gtk2hs (to name a few) so might have interoperability problems). When possible pure Haskell is preferred, but there's a lot of complex libraries out there that one should not try to rewrite. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvCyUACgkQIn7hlCsL25UOUACeO66bd9Odm0r7cIofJk6dPN0C tWUAn2tUmZcJZnH1CQ241eTMDRfscssV =Lxt5 -----END PGP SIGNATURE-----

On 3 Jul 2010, at 11:04, Brandon S Allbery KF8NH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/3/10 05:57 , Andrew Coppin wrote:
Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-)
Who says they do, or should?
Dons rather implied it... The suggestion is that someone who hasn't used hsc2hs is an inexperienced Haskeller... I'd bet though that there are many *extremely* experienced haskellers who have never once in their life written a C binding. Bob

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/3/10 06:12 , Thomas Davie wrote:
On 3 Jul 2010, at 11:04, Brandon S Allbery KF8NH wrote:
Who says they do, or should?
Dons rather implied it... The suggestion is that someone who hasn't used hsc2hs is an inexperienced Haskeller... I'd bet though that there are many *extremely* experienced haskellers who have never once in their life written a C binding.
I wouldn't be surprised if, for the purposes of Galois, ``experienced Haskeller'' *does* include hsc2hs. For others, it might not; similar concerns apply for any other language (think library packages). - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvDeUACgkQIn7hlCsL25UI8ACfRRde3G7UG1t9Czc/jH4Ibk8+ DEYAnjItSVSTGy9IpDMADszNnBjHPYHh =Yp4z -----END PGP SIGNATURE-----

And conversely, someone who have made a C-to-Haskell binding may not be a
Haskell guru.
What about Arrows: do you think one should master them so that he could be
regarded as experienced?
It's kind of hard to put a border between casual Haskell and skilled
Haskell, since it's a very wide language and your knowledge will depend on
what you have already done.
2010/7/3 Thomas Davie
On 3 Jul 2010, at 11:04, Brandon S Allbery KF8NH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/3/10 05:57 , Andrew Coppin wrote:
Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-)
Who says they do, or should?
Dons rather implied it... The suggestion is that someone who hasn't used hsc2hs is an inexperienced Haskeller... I'd bet though that there are many *extremely* experienced haskellers who have never once in their life written a C binding.
Bob_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Yves Parès
And conversely, someone who have made a C-to-Haskell binding may not be a Haskell guru.
What about Arrows: do you think one should master them so that he could be regarded as experienced? It's kind of hard to put a border between casual Haskell and skilled Haskell, since it's a very wide language and your knowledge will depend on what you have already done.
Exactly; until I need to know something I typically don't bother really studying and learning it (e.g. iteratees: they sound cool, and I've read through the TMR paper on it, etc. but I still don't "grok" and understand them fully). As an example: until I took over graphviz, I didn't really understand combinator parsing. Now I feel I know how polyparse works fairly well, but I still have no idea how to use Parsec (either series), partially because of how complex it is compared to polyparse. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Saturday 03 July 2010 12:12:56, Thomas Davie wrote:
On 3 Jul 2010, at 11:04, Brandon S Allbery KF8NH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/3/10 05:57 , Andrew Coppin wrote:
Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-)
Who says they do, or should?
Dons rather implied it... The suggestion is that someone who hasn't used hsc2hs is an inexperienced Haskeller... I'd bet though that there are many *extremely* experienced haskellers who have never once in their life written a C binding.
Andrew Coppin:
Who says they do, or should?
Don, a few emails ago.
I think you missed a small detail there.
ivan.miljenovic:
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-)
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.
Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-)
dons was replying to *Ivan Miljenovic* here (with a smiley to remove all doubt), he was teasing [is that the entirely correct word?] Ivan a bit.
But in this case, the OP didn't even know *about* the something.
That, however, is indeed an indicator (not infallible of course). After a few years of Haskell coding, it's very unlikely that you've never heard of those tools. Cheers, Daniel

Daniel Fischer
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.
Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-)
dons was replying to *Ivan Miljenovic* here (with a smiley to remove all doubt), he was teasing [is that the entirely correct word?] Ivan a bit.
Teasing works (as the teased, I'll accept it anyway :p). As for what Don was teasing me about: lemme first finish writing all these base generic graph libraries, then I'll see about writing bindings to external C libraries for graphs, etc.!
But in this case, the OP didn't even know *about* the something.
That, however, is indeed an indicator (not infallible of course). After a few years of Haskell coding, it's very unlikely that you've never heard of those tools.
Especially if you're active in the community, etc. I mean, it's still possible to not know about hsc2hs, but it gets bandied about every now and again. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Sat, Jul 3, 2010 at 9:43 AM, Daniel Fischer
Andrew Coppin:
Who says they do, or should?
Don, a few emails ago.
I think you missed a small detail there.
ivan.miljenovic:
Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-)
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.
Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-)
dons was replying to *Ivan Miljenovic* here (with a smiley to remove all doubt), he was teasing [is that the entirely correct word?] Ivan a bit.
Ohhh, so that's the quotation being discussed? I can not speak for dons, but I understood that he meant that more bindings should be contributed, really. Don't get wrong, I love Haskell-only code, but the reality is that reinventing the wheel isn't fun most of the time. For example, I have two bindings on Hackage [1,2]. We could write a 2D physics library in pure Haskell, and I think there was a project some time ago to write a 3D one, but that's a tough job. It is difficult to get right, and difficult to be fast enough to be useful. Chipmunk already exists, uses the MIT license and is heavily optimized. The optimization package would be even easier to rewrite in pure Haskell, but if you look at the API docs [3] you'll see that the C library handles a lot of corner cases and has many knobs to get the most out of the optimization proccess. In fact, the C library was written by the authors of the optimization procedure, so it probably has very few bugs. Repeating everything in Haskell would be a pain. There are many many other useful C libraries that we should have bindings to. For example, Hackage doesn't have any MPI bindings. Could we write an MPI client in Haskell? I guess so. Is it worth it? I doubt. Cheers! [1] http://hackage.haskell.org/package/Hipmunk [2] http://hackage.haskell.org/package/nonlinear-optimization [3] http://hackage.haskell.org/packages/archive/nonlinear-optimization/0.3.2/doc... -- Felipe.

Felipe Lessa
There are many many other useful C libraries that we should have bindings to. For example, Hackage doesn't have any MPI bindings. Could we write an MPI client in Haskell? I guess so. Is it worth it?
We might get some in two weeks time <shameless plug>at AusHac!!! http://www.haskell.org/haskellwiki/AusHac2010#MPI_bindings -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Sat, Jul 3, 2010 at 10:15 AM, Ivan Lazar Miljenovic
Felipe Lessa
writes: There are many many other useful C libraries that we should have bindings to. For example, Hackage doesn't have any MPI bindings. Could we write an MPI client in Haskell? I guess so. Is it worth it?
We might get some in two weeks time <shameless plug>at AusHac!!! http://www.haskell.org/haskellwiki/AusHac2010#MPI_bindings
That's nice! There are many interesting possibilities of high-level bindings that may be explored. I've mentioned MPI because I may need such bindings in a not-so-near future. I'll also note that having many bound libraries is also an advantage for newcomers. If they see that a library they use to solve problems in other languages already has a binding for Haskell, then they are much more likely to be successful and in a shorter time. I, for one, didn't have to learn anything new at all to use Gtk2Hs (thanks, guys!). Should we have only WxWidgets bindings then I would need to learn the Wx way before writing my first graphical program. (Alas, I've never programmed with Gtk+, the C "bindings", I've learnt with Gtk# and then PyGtk.) Cheers, -- Felipe.

Brandon S Allbery KF8NH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/3/10 05:57 , Andrew Coppin wrote:
Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-)
Who says they do, or should?
Don, a few emails ago. Personally, I agree with you - certain libraries can and should use C, but by no means *all* Haskell libraries require C. (That would suggest that Haskell is kind of a pointless exercise...)

Hi, Am Samstag, den 03.07.2010, 11:15 +0100 schrieb Andrew Coppin:
(That would suggest that Haskell is kind of a pointless exercise...)
Haskell provides pointless exercises, but even these are not pointless. (SCNR) Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

Brandon S Allbery KF8NH
On 7/3/10 05:57 , Andrew Coppin wrote:
Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-)
Who says they do, or should? AFAIK it's only done for the reasons I mentioned (or, sometimes, for library compatibility; a native XCB library has been considered, for example, but it wouldn't share state with the XCB used by OpenGL, WxWindows, or gtk2hs (to name a few) so might have interoperability problems). When possible pure Haskell is preferred, but there's a lot of complex libraries out there that one should not try to rewrite. Yes, i agree.
Let us make a GTK + example, why some popular languages such as Java, Python does not rewrite the GTK+? I think the key is not which language is best language to rewrite those *complex* library, the key is we need work together! That's why Haskell build FFI to work with other language. -- Andy

Hello Andrew, Saturday, July 3, 2010, 1:57:22 PM, you wrote:
(I suppose I'm just bitter because any Haskell libraries involving C are almost guaranteed to not work on Windows...)
haskell code is easily ported between OSes, unlike C one. when i ported my application from Win to Linux, i spend one day on haskell code and 3 days on C one, despite the fact that haskell code dealed with OS interaction and C used purely for computations C works on windows as well as it works on Unix, it just need some work to be ported between OSes, and since most developers just use one OS, C code has much more chances to remain OS-specific -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Bulat Ziganshin
haskell code is easily ported between OSes, unlike C one. when i ported my application from Win to Linux, i spend one day on haskell code and 3 days on C one, despite the fact that haskell code dealed with OS interaction and C used purely for computations
Care to provide more details? This story intrigues me (even though I've never really used C that much, and would prefer to keep it that way). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Hello Ivan, Saturday, July 3, 2010, 3:24:34 PM, you wrote:
haskell code is easily ported between OSes, unlike C one. when i ported my application from Win to Linux, i spend one day on haskell code and 3 days on C one, despite the fact that haskell code dealed with OS interaction and C used purely for computations
Care to provide more details? This story intrigues me (even though I've never really used C that much, and would prefer to keep it that way).
since 2004 i'm developing FreeArc archiver, something like winzip. in 2007 i've ported it to Linux. the only Haskell part that required was my own I/O library: i developed it in 2005 since ghc doesn't supported large files and unicode filenames at that time. my library used Win-specific calls and i, naturally, required to add some Unix way to compile it - i just used standard Haskell I/O calls generally speaking, as far as your program utilizes only existing Haskell libraries, it just work. problems starts only when existing Haskell libraries can't serve your needs and you start binding to some C or OS-specific code for the C part, i have found that some APIs i've used in mingw were in fact MSVC-compatibility ones, and was absent in Linux gcc i just looked at my darcs repository. Unix-specific patches were:
added /dev/urandom as entropy source for Unix Unixifying: dir.size:=0 Added Unix support for GetPhysicalMemory, GetProcessorsCount Unix: config files in "/etc"; fixed compilation scripts Unix: look for SFX in /usr/lib Unix: UTF8 for filelist/screen/filenames/cmdline encoding Unix: getThreadCPUTime CUI: hidden password input now works on Unix too
so, the main catch for C part were OS-specific calls like GetPhysicalMemory - i spent lot of time reading mans. for Haskell part, main changes were about default directories -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/3/10 08:01 , Bulat Ziganshin wrote:
so, the main catch for C part were OS-specific calls like GetPhysicalMemory - i spent lot of time reading mans. for Haskell part, main changes were about default directories
Even without libraries, if you're writing in C it's really easy to get tripped up by different sizes of variables (is "long" 4 bytes or 8? How about "int"? Does the compiler need an option or pragma for "long long" to work? Are you secretly depending on pointers being the same size as a particular type?) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvYmgACgkQIn7hlCsL25V/LACfaCh/CEjrdv82Mf5k6ReSjNHH XbMAn1svrJ9Ico/zLr5UCxVVfASEHOFM =hYPQ -----END PGP SIGNATURE-----

Andrew Coppin
Don Stewart wrote:
So I guess that means that I don't count as a "knowledgable" Haskell programmer. :-(
RWH is free and online, and covers many useful things. There's no excuse :-)
I was about to say "yeah, but RWH isn't that good" - and then I noticed who I'm speaking to. ;-)
So let me rephrase that: RWH isn't as good as I was hoping it would be. Still, since I haven't written anything better myself, I guess I don't get to criticise...
In any case, surely the Typeclassopedia would be a far better place to comprehend Applicative?
Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-)
So hsc2hs is related to writing C bindings? Well, that'll be why I've never heard of it then; I don't understand C. (Nor do I particularly want to... I chose Haskell.)
Besides, why in the world do Haskell libraries have to involve C? Because we need to reuse those existing high-quality C library, such as GTK+ library. Because so many people into their's efforts to these C library, it's really unnecessary re-implement those *huge* C library by Haskell.
C binding perhaps not the perfect way, but it's cheapest way to fix your *real* problem. Don't tell me you want spend 10 years build Haskell Purely Graphics Toolkit even you just want do some GUI program. ;-) IMO, C is best way to handle hardware detail, that's the another reason need C binding... Cheers, -- Andy

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.

On 02/07/10 14:43, Edward Kmett wrote:
"Knowledge of Haskell" means very different things to different people. I'd be somewhat leery of blindly hiring someone based on their ability to answer a couple of pop Haskell quiz questions.
Fair enough, and I should probably have put a smiley in there. I'd also just that day read a couple of laments from hiring managers about applicants for Java jobs who *couldn't* write Fizzbuzz. I was really trying to ask about the general level of knowledge amongst the job applicants. Paul.

On Fri, 2010-07-02 at 09:43 -0400, Edward Kmett wrote:
* How many applications did you get?
I tend to actively recruit rather than throw open the floodgates.
We did that initially. We are now very pleased that we switched track to openly advertising. We've had many excellent people who applied that we either did not know or would not have thought of asking (and I like to think we know a lot of people in the community quite well). On the other hand it is certainly more work. Duncan
participants (27)
-
aditya siram
-
Alexander Solla
-
Andrew Coppin
-
Andy Stewart
-
Brandon S Allbery KF8NH
-
Bulat Ziganshin
-
Chris BROWN
-
Daniel Fischer
-
Darrin Chandler
-
Don Stewart
-
Duncan Coutts
-
Duncan Coutts
-
Edward Kmett
-
Felipe Lessa
-
Ivan Lazar Miljenovic
-
Joachim Breitner
-
JP Moresmau
-
Mark Lentczner
-
Matthias Görgens
-
Mihai Maruseac
-
Paul Johnson
-
Sean Leather
-
Serguey Zefirov
-
Thomas Davie
-
wren ng thornton
-
Yves Parès
-
Zura_