Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Hiring Haskell People

well-typed.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: On Hiring Haskell People

#11

Post by cageface »

prodigal_erik wrote: post #10
chancho wrote: post #2

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…

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 o…

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++.

Re: On Hiring Haskell People

#12

Post by wnoise »

chancho wrote: post #2

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…

I would actually say that pointer arithmetic and manual memory management are _easier_ than managing space by controlling evaluation order.

The real benefit of lazy-evaluation is that it decouples generation from consumption in a very thorough way. Unfortunately it often doesn't scale up as space leaks attest. I'm starting to think that in the large it should be feasible to replace it with CSP-like channels, though this is essentially boiler-plating the runtime code, it gives far more fine control.

I'd say also say that automatic memory management is similar. The downside to manual is not all the debugging difficulties per se, but the fact that you do have to decide who allocates, who deallocates, and that these decisions are highly coupled and can greatly impact the choice of feasible data structures.

Re: On Hiring Haskell People

#13

Post by tuxychandru »

abi wrote: post #6
chancho wrote: post #2

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…

Anyone know of good resources to read about evaluation order in Haskell (so we can get better at it)?

This page can be very handy to understand how a piece of code is evaluated. http://www.srcf.ucam.org/~bm380/cgi-bin/stepeval.cgi

Re: On Hiring Haskell People

#14

Post by jrockway »

noelwelsh wrote: post #5

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.

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

Re: On Hiring Haskell People

#15

Post by thesz »

prodigal_erik wrote: post #10
chancho wrote: post #2

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…

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 o…

I had to add that it is exactly my experience.

I was bitten by the space leak once or twice and my programs was useful for my colleagues despite that errors.

One great example is the model of CPU. Space leak made it to slow down quadratically - simulation_speed=O(1/simulated_time^2). It took a second for 5000 cycles and couple of hours for 100000. But all interesting effects about CPU execution could be discovered in 5000-20000 cycles - inner loops of various use cases. So you have to wait about minute or so to see what is good and what is not.

Re: On Hiring Haskell People

#16

Post by iamelgringo »

plinkplonk wrote: post #8
codexon wrote: post #3

The next Haskell will be strict -Simon Peyton Jones http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.pp... The latest research fads in CS aren't always beneficial.

"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)…

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.

Re: On Hiring Haskell People

#17

Post by plinkplonk »

iamelgringo wrote: post #16
plinkplonk wrote: post #8

Earlier quoted context omitted.

"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)…

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.

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.

Re: On Hiring Haskell People

#18

Post by 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.

Re: On Hiring Haskell People

#19

Post by 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.

Re: On Hiring Haskell People

#20

Post by chc »

prodigal_erik wrote: post #10
chancho wrote: post #2

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…

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 o…

Unless you're running 64-bit, a program's memory space is not only finite but relatively minuscule, and exhausting it through wasted memory is definitely a possibility.
Post reply on HN