Comment by darksaints | Hacker News Reader

Comment by darksaints | Hacker News Reader

It's just the Haskell family of functional programming languages that is hard to pick up. There are plenty of functional language families that are quite easy to understand and much more pragmatic:

* ML - includes SML, OCaml, F#, Scala, and Rust

* Lisp - includes Common Lisp, Racket, Scheme, Clojure

* Actor Model - includes Erlang, Elixir, and Pony, as well as other languages that have actor model systems at the library level

You'll find endless sources of opinions on why the Haskell family is so hard to use well. My personal opinion is that most languages create abstractions with concrete types of problems in mind. Haskell created abstractions with other types of abstractions in mind. If you ask the question "what is a monad used for?", the average Haskell user isn't going to respond in any form about making side effects safer, because that's just one thing that they do...they're going to respond with other abstractions. And after 45 minutes of explanations of what they are, they still haven't yet gotten to the explanation of what you can do with it. And then when you finally understand what you can actually do with it, you have to confront the fact that they made an incredibly easy thing hard, just in case you might want to use it a different way.

I cant recommend this rant enough - https://existentialtype.wordpress.com/2011/05/01/of-course-m....

> * ML - includes SML, OCaml, F#, Scala, and Rust

Scala and ocaml suffer from the same reputation. SML didn't really make it out of the academia. F# is easier, but still has a bad rap from C#ers. Rust is making incredible efforts to be accessible, but the learning curve is still steep.

One could say haskell itself is also an offspring of the ML family.

In that family, the article author correctly identified that Elm is probably among the most accessible. Choosing a specific application domain enabled the language creators to cut a lot of complexity, and to use a simple state machine as a runtime.

> If you ask the question "what is a monad used for?"

You'll get the same kind of answers as you'd get you'd get when asking Java programers what this "class" concept is about. The functor-applicative-monad stack is at the heart of Haskell's flavor of functional programming. You can write small programs without it, of course, but it's going to be the same experience as writing Java with a single "main" class.

> Scala and ocaml suffer from the same reputation.

As far as I know, they both have a reputation for being practical, pragmatic languages that enable imperative, OOP, and FP styles.

> F# is easier, but still has a bad rap from C#ers.

Yes, and C gets a bad rap from Assembly programmers.

+1

We've been using F# with great success for a few projects now. Our stack is super simple.

On the backend we use F# (on .NET with ASP.NET Core) + Postgres.

On the frontend we use F# (via Fable with React and the Feliz Bindings).

https://zaid-ajaj.github.io/Feliz/

And we have a huge shared library. Works like a charm.

A few nits: I would not put Scala in the ML category (I'm not sure about Rust). Haskell is, in-fact an ML. Racket is a Scheme. I would consider the actor model to be more OO than FP.

Scala may be hybrid OO/FP, but Martin Odersky has been absolutely clear that Scala's primary functional programming design was inspired by ML. At various times in the past, he has referred to Scala as OCaml with a different object model. I believe I read a post on Reddit quite a few years back from Martin Odersky about how he originally intended to only have structural typing, a-la SML, but when the decision was made to implement Scala on top of the JVM, that nominal typing made it's way in, with an object model that was closer to Java than OCaml, for interop purposes.

Rust's primary influence was ML. The compiler was originally written in OCaml. In fact, Graydon Hoare has commented about how he preferred OCaml's module-based polymorphism, but the Haskell advocates would never shut up about type classes so he eventually relented on that one single idea and implemented traits. But he held on to OCaml's ideas for almost everything else, at least until the point where he resigned his BDFL position.

Haskell has some ML influence, but it received that influence via Miranda. Miranda deliberately diverged from ML in the operator emphasis, and execution (lazy vs eager). They both might have been considered at arm's length with the ML family right up until the point (1990ish) that Haskell decided to eliminate all unpure IO and adopt Monadic IO. There is almost no resemblance anymore, and the functional programming community is very cleanly divided: you're either in the ML camp or you're in the Haskell camp, unless you're one of the few Lisp weirdos sitting in the corner singing hippy songs.

The actor model does have a lot of roots in functional programming (as well as logic programming), but you're right that it is also related to modern OO programming insofar as most modern OO languages inherited a ton from Smalltalk, which was a similar message-passing model. However, unlike Smalltalk, the actor-oriented languages rely on immutable state and pure state transition functions. That makes them functional languages at least in some respects.

Lisp is not a pure functional language. So it won’t teach you FP in its pure form. I already knew how to program in Lisp/Scheme/Clojure before learning Haskell. But wow what a difference it was.

Agreed. I would bet on a language like Elixir or F# being simpler to learn and grow for a complex system than a class-oriented-imperative-oop (Java, Ruby, Python, etc) language any day.

F# is such a sleeper language IMO. It's compositional tools are quite beautiful. I don't think it'll ever get wide adoption though, which is quite sad. It's just such a sensible ML language. The abstractions chosen (computational expressions, for example) were the best choice for F#, rather than copies of other FP languages. They can't implement any form of HKT because of limitations in the CLR, so they had to use alternatives.

Elixir is also really great IMO. The pipeline composition is a really nice model. If adoption grows more the tooling should step up, because it's lacking a little. The language server can't do things like rename a function, there isn't a complete TreeSitter parser either. I also have this fear with actor model that I'm inadvertantly leaving some process dangle somewhere, which in my experience is not unjustified.

Reply on news.ycombinator.com