3 ms·

>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 oriente

>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 stands in contrast not to imperative programming but object oriented programming, whose core feature is fusion of data and methods. Functional programming tries to address complexity by separation of concerns, pulling data and methods apart, OO tries to address complexity by encapsulation, pulling data and methods into purely local contexts. This is also where the association between FP and static typing comes from that the post briefly mentions. Pulling data and functionality aside lends itself to programming in a global, sort of pipe based way where types act like a contract between different interacting parts, whereas the information hiding of OO lends itself to late binding and dynamic programming, taken to its most extreme version in say, Smalltalk.

keybored 2y ago
Now you’re just defining FP as a contrast to OO. That’s wrong and boring.
breadwinner 2y ago
> 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.
- giovannibonetti 2y ago
  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
  - randomdata 2y ago
    Yes, the original comment posits that functional programming and imperative programming are the same thing, but that does not address the practical concerns of the parent. The harsh reality is that we have both "functional programming" and "imperative programming" terms with an intent for them to have different meanings. Let's accept temporarily that functional programming and imperative programming are, indeed, the same thing. But now you have two terms with the same meaning still wanting to mean something different. A conflict in need of resolve. So, from this point forward what can we say that makes them different? A trait I often see in languages that are considered functional, and not found in C, is the closure. Its purpose is to bind data with functions. That suggests to me that, as we seek a division in meaning, separation of data and functions is better left for the imperative definition rather than the functional definition. Perhaps functional programming is best described as the intersection of imperative programming with "OO" programming? That seems to be the view the original commenter ends up taking in subsequent comments.
wk_end 2y ago
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 - the internals of the type sealed away such that only those functions can operate on that data.
- Barrin92 2y ago
  >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.
  - randomdata 2y ago
    > by injecting a bit of OO. OO is defined by message passing. What does a closure have to do with message passing?
    - layer8 2y ago
      In most OO languages, message passing is just a fancy term for function calling. It’s really not fundamentally different from functional application on a closure value in FP. OOP is defined by encapsulation and subtyping (polymorphism and inheritance). In fact, the one thing that doesn’t exist in standard FP is inheritance. (Encapsulation sort-of exists with closures, and polymorphism exists with function values.)
      - randomdata 2y ago
        > In most OO languages, message passing is just a fancy term for function calling. Having objects does not make a language oriented to those objects. By your definition C++ would be considered OO, but we know it is not. Kay quite explicitly stated that C++ is not OO. I expect you're thinking of Object-based programming. If you look at the actual definition of OO, it basically is just a laundry list of Smalltalk features. It is probably not usable outside of Smalltalk for that reason, despite Joe Armstrong's playful insistence that Erlang is the only OO language in existence. You might be able to include Ruby and Objective-C (and, iff you're really stretching, Swift with @objc enabled), but that's about the extent of it.
oglop 2y ago
There's always some rambling answer in every FP post about what FP _actually is_ which then devolves into senseless drivel and arguments. 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.

keybored 2y ago

Now you’re just defining FP as a contrast to OO. That’s wrong and boring.

breadwinner 2y ago

> 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.

giovannibonetti 2y ago
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
- randomdata 2y ago
  Yes, the original comment posits that functional programming and imperative programming are the same thing, but that does not address the practical concerns of the parent. The harsh reality is that we have both "functional programming" and "imperative programming" terms with an intent for them to have different meanings. Let's accept temporarily that functional programming and imperative programming are, indeed, the same thing. But now you have two terms with the same meaning still wanting to mean something different. A conflict in need of resolve. So, from this point forward what can we say that makes them different? A trait I often see in languages that are considered functional, and not found in C, is the closure. Its purpose is to bind data with functions. That suggests to me that, as we seek a division in meaning, separation of data and functions is better left for the imperative definition rather than the functional definition. Perhaps functional programming is best described as the intersection of imperative programming with "OO" programming? That seems to be the view the original commenter ends up taking in subsequent comments.

wk_end 2y ago

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 - the internals of the type sealed away such that only those functions can operate on that data.

Barrin92 2y ago
>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.
- randomdata 2y ago
  > by injecting a bit of OO. OO is defined by message passing. What does a closure have to do with message passing?
  - layer8 2y ago
    In most OO languages, message passing is just a fancy term for function calling. It’s really not fundamentally different from functional application on a closure value in FP. OOP is defined by encapsulation and subtyping (polymorphism and inheritance). In fact, the one thing that doesn’t exist in standard FP is inheritance. (Encapsulation sort-of exists with closures, and polymorphism exists with function values.)
    - randomdata 2y ago
      > In most OO languages, message passing is just a fancy term for function calling. Having objects does not make a language oriented to those objects. By your definition C++ would be considered OO, but we know it is not. Kay quite explicitly stated that C++ is not OO. I expect you're thinking of Object-based programming. If you look at the actual definition of OO, it basically is just a laundry list of Smalltalk features. It is probably not usable outside of Smalltalk for that reason, despite Joe Armstrong's playful insistence that Erlang is the only OO language in existence. You might be able to include Ruby and Objective-C (and, iff you're really stretching, Swift with @objc enabled), but that's about the extent of it.

oglop 2y ago

There's always some rambling answer in every FP post about what FP _actually is_ which then devolves into senseless drivel and arguments. 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.