Hacker News Reader

Comment by NightMKoder | Hacker News Reader

Functional languages and strongly typed languages are not the same set. Most functional languages focus on typing (e.g. Haskell, Scala), but there are functional languages that do not (e.g. Clojure, Common LISP). You can easily do functional programming in clojure without using any monad concepts directly (though obviously it’s easy to say “that’s just a monad” in a lot of cases).

IMO the biggest win from functional programming is referential transparency. Automated verification (i.e. type checking) can definitely be useful on larger projects with bigger teams since it’s self documenting. That’s just my personal take on it though - there’s plenty for everyone to like.

View on HN

You're mentioning Clojure.

Clojure has protocols which are probably inspired by type classes. Just like Clojure's protocols, type classes are a mechanism for ad hoc polymorphism that allows decoupling between data and the functions operating on that data.

Clojure indeed doesn't have monads, but this has to do with Clojure's culture (like all LISPs) of using macros for describing APIs for composing stuff. But those APIs aren't unified and some of the DSLs I've seen do not have a theoretical foundation, which really means they aren't reusable and some of them are flawed.

Due to its evolution and backwards compatibility concerns, some of its design shows its age as well. You can't make operations like "map" work on your own data types because it doesn't have a protocol defined for it.

Don't get me wrong, I actually like Clojure, but that the community is not using types like monads to drive their design is a flaw.

What do you mean by "doesn't have monads?" You just write monads in Clojure. They are only a structural formalism. [1]

If you meant doesn't have the Maybe monad built in... why would you want that tangled up in your data? [2]

  [1] https://github.com/khinsen/monads-in-clojure/blob/master/PART1.md

  [2] https://youtu.be/2V1FtfBDsLU?t=2381

There are two important functional programming concepts absent from most Lisps: currying and lazy evaluation, so if a Lisp is used they'd need to be explained separately. Implementing them in Lisp would be a good way of understanding them.

If you want a more typical functional language without type declarations or monads, there's SASL. It's an ancestor of Haskell, but I don't know of any implementation which runs on modern hardware. Interestingly, SASL was once used to write an operating system.

I would hardly identify lazy evaluation as a core feature of functional programming. It definitely forced Haskell not to compromise on purity but, as SPJ himself has pointed out, that may be the only strong thing it has going for it[0]. Currying is also nice, but I'm still not sure that is _core_ to FP.

What Lisp is really missing from an FP perspective is purity. In fact, maybe a pure variant of Lisp would be perfect for teaching.

[0]: https://www.microsoft.com/en-us/research/publication/wearing...

Isn't Scheme pretty darn close to a pure and clean version of Lisp? Which is why it was chosen as the language of SICP?

Hey hey and what do you know, you can do both in scheme!

Purity isn't missing. It's what you have until/unless you introduce/allow impurity into your code.

How can you even teach what purity is, if it is enforced?

"Bad things could happen, take my word for it?"

ML-style FP (including Haskell) is probably the most blogged-about, although I'm not sure it's the common used style of FP.

Lisps, Erlangs, and APLs all have distinct takes on what it means to be "functional".

For example, J is dynamically typed, permits mutable state, and doesn't really have first-class functions in any meaningful way. But it definitely has a functional "feel" to it (easy to compose functions, almost all operations are side-effect free, etc).

Reply on news.ycombinator.com