Comment by ebingdom | Hacker News Reader

Comment by ebingdom | Hacker News Reader

Parent Full thread

> I strongly dislike Haskell's focus on theory.

First of all, I completely understand where you're coming from.

But the fact that Haskell embraces computer science, unlike most other programming language communities, is what attracts me to it the most. I can geek out about the mathematics that leads to simpler, safer software with like-minded people. I am always learning from Haskellers more than from any other programmers.

But it does take a lot of learning and unlearning to become a fluent functional programmer. This isn't because functional programming is more complicated than other paradigms (au contraire), it's because schools and universities have been mostly teaching OOP for the past 2-3 decades—unfortunately. As a result, most programmers have such a big gap in their knowledge that it can feel too daunting to dive in.

We could definitely do a better job teaching the theory and explaining how it's useful. That would be better for everyone: better for curious minds who want to expand their programming skills, and better for me because I'd have more company to discuss it with.

> But it does take a lot of learning and unlearning to become a fluent functional programmer.

Just no.

The reason Haskell is so complicated to become fluent in has nothing to do with the inherent complexity of functional programming. The Haskell community is just in love with complexe abstraction for the sake of abstraction, extremely terse and hard to understand syntax (see for example the obsession with introducing convoluted operators) and generally favour hard to understand style like point free where pipes are a lot easier to follow. The Haskell community is full of people who are here to geek out rather than produce software. Haskell is what happen when you let one upmanship leads your language design.

Meanwhile, you can learn SML, F# and Ocaml in a couple days, gradually enjoy the functionality they have to offer and benefit for a nice community. I really don't understand why anyone would choose Haskell.

If you don't understand why anyone would choose something that many people have chosen, you might want to be a little less bold in announcing what motivation those people must all have.

Yeah, um... let's be sure to apply that on all sides.

I can't count the number of times I have read, here on HN, that people only choose imperative programming or OOP because they're ignorant or stupid. Because if they actually understood FP then of course they would choose it, so the only reason they don't is because they haven't learned or can't learn.

> generally favour hard to understand style like point free where pipes are a lot easier to follow

No they don't. Every Haskeller I know (myself included) acknowledges that sometimes point free style is better, and sometimes it isn't. None of them would unilaterally declare it better, and most generally avoid it except in very simple situations.

> The Haskell community is full of people who are here to geek out rather than produce software.

The Haskell community is full of people who are here to geek out about the best ways to produce software. This means they embrace tools like mathematics, and are generally extra thoughtful about structuring programs in principled ways. It's a wonderful community of people who care about the details of their craft and treat it like a skill to be honed over time. I have a lot of respect for that.

If I could rant for a moment: I'm really sick of spending many years of my life investing in myself and my ability to produce software with the best tools humanity has to offer, only to have these people in Hacker News tell me I'm just doing mental masturbation when it seems like they don't even understand what they're criticizing.

Function application pipelines and function composition are closely related. Here's a "pipe" in Haskell:

\x -> h $ g $ f x

At a certain point you realise that in many cases seeing the `x` is not just useless but needless visual noise. The following is identical and more readable once you've internalised composition:

h . g . f

And this extends to a cute trick in which, if you need to explicitly provide that data to begin with, you can do this:

h . g . f $ x

I'm now working with Haskell having previously come from PHP and JS/TS. Composition is more readable, it's just harder to get started with because it's different to what you're used to.

As for the "geek out" comment, of course, I enjoy programming for the intellectual sake of it. I'm not product-driven. Don't make the mistake of thinking everyone's the same as you, nor that of thinking there aren't benefits to being so intellectually-motivated. I don't know if it's intentional but your comment comes across as rather self-righteous.

Haskell embraces PLL. Computer science is much larger than PLL, and much of it ignores PLL entirely.

In particular, most algorithms research and papers are expressed in imperative pseudo-code, as that is, in fact, much easier for humans to intuitively reason about than complex category theoretical concepts.

> much easier for humans to intuitively reason about than complex category theoretical concepts.

We're not talking about any complex category theoretical concepts here. Functors, for example, are one of the first ideas one would learn in a category theory course. Likely even in the first lecture.

Even the most advanced functional programs use only the most basic categorical constructs.

And when you say "imperative pseudo-code", you've already conjured an implicit monad involving state, I/O, etc. Functional programming just teaches us that it's not the only one—and there are simpler ones that may be more appropriate for the given situation.

> And when you say "imperative pseudo-code", you've already conjured an implicit monad involving state, I/O, etc. Functional programming just teaches us that it's not the only one—and there are simpler ones that may be more appropriate for the given situation.

No, I have not. The fact that you can recreate state and I/O using monads does not mean that anyone using state is implictitly using a monad - monads have very specific properties that imperative code often doesn't have.

It's only Haskell's laziness that makes it require monads for i/o, by the way. Other pure functional languages don't use them. For example, in Idris, IO and state are not monads, they are effects - tracked at the type system level, but without all of the commodity of monads. For example, you can have a single do-block in Idris that does IO and state operations without needing any monad transformers or lifting.

Lazyness requires monads for IO, but monads are useful for much more than IO, even in eager languages.

Absolutely, I meant "don't use them for IO", didn't mean to imply they are not used at all in other pure, strongly typed functional languages.

I still think they don't often come up in algorithms research, though.

> I still think they don't often come up in algorithms research, though.

Why are you so fixated on algorithms research in your attempts to dismiss the usefulness of functors and monads?

You completely missed my purpose. The OP was claiming that Haskell is superior to some other programming languages because it "embraces computer science". I was pointing out that computer science is larger than PLL, and that much of computer science (algorithms research being a very productive field within CS) is not in fact using FP or PLL concepts to a large extent.

Basically, I am only trying to dismiss the idea that Haskell is somehow closer to CS or more scientifically correct than other programming languages; instead, it is as related to CS as other languages are, just choosing to focus on a different area than many others.

I also want to dismiss the idea that CS == FP, that imperative style reasoning is just some second-tier style not used in rigorous circles - much of the forefront of CS is indeed using imperative style constructs more than FP ones.

> monads have very specific properties that imperative code often doesn't have.

You don't know what you're talking about. In the context of programming language theory, monads were first used by Eugenio Moggi precisely for the purpose of specifying the semantics of imperative programming languages. Only later did Wadler realize that they could be useful as user-defined constructs within a programming language.

The "very specific properties" are actually just the identity and associativity laws of a certain monoid. These are trivially satisfied by imperative-style code including the "algorithms research and papers are expressed in imperative pseudo-code" you mentioned: you can write an imperative program that does nothing when sequenced with other programs (identity), and A; B; C does not require explicit grouping (associativity).

> It's only Haskell's laziness that makes it require monads for i/o, by the way. Other pure functional languages don't use them. For example, in Idris, IO and state are not monads, they are effects - tracked at the type system level, but without all of the commodity of monads. For example, you can have a single do-block in Idris that does IO and state operations without needing any monad transformers or lifting.

This is an incoherent train of thought. Haskell's laziness does not require the explicit use of monads, nor are monads only useful in the context of laziness. Haskell could have used Idris's IO system instead—algebraic effects work just fine in lazy languages. But also it is not true that Idris programs do not use monads just because you don't see the word "monad" in Idris programs. Effects give rise to a monad, mathematically; namely, the free monad for the algebraic theory. Read the seminal work by Plotkin and Pretnar, for example.

How can you say it's easier for humans to reason about when your test subjects almost all exclusively got started in programming with imperative programming? It's a slightly biased data set.

Reply on news.ycombinator.com