The article itself was well written, although I'd appreciate if the author was more "to the point" with the examples. FP never resonated with me and never fit the mental model I have for programming. I tried learning Prolog and Haskell a few times, and I never felt like I could reason about the code. This line from the article: "[..] With functional programming, whether in a typed language or not, it tends to be much…
FP doesn't have to be a religion; in Common Lisp it's just an idea, an ideal to aim for perhaps.
I'm personally a fan of FP. It offers clear benefits: simplified parallelization, improved testability, and reduced side effects. These advantages often lead to more maintainable and robust code. However, FP's benefits can be overstated, especially for complex real-world systems. These systems frequently have non-unidirectional dependencies that create challenges in FP. For example, when component A depends on B, but…
>d. As a result, FP's emphasis on granular transformations can increase cognitive load, particularly when dealing with these intricate dependencies.
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?
The article itself was well written, although I'd appreciate if the author was more "to the point" with the examples. FP never resonated with me and never fit the mental model I have for programming. I tried learning Prolog and Haskell a few times, and I never felt like I could reason about the code. This line from the article: "[..] With functional programming, whether in a typed language or not, it tends to be much…
It's possible that what makes functional languages easier to reason about and debug is the fact that they allow the types to capture a lot more information than the imperative languages.
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.
>The core of Functional Programming is thinking about data-flow rather than control-flow That's not right. The difference between data and control flow oriented programming is the difference between laziness and eagerness. The difference between imperative and functional programming is largely one of abstraction, not a feature in itself. The genuine core feature of FP is the separation of data and methods , that stan…
One of the foundational building blocks of FP is the closure, the purpose of which is to couple together data and the function operating on it. 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 - t…
>One of the foundational building blocks of FP is the closure
Yes, because the closure solves a problem in functional programming by injecting a bit of OO. Closures are just stateful function objects with a single call method operator where the local context serves the same purpose as private variables in an object.
It's exactly because FP otherwise lacks the coupling of data and methods that closures are so important, and it's why, the other way around, in languages where functions are literally first class objects, you achieve that through closures.
One of the foundational building blocks of FP is the closure, the purpose of which is to couple together data and the function operating on it. 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 - t…
>One of the foundational building blocks of FP is the closure Yes, because the closure solves a problem in functional programming by injecting a bit of OO . Closures are just stateful function objects with a single call method operator where the local context serves the same purpose as private variables in an object. It's exactly because FP otherwise lacks the coupling of data and methods that closures are so importa…
> by injecting a bit of OO.
OO is defined by message passing. What does a closure have to do with message passing?
>The core of Functional Programming is thinking about data-flow rather than control-flow That's not right. The difference between data and control flow oriented programming is the difference between laziness and eagerness. The difference between imperative and functional programming is largely one of abstraction, not a feature in itself. The genuine core feature of FP is the separation of data and methods , that stan…
> The genuine core feature of FP is the separation of data and methods Couldn't disagree more. Based on this definition C language would be the epitome of functional programming... but it is not.
That's exactly what the parent comment said, since C is an imperative programming language:
> The genuine core feature of FP is the separation of data and methods, that stands in contrast not to imperative programming but object oriented programming, whose core feature is fusion of data and methods
The article itself was well written, although I'd appreciate if the author was more "to the point" with the examples. FP never resonated with me and never fit the mental model I have for programming. I tried learning Prolog and Haskell a few times, and I never felt like I could reason about the code. This line from the article: "[..] With functional programming, whether in a typed language or not, it tends to be much…
FP doesn't have to be a religion; in Common Lisp it's just an idea, an ideal to aim for perhaps.
Same can be said about Clojure. Although Clojure usually described as an FP-language, it's not "purely FP". In general, I find that Lispers typically don't concern themselves with the popularity of certain tools or techniques; They don't care for things like MSFT marketing shoveled in your mouth. Die-hard pragmatists, they'd use an instrument if it makes sense. They don't give two shits about OOP propaganda or extreme functional purity, or the notion such as "not using static types is immoral" and shit like that, they'd use object-orientation where it makes sense; metaprogramming, where desired; constrains, if applicable; concurrency when required, etc. All that without any zealotry - just pragmatic use of the right tools for the job, embracing Clojure's flexibility and power while staying true to the only core "philosophy" - "simple made easy".