Hacker News new | ask | show | jobs
by calopetreep 4855 days ago
> Haskell is a bad choice for business simply because you limit yourself to a very small talent pool.

Actually, there are many more Haskell programmers than jobs available, so it's possible to pick and choose when hiring.

1 comments

Interesting, but how many are good enough that they make up for the handicaps of poor library support and whatever other issues people have when they use Haskell for 'real' work.

And how many are willing to stay at your company when it becomes bigger and more boring?

Many Haskell programmers come from academia, how many are willing to do boring business logic?

Not saying it's always the wrong choice, but I think there's pretty sound reasoning for avoiding esoteric languages.

Actually, I've found that Haskell libraries are absolutely fantastic- For me, its ecosystem is superior to other languages I've used, and I find libraries tend to be better designed and easier to pick up and use.

> And how many are willing to stay at your company when it becomes bigger and more boring?

I feel like this is an argument that could apply to any set of programmers- I'm not sure I see how it's relevant to Haskellers in particular.

> Many Haskell programmers come from academia, how many are willing to do boring business logic?

I don't know, but it's almost certainly non-zero. I know of a few Haskellers with PhDs working in startups.

Maybe the haskell libraries that exist are fantastic, but a non esoteric language like java will also have really solid libraries and tool chains(likely more solid) plus have lots more available libraries so you spend less time reinventing the wheel.

Theirs very few haskell programmers that are interested in doing boring work. At some point though, boring work is necessary for a business, and at that time you want to be able to hire someone to do it, which will be very difficult if the codebase is in haskell.

> you spend less time reinventing the wheel

I've found this to be totally the opposite: my time in Java is much less productive. There are many libraries in Haskell which aren't even possible to write in Java (automatic differentiation, parser combinators, lenses, etc.)

> very few haskell programmers that are interested in doing boring work

Nobody is interested in doing boring work, or it would be interesting work. Nothing to do with Haskell programmers.

Hiring (good) Haskellers is easy because there's a demand for jobs. It's as simple as that.

> There are many libraries in Haskell which aren't even possible to write in Java (automatic differentiation, parser combinators, lenses, etc.)

So you're saying Alan Turing was wrong? Publish your finding, win a Nobel Prize.

You didn't say it would be difficult, you said it wasn't possible.

Here's the breakdown:

1. Haskell is compiled into machine code.

2. Machine code doesn't care or reveal where it came from.

3. Points (1) and (2) demonstrate that any algorithm that can be written in Haskell, can also be written in machine code.

4. Therefore the claim that Haskell's libraries cannot be written in Java is false.

Turing-completeness is a red herring. All it talks about is what a machine can compute, not how. This is an important distinction because libraries can be used for things like meta-programming.

It's completely possible to have a Turing-complete method of computation that does not allow the equivalent of self-modification, for example. And then you won't be able to write a library for self-modifying code!

You can't retrofit Java with a macro system without writing a preprocessor, for example. So it is impossible to have a whole bunch of useful constructs in a library.

Essentially, as soon as you consider "self-reference"--that is, programs that depend on details of the machine itself--Turing-completeness stops mattering. And this is still important; programmers care about more than just what the program does, after all!

> So you're saying Alan Turing was wrong?

Nope! The Turing-completeness of Haskell and Java means they can both compute the same functions. However, there are certain things which are just not possible to express directly in some languages. Possible to compute, but not express directly.

Instead of Java, consider Brainfuck. It's a turing-complete language and certainly has no notion of what a function is. There's simply no way in Brainfuck to directly express that idea.

Another example, this time with Java and Haskell. In Haskell, I can write a function to add any two numbers (regardless of their type) like this:

add' :: Num a => a -> a -> a

add' x y = x + y

As far as I'm aware in Java, there's no way to write a function with a signature that says "Take two numeric arguments of any type". Certainly pre-generics, this is impossible.

Edits: markup