Why Functional Programming Matters [pdf] | Hacker News Reader

Why Functional Programming Matters [pdf]

cs.kent.ac.uk

27 pointsalexzeitler5 comments

> As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write and to debug, and provides a collection of modules that can be reused to reduce future programming costs. In this paper we show that two features of functional languages in particular ...

My problem with this side of the force, is that it's all about the theory and the expressivity, which matters of course, but very little about tooling, readability of the code, etc. This sometimes gives birth to functional languages that are very interesting but not really usable from an engineering perspective.

To me, it would be interesting to see a modern functional language that would follow Rust's way. Great all-in-one product (tooling, build system, package manager, formatter, static analyzer) with great doc, and language decisions that make organizing codebases a pleasure (via convention over configuration, for example)

I think Roc (https://www.roc-lang.org) is trying to be that kind of practical, less theoretical FP language. It's strictly evaluated, doesn't have currying, you can learn it without ever hearing the word monad. It's still very young, so the tooling isn't there yet, but it already has a formatter and linter built into the compiler.

oh this is amazing, I do think exposing currying to the developer is a big mistake (along with the lack of explicit types)

> Well-structured software is easy to write and to debug

I agree that functional programming makes software easy to write (it’s easy to reason about pure functions). However, having spent a decade writing and supporting Scala apps in the wild, I disagree with the notion that FP makes software easier to debug.

Perhaps this is a reflection on the way FP has been shoe-horned onto the JVM, but too many of my stack traces contain deeply nested calls to anonymous functions, and the semantics of the original program are almost completely buried in noise. This gets a lot worse when you start working with heavy framework code.

When writing code, I love Scala’s succinctness and expressiveness. When debugging, I miss the simplicity of stack-friendly imperative code.

It's not much better in Haskell; while you can coerce GHC into printing a stack trace, you'll need some knowledge of how the language is evaluated in order to understand it.

I think the mapping of imperative "stack frames" to functional code is leaky when there's a runtime sitting in between. Traces should be done in the runtime, however it makes sense to display them.

Reply on news.ycombinator.com