3 ms·

It's arguable that SQL is "basically applying and composing functions," given that its mathematical underpinnings lie in the relational algebra (hence relationa

• roenxi 2y ago
  The distinguishing characteristics don't distinguish FP from anything. Those are features like first class functions that I would expect to find support for in Python or C++, for example. And it isn't possible to write a useful program that doesn't have side effects because there would be no IO. It is a case of the paradigm not really meaning anything. It is an arbitrary bunching of language features and code properties that doesn't provide a particularly useful guide. Anything that is a good idea in one paradigm is also a good idea in any other paradigm too.
  • ryandv 2y ago
    It's worth noting that both languages cited (Python, C++) are multi-paradigm and therefore contain aspects of both OOP and FP; there are very few languages that are exclusively object-oriented or functional. The naming of the functools [0] stdlib package for Python's higher-order functions is illustrative in this respect, and there is an entire HOWTO for "implementing programs in a functional style" [1] in the Python docs. If you want to see object-orientation taken to the extreme, and how it makes writing programs in a functional style extremely unergonomic, you can read old-school Guava code from Java 6 and try to decipher all the line noise; there is even a caveat in its official documentation [2] that states, functional programming without Java 8+ requires awkward and verbose use of anonymous classes. Excessive use of Guava's functional programming idioms can lead to verbose, confusing, unreadable, and inefficient code. These are by far the most easily (and most commonly) abused parts of Guava, and when you go to preposterous lengths to make your code "a one-liner," the Guava team weeps. > It is a case of the paradigm not really meaning anything. It is an arbitrary bunching This is a case of throwing the baby out with the bathwater; just because we can't come up with a perfectly precise definition doesn't mean that we should dispense with rough heuristics and (perhaps crudely drawn) boundaries that serve as a useful clustering of related features. Try asking a machine learning or computer vision algorithm for the criteria it uses to categorize something as a "dog;" it's unlikely that you'll come up with something as precise as the definition of the Platonic ideal of a dog, but we can still use its model to recognize dogs with a reasonable degree of accuracy. [0] https://docs.python.org/3/library/functools.html https://docs.python.org/3/library/functools.html [1] https://docs.python.org/3/howto/functional.html#small-functions-and-the-lambda-expression https://docs.python.org/3/howto/functional.html#small-functi... [2] https://github.com/google/guava/wiki/FunctionalExplained https://github.com/google/guava/wiki/FunctionalExplained
    • roenxi 2y ago
      But if we take a holistic view here, languages that treat paradigms as a thing have been trounced in the marketplace of ideas. And to find an example of a non-functional programming language your first instinct was to talk about Java 7 - where there is a strong consensus that if you were going to create a new program today it should not be used. We're up to Java 22. The attempts from decades past to draw a distinction between OOP and FP paradigms has largely failed. Consensus seems to be that whatever is concise and easy to understand is best and attempting to force code into a paradigm is inferior to looking at specific individual features and techniques in context of the problem being tackled.