Hacker News Reader

Comment by epgui | Hacker News Reader

> Haskell and Idris are beautiful and powerful, but inaccessible to most software engineers.

I don't see any fundamental reason why that should be the case. It seems to me that while it's true that most engineers would have a hard time navigating these languages today, it's mostly due to socio-historical accident. It's not because the languages are particularly difficult or arcane, it's mainly because people don't already know it, and people don't like to learn to do things differently: their experience stands in the way.

View on HN

> it's mostly due to socio-historical accident. It's not because the languages are particularly difficult or arcane, it's mainly because people don't already know it, and people don't like to learn to do things differently

I beg to differ. I studied compsci BSC at an eastern european university. The professors decided to test that theory and decided to introduce programing to everyone in our program through Haskell. Every year about 500 new students were thaught Haskell. I don’t know a single one of us who stuck with it. Probably there are a few odd ones, but if it were only a question of familiarity you would expect that more people from there would keep programing in it.

That's a response to a slightly different question. Your answer makes it clear that exposing students to a language isn't enough to make them take up a language. The original point was that Haskell isn't per se inaccessible.

It's inaccessible because it's difficult and arcane compared to languages like Python, especially at the beginner levels when you are still trying to figure out how a for-loop works, and what are variables, and so on.

OK, but now we're back full circle, and you're disagreeing with both epgui https://news.ycombinator.com/item?id=34542953 and krisoft https://news.ycombinator.com/item?id=34544130

Yeah, of course, I am. I don't see what that has to do with anything. So my point is only valid if I support someone else?

A lot of us here have read "Learn You A Haskell for a Great Good". We've used it.

It's not a socio-historical incident, and it's not just beginners who struggle with the language either.

> Yeah, of course, I am. I don't see what that has to do with anything. So my point is only valid if I support someone else?

Your point is perfectly valid. I'm just saying the thread has just become a sequence of assertions and not particularly enlightening.

If it was accessible, then exposing students to it would be enough to make them take it up, no?

No? It may not be suited to their applications (wrong tooling / libraries ), or their collaborators may not use it, or they might simply not like it

I have a similar experience at Oxford. However, the introduction course doesn't even cover IO monad and all of our code are run in repl. No wonder the students regard Haskell as impractical as they did not even write a full program in it.

Still, if they'd found that Haskell was much easier or more productive to use than other programming languages for simple computational tasks, you'd think a few of them might have googled 'how do do IO in Haskell' and gone from there.

That seems to be getting things backwards. How could they find it easier or more productive if they haven't even done IO yet?

I would say the productivity gains of Haskell are actually most transparently obvious in the case of the sort of toy algorithmic code you're likely to be writing in a compsci class.

OK. And I would say the productivity gains of Haskell are most transparently obvious in the case of the sort of highly complex, stateful, I/O-interacting code you're likely to be writing for a successful tech company.

This doesn’t match my personal experience (having worked on a Haskell web app professionally for a couple of years). GHC does have some cool features like STM, but typical stateful code tends not to be radially more concise or easier to write in Haskell than in other high level languages (compared to, say, code for traversing a binary tree, or implementing a parser combinator library). Others may have different experiences.

Our uni taught us Haskell, Prolog, C and Java. All very intensive. First it was C, then Haskell & Prolog and then Java. When I came out of uni, I wanted to use Prolog & Haskell for everything, but jobs were only in Java and C. Don’t think it’s a matter or liking them or being more productive in them; you need to earn a living.

I do see fundamental reasons. Haskell was designed from conception to be a platform for research and education. I’d say it was a wild success at those two things. Certain decisions that made it successful as a platform for research and education make it less suitable for use writing applications in industry.

The main decision I am thinking about is lazy evaluation. Lazy evaluation forces authors to write pure code, which drove Haskell’s community to build libraries that expressed effects in the type system, which made things like STM possible. If I wanted to design a Haskell-like for industry use, I would give it non-lazy evaluation (I’m not gonna say “strict” because I think the compiler should be free to omit the evaluation of any expression, but it sure would be convenient if we had more predictable performance characteristics).

I’m also not saying that you can’t use Haskell in industry. Obviously, people do that.

Having used Haskell in industry, I can say it's actually _surprisingly_ good at boring run-of-the-mill software. The strong focus on correctness and the ecosystem-wide consistency of it's core design patterns means you spend a lot less time debugging things, and a lot more time writing the thing you actually want to write.

That said, the type system _does_ stand in the way of learning it - though it's very powerful once you get your head around it - and lazy evaluation means you do spend more time than you'd generally like hunting down space leaks if you're writing the sort of code that's capable of getting space leaks.

...which is as easy as using foldl instead of foldl' instead of foldr, which to a beginner is... mildly confusing.

OCaml uses eager, not lazy evaluation but it is even less popular than Haskell. BTW, I like Haskell, but I feel like a novice, still learning, even though I wrote a Haskell book (you can read it online for free https://leanpub.com/haskell-cookbook/read).

Imo, one "fundamental" reason is that Haskell has a much smaller, nicer core than most languages, so it builds everything out of that core. For example, most languages have variable update statements in their core. Haskell defines at least two data types of "programs that have stateful variables" (ST and State). The result is that people want to see how everything is broken down into pure functions under the hood, and that means it takes more time to learn the language.

> It's not because the languages are particularly difficult or arcane, it's mainly because people don't already know it, and people don't like to learn to do things differently: their experience stands in the way.

I'm somewhat of a fan of Haskell (though its standard library is awful) and very much a fan of Idris (at the very least it's a better-Haskell, at best, dependent types!), but hard disagree.

These languages are difficult and arcane, compared to eg Python. A beginner to programming can get started with Python immediately, it reads like pseudocode.

Get started with Haskell or Idris, you quickly hit higher kinded types, monad transformers, free monads, final tagless. It's a different universe.

>Get started with Haskell or Idris, you quickly hit higher kinded types, monad transformers, free monads, final tagless. It's a different universe.

How is any new developer hitting any of these "quickly"? I'm working on a mature production codebase with plenty of advanced Haskell, and we barely have any tagless final code - much less free monads. Even HKDs and monad transformers are relatively recent additions to our toolbox that we reach for when appropriate - most of the code uses plain old datatypes and one or two concrete monad types.

My experience of learning Haskell is that many production codebases use advanced features because they are big boons to productivity, but few learning resources make reference to them. In fact, Haskell's biggest problem is probably the gap in knowledge between simple, low-productivity code written by newer developers, and the kind of code that actually goes into production with all the optional advanced features. A budding developer can easily write a whole application that never goes beyond `IO` without issue.

Alternatively, getting started with Java you quickly hit polymorphism, inheritance, getters-and-setters, and null object handling.

And yet everyone in my intro to CS class in uni managed to pick up Java within a week or two. Haskell is a bit more involved than Python, but not more involved than most languages.

Yes, Java is kind of the worst of both worlds. You have to learn new concepts and they aren't even very useful concepts.

I believe that to be mostly true for Lisp or ML-family (OCaml, ...) languages, but not for Haskell. Reasons would be: - lazy evaluation can be tricky if you work with files, you have to profile and force strict evaluation at key points to avoid memory explosion. - refactoring something to work with the IO monad is hard - typing some higher-order functions is hard

It may be subjective, but even for the syntax I felt a much stronger cognitive load working with Haskell.

Reply on news.ycombinator.com