[cousin_it]

As a first language, I think Haskell is too safe. It forbids you from doing too many things that the computer can do. I recently talked to someone who was learning Haskell as a first language, and it was a surreal experience. It was obvious that he wasn't having fun in the sandbox, but he couldn't articulate it because he'd never been outside the sandbox.

My own first language was QBasic and I'm very happy about it. If I'd been made to suffer through parsers instead of putting colorful circles on the screen, I would think of programming as hard work, and that probably wouldn't lead to a very good career.

[kqr]

> Haskell is too safe. It forbids you from doing too many things that the computer can do.

Computers are to computing science what telescopes are to astronomy, or something. Haskell is a great language for expressing computations, the thing CS is about. It's not meant to flip bits and observe processor states and page faults, if that is your idea of fun. That's more computer engineering stuff.

But Haskell is absolutely capable of drawing pretty circles on the screen in just a couple of lines of code![1]

[1]: https://hackage.haskell.org/package/gloss-1.9.4.1/docs/Graph...

[cousin_it]

> Haskell is a great language for expressing computations, the thing CS is about.

I think Haskell is good at expressing a narrow range of ideas that, honestly, aren't all that fruitful outside the FP field. There are three main reasons why it's not a great language for expressing arbitrary algorithms:

1) It uses the pointer model instead of the integer RAM model. That leads to extra logarithmic factors.

2) Immutability. That's hypothesized to also cause extra logarithmic factors, but AFAIK that's still an open problem.

3) Non-strict evaluation. That wreaks havoc with space complexity, and compositional analysis of performance in general.

Yes, you can add epicycles to remedy these drawbacks (arrays, ST, strictness annotations). But I'd rather use a C-like language in the first place. That's closer to the "core" of CS as I understand it, and that's how most algorithm research is done.

[kqr]

All three are problems with performance on a von Neumann machine. So there are three main reasons why Haskell is not a great language for expressing high-performance computation algorithms. Since CS is a branch of maths, performance isn't that big a deal; the important thing is that the result is computable. The performance may be an interesting property, but so is line count and purity and ease of writing proofs and doing analysis on the code!

Speaking more pragmatically, outside of CS study, most of the programs I write do not require me to write high-performance algorithms – they tend to be very I/O bound, and call out to external libraries/services for the data crunching. When I need performance (because of course I do at times), there is an amazing library that lets me write C code in Haskell[1]. The fact that some sections of my program is performance critical doesn't mean I have to write the entire program in C. I can write just the performance critical parts in C.

[1]: https://github.com/fpco/inline-c/blob/master/README.md

[cousin_it]

Um, CS is totally about performance. Frigging P vs NP is about performance. Sure, there's a part that deals with computability and the halting problem, but I'm not sure Haskell is especially useful for studying that either! It can't even express the notion of "dovetailing over all possible programs" very easily :-)

Out of curiosity, what kind of CS do you mostly work with? If it falls under the umbrella of Curry-Howard, then sure, I agree with you. But CS has tons of other areas like graphics, crypto, AI... The impact of Curry-Howard related ideas on these areas has been disappointingly small, IMO.