Hacker News Reader

Comment by pka | Hacker News Reader

The fact that it's meaningless to you doesn't mean it doesn't have any meaning :)

Your "hideously complicated type theory" is many peoples' "hideously horrible paren-based syntax" - i.e. Lisp. So, how many people don't learn Lisp only because of its syntax? I'd say a lot.

Many of the concepts make sense when having an explicit type system, so if you want types you may want to learn them.

Others I suspect you are already using, even if you don't know them by name. Have you ever used streams? Congratulations, this is what codata is.

View on HN

> "hideously horrible paren-based syntax" - i.e. Lisp. So, how many people don't learn Lisp only because of its syntax? I'd say a lot.

But the point is that nobody's putting 'S-expression syntax languages' in a Lisp-centric list of essential functional programming skills. The idea that half this stuff is supposedly mandatory is a skewed perspective.

> Others I suspect you are already using, even if you don't know them by name.

And if the list is comprised of Haskell-centric jargon for more generic notions, that's obviously grounds for criticism.

> But the point is that nobody's putting 'S-expression syntax languages' in a Lisp-centric list of essential functional programming skills.

They should've probably said "FP-only" (i.e. pure) languages to exclude imperative languages that merely support functional programming constructs, like Clojure, Erlang, etc.

I agree, many of the concepts that are useful in pure languages (i.e. monads) are not that practical in imperative/impure or dynamic languages (at the cost of reduced ability to reason about your program.)

> And if the list is comprised of Haskell-centric jargon for more generic notions, that's obviously grounds for criticism.

It's the other way around - the items on this list are the more generic concepts [0]. Less expressive languages lack the (practical) ability to reason about those concepts generically, hence the need for more specialized constructs, like i.e. streams, transducers, etc.

[0] https://en.wikipedia.org/wiki/Coinduction#Codata

They should've probably said "FP-only" (i.e. pure) languages to exclude imperative languages that merely support functional programming constructs, like Clojure, Erlang, etc.

Ahh, and there would be that definition again, the one at the root of the problem.

Please find your nearest whiteboard and write the following 100 times or until it sinks in: "Haskell is not the only Functional Programming language."

FFS, the languages that invented functional programming are not Haskell, and predate it by some time. Lisp dates back to 1958. Scheme first appeared in 1970. ML dates to 1973. Haskell didn't even exist until 1990.

This weird ahistorical definition of "functional programming" is both useless and inaccurate. Strict typing and purity are not the sole measure of whether a programming language is functional and never have been. It's only been in the last few years that there seems to be this desperate push to define FP as "Haskell", which as far as I can tell is the product more of a desperate kind of evangelism than any sound argument for such a limited definition.

We get it, you like Haskell. But some of us also like Clojure, and Erlang, and Elixir, and F#, and OCaml, etc. etc., and you don't get to just redefine terms to cut out languages you don't like. Reality doesn't work that way.

But Haskell does stand out among your list as being a pure functional programming language (it is not the only example of course). Whether this is a good or bad thing, I will not get into. When programming in a pure language you typically have to use some quite recent/advanced ideas such as monads and lenses, just to get practical work done. This is not the case with Clojure, F#, Scala, Erlang etc, where side-effects are idiomatic. In fact, if you tried to go fully pure with these languages, you would run into problems with performance.

To avoid confusion, they should have used the term "pure functional programming" or even "typed pure functional programming".

To avoid confusion, they should have used the term "pure functional programming" or even "typed pure functional programming".

That's what was used when I started learning FP, which was maybe three or four years ago. There was FP, and then purity was a secondary characteristic. Haskell was pure and typed, but that didn't make other languages not FP, when they still had all the same basic tools and the same idiomatic focus on composition of functions over mutable state and imperative logic. No, you didn't need a special magic word to allow you to have side-effects like I/O, and most also allowed for mutability (even Scheme had set! after all), but they are first and foremost functional languages. In many ways, Haskell was and still kind of is the odd one out, not counting experiemental academic languages like Idris and Coq.

This wasn't even a controversial statement just a few years ago. But as Haskell has been more and more in vogue, there's this weird fixation on redefining the window of what "FP" is to only refer to, well, Haskell. And it's very clearly what the LC list is all about, because so many of the concepts described are both largely unique to Haskell and it's closest relatives, and unnecessary to do practical, everyday work in a vast majority of FP languages.

And ultimately, attitudes like that hurt the whole field. In trying to fix Haskell's image problem by brute force, they wind up damning the larger domain in the process.

If your language is not purely functional it is imperative. There is really no conceptual difference between Clojure and Python, except for syntax/macros and that Clojure has immutable data structures in clojure.core.

You could use mutable arrays in Clojure the same way you could use immutable arrays in Python (yet nobody is calling Python a functional language.)

Still, I agree that functional mostly means "language with closures and immutable data" in the mainstream, but in the context of this post I'd say it's not that hard to guess that the authors meant purely functional.

I think the point was that this is a Standardized Ladder of Haskell Programming masquerading as a Standardized Ladder of Functional Programming.

Reply on news.ycombinator.com