https://dl.acm.org/doi/10.1145/359576.359579

I recently gave a talk to some colleagues about that, which was divided into two parts: Practical functional programming patterns we can use today in our codebases (we use mainly C++, Python) and a more abstract part about pure functional programming.

The first part basically boils down to using functions as first class "objects", while the point of the second part was, that there can't be implicit state in pure functional language. The consequence of that is, that there is no strict order of execution, which is in direct contrast to imperative programming, which is all about list of statements, that are executed one after another.

I presented small code examples in Haskell and showed corresponding execution graphs to emphasise, that the compiler can easily optimise the execution order.

I like that POV, because it clearly distinguishes imperative from functional programming. Starting from there, it's also easy to understand the motivation behind monads or elaborate on architectural patterns like " functional core, imperatively shell".

For example, while I can do FP in Rust, I would not really call Rust a FP language. It does have some features that make doing FP possible, but a lot of the code I see (and write) is a mix of imperative and FP.

But if I'm writing Scala, I'm going to be mostly writing FP code, and the language helps me there. Recent versions of Java make it easier to write FP code if you so choose, though you'll still see a lot of people write more imperative code in Java.

(I think if Rust had Scala's for-comprehensions, I'd write more FP-ish Rust. I know there are crates that emulate them, but they're not the most ergonomic, and I don't want to write what ends up being unidiomatic Rust code.)

We just don’t call them monads.

We don’t really use them in mainstream languages. They exist as idioms for shallow application, but one doesn’t go full-on combinators in javascript, for at least performance reasons. What we do in mainstream is as FP as walking stairs compared to rope climbing.

That said I think deep FP makes no sense and only entertains bored intellectuals by being a subspecies of code golf.

- understanding paradigms of state handling enables you to make conscious choices about what to aim for, how to design your data model, etc

- learning the benefits of having all data as values, except at the edges of the system (instead of object refs encompassing mutable state and/or IO handles)

