1. 7

  2. 4

    Functional languages reduce the need to reason about time and state changes.

    This is a very good point, and one I’ve never seen stated in quite this way. It’s subtly different than the point I see bandied about by FP proponents (myself included) that FP is “easier to reason about.” It’s not just that whatever reasoning you’re doing is “easier” in some abstract, subjective way…it’s that there is less reasoning to be done.

    1. 2

      Exactly! Thank you

    2. 2

      I’m with you about the perils of globally mutable state and the joys of using a functional style in a dynamic language, but how does “people like using dynamic languages” follow from “to use modern C++ you need to understand five separate languages”? Couldn’t one also argue that Python developers also have to worry about bytecode with PyPy or C with CPython? And can’t you write OOP in Python or, for that matter, many other multi-paradigmatic dynamic languages? How do more modern statically typed languages like Rust, C#, Haskell, or ML-ish languages fit into this analysis?

      1. 3

        Thanks for your comment!

        The point is with a dynamic language like Python there’s only one execution model. Things like bytecode you almost never need to think about. You write your code and it operates following one set of rules. The implementation of OOP and other paradigms in Python also follow those same rules (e.g., the descriptor protocol).

        In many statically typed languages, the type system has a totally different execution model than normal program flow. So you need to learn about both and their unique behaviors and interactions. This is cognitive overhead which makes it harder to gain proficiency and be effective.

        Here’s a gist that I think also does a great job of explaining this concept:


      2. 2

        I agree with the general sentiments, and I prefer to program in a dynamic, pure functional programming language.

        Although you can do some functional programming in Python, not all functional programming idioms are supported, efficient or convenient, and the library ecosystem is mostly imperative rather than functional. I would rather use a language that is designed from the ground up to support pure functional programming, with features like proper tail calls, immutable data structures with efficient update, and the ability to do everything without using shared mutable state.

        1. 1

          I totally agree. Which ”dynamic, pure functional programming language” do you prefer these days?

          1. 1

            That’s a good question. Any suggestions? There seems to be a shortage of the kind of language I want to use. Highly expressive and dynamic, in the Lisp/Smalltalk sense, yet pure functional, with no shared mutable state, and simple, in the sense of minimizing cognitive load and enabling you to use local reasoning to understand code.

            I created my own language called Curv a while back, which is used for creating 2D and 3D art. I’m working on a new one which will be more general purpose.

            1. 2

              Clojure seems to be a great fit for your criteria. The only thing that keeps it being close enough to perfect for me is that I want strong typing.

              1. 1

                I’m working on something like this. Would be interesting to hear what you’re doing too. Probably will release what I have early next year. I’ll check out Curv.

                1. 1

                  I would be interested in talking to you about your project. My email address is in the Curv readme. If you have anything online that describes your language, post a link or send it to me.

          2. 2

            Python is not only consistent, but it also has good defaults, a wide std library, and a huge ecosystem.

            Whenever I contemplate moving to a smaller language, even if it has a better core, I lament everything I’ll have to write from scratch just to get the same level of usability.

            1. 1

              Lets just hope that one increments the correct step result in your functional code. It is easy in a trivial example to ensure it is. But the problem of needing to correctly maintain multiple versions of that returned “state” in complex code is somewhat glossed over.

              Perhaps also your criticisms reflect ambiguities in you language code. 1. Internal object state is not entirely encapsulated. 2. Your (poorly encapsulated) object’s public interface includes no “reset” behavior so each object’s instantiation leaves no ambiguity that the count is set on each instantiation. 3. “Threshold” should be encapsulated such that once provided, it performs internally as intended..