- eg the resulting ability to reason about your system in a principled way (this can still be hard to mentally reach, even given all the ingredients, if you're very used to the "poking the mystery ball" way of relating to your app)

- how it comes together so you can just test a subset of your code at your REPL, being able to paste the input datastructure there (because it's just values, not active objects) without having your app framework up and running in a stateful context in browser or server environment.

Another strength of FP is about paralell programming. The bottleneck of parallelizing code by using multiple threads is concurrency bugs which come from mutable data. Immutable data and referential transparency is close to a silver bullet for this. (But JS programmers aren't as likely to appreciate this since JS is nearly always single-threaded)

If you go to https://en.wikipedia.org/wiki/Functional_programming right now you will see "functional programming is a programming paradigm where programs are constructed by applying and composing functions" which is a bit of a ... it is quite hard to program without doing that. Even SQL is basically applying and composing functions. There are languages that are branded together because they have similar communities or techniques, but the brand isn't describing something beyond people thinking that things belong in a basket together.

Consider whether the same input to your code will result in the same output (aka functions), that's a good place to draw the line.

You can stick 'FP' fancy types and closures into a method; that doesn't turn it into a function.

It's also important to teach the techniques together because functional programming tools are typically (deliberately) less powerful, which makes them easier to analyze, but means you need more tools.

I find FP concepts easy enough to grasp (provided they’re not demonstrated in e.g. Haskell) and even adjacent stuff like typeclasses or monads or what have you aren't a stumbling block, and I'm plenty comfortable with stuff like recursion.

… but I'm firmly on the language-is-more-natural-for-me side of things, and find non-algorithmically-oriented math writing incredibly difficult to follow—I have to translate it to something more algorithmic and step-oriented to make any headway, in fact. I find languages like Haskell nearly illegible, and tend to hate reading code written by dedicated FP fans in just about any language.

It's an annoying trade off, to be sure. With a language that makes writing FP code ergonomic and idiomatic, though, I'm usually going to choose to write that way.

But even in languages where writing in an FP style is a chore (if it's even possible at all), you can take some lessons. The C I write today is more "functional" than 25 years ago, when I'd never even heard of functional programming. I try to avoid global state and mutation and side effects, and write more pure functions when I can. I think about my programs as transformations of data, not as a series of instructions, when I can. My C code today is not very FP at all when you'd compare it to something written in Haskell or Scala or whatever, but it's, IMO, "better" code than what I used to write.

In 2022 I went back to a C-based open source project that I used to work on heavily in the mid-'00s. Reading a lot of that old code makes me cringe sometimes, because the details at the micro level make it really hard to reason about behavior at the macro level. As I've been working on it and fixing things and adding features again, I'm slowly morphing it into something easier to reason about, and it turns out that using functional concepts and idioms -- where possible in C without having to go into macro hell -- is essentially what I'm doing.

What would also explain why Prolog has none of those benefits. If you don't use the extra information, it can't do any good.

But if it is really just that, it can be replicated over imperative languages. Anyway, Rust is evidence that there is something to that idea.

Does it increase cognitive load, or is it just making the cognitive load more apparent. Sure it's easier to write multithreaded code if you assume race conditions can't happen, but that's not actually accurate to what would happen.

Perhaps FP just makes explicit in the typing/coding portion, what would otherwise be uncovered hours/days/weeks later in a bug?

These aren’t strictly necessary for effectively using functional techniques in an imperative environment, but they can go a long way toward providing useful guardrails you don’t have to figure out yourself.

However, circular dependencies can be represented with lazy (aka non-strict) references and deferred function calls (aka thunks / call-by-name), and are IMO easier to reason about than mutable imperative techniques for representing such relationships. They also have the advantage of being totally thread-safe.

The OP (Lihaoyi) is the author of an important set of Scala libraries, and Scala is an example of what you are describing. Scala is a hybrid OO / FP language that is not dogmatic about purity. You can be totally imperative if you want.

It is common in the Scala ecosystem to implement performance-critical library code using local mutability and null references. Internally the function is imperative; to the caller, it is functionally pure.

Maintainable code? I dunno. From what I’ve seen, FP is much worse for changing when you have shit deep in your call stack. I wouldn’t call that maintainable.

More readable? Nah. Nearly everyone has a much easier time consume code when they’re not constantly context switching between function jumps all over the place.

Additionally, FP only makes threading “easier” in one very specific circumstance. Once you need to parallelize the same workload, FP is generally much much harder to thread, whereas this is trivial in other languages.

    whip(cream)

    whipped_cream = whip(cream)

While they could have mentioned it, it wouldn't really change the message.

To me (someone who really doesn't like FP as a religion), FP is about function application: everything should just be "pure" function calls taking values (not references) and returning values; immutability is indeed a corollary of that, static typing really isn't (isn't Church's original LC untyped, btw?).

* If you don't have side effects, you can't do anything.

* Haskell can do things? Then it has side-effects, so it's not functional.

* Computer getting hot is a side-effect.

* i++ is not a side-effect, because I intended to do it.

For me, the essence of FP is the minimization of global state

  Eggs.mix()
      .whip()
      .beat();

> Fluent API is a way of implementing object oriented API in a way that it provides readable code. [https://www.progress.com/documentation/sitefinity-cms/for-de...]

I have yet to see a more practical, elegant solution than Haskell's STM for this: https://www.adit.io/posts/2013-05-15-Locks,-Actors,-And-STM-...

Can be disproved trivially. Anyone can code up a program that generates the nth prime for some n, by iteratively accumulating n primes starting from 2 using trial division. otoh, an actual formula that produces the nth prime would be an earth shaking event.

Your quote is specifically about the code formatted in such a way, with arrows drawn all over it, to match the box diagram. But if you look at the code as it would actually be written, in a functional style:

        def make_tiramisu(eggs, sugar1, wine, cheese, cream, fingers, espresso, sugar2, cocoa):
            beat_eggs = beat(eggs)
            mixture = beat(beat_eggs, sugar1, wine)
            whisked = whisk(mixture)
            beat_cheese = beat(cheese)
            cheese_mixture = beat(whisked, beat_cheese)
            whipped_cream = whip(cream)
            folded_mixture = fold(cheese_mixture, whipped_cream)
            sweet_espresso = dissolve(sugar2, espresso)
            wet_fingers = soak2seconds(fingers, sweet_espresso)
            assembled = assemble(folded_mixture, wet_fingers)
            complete = sift(assembled, cocoa)
            ready_tiramisu = refrigerate(complete)
            return ready_tiramisu

(sorry, bitter personal experience) And yes, that is explicitly "modern" Java code written by a lead engineer and "java champion" in 2023.

I have refactored large enterprise systems, and always tend to write in an FP style depending on the language. Im not talking about full blown Haskell here, but traditional C like languages.

Just keeping it simple, avoiding mutation, isolate side effects and having pure functions will take you a LONG way for better software.

You dont have to go balls deep in category theory for FP, and usually the language you use is not really suited for a monadic way of things, i dont like to shoehorn that stuff in if im not working with something like ocaml etc.

ML, one of the standard-bearing functional programming languages, is at least partially defined by its powerful module system. And an ML module serves a similar sort of encapsulatory purpose as the class does, often binding together a type and functions that operate on it - the internals of the type sealed away such that only those functions can operate on that data.

Couldn't disagree more. Based on this definition C language would be the epitome of functional programming... but it is not.

If you wrote this in a book and gave it to me as a way to learn what FP is, I'd be pretty pissed if I paid for that book is all I'm saying.

Also, what in the actual fuck are you on about? FP is many things and some of them are less enforced than others depending on implementation, but I'm pretty sure in each FP book I've looked at has mentioned exactly this idea of data-flow. So either you are an amazing genius who sees what others can't, or you are just generating nonsense. Either way I don't care, HN is kind of a joke to me anymore.