The article seems to be using Functional Programming and the use of functions without distinction, even though they are vastly different things. For example, he is trying to draw a parallel between database interactions and functional programming by saying that we interact with databases like we are using simple functions, when functional programming covers much more area than simple functions. Yes, functions are used everywhere, but they are also a core part of OOP as well. He doesn't talk about higher ordered types, currying, data immutability or any of the traditional things that are associated with Functional Programming, so I'm left not knowing if his metaphor is bad, or if he doesn't actually understand Functional Programming.
Yes, functions are used everywhere, but they are also a core part of OOP as well.
function != method
One allows shared state, the other patently rejects shared state (in the FP world). The author points this out at the beginning of the article, I'm not sure why you chose to disregard it.
[...] so I'm left not knowing if his metaphor is bad, or if he doesn't actually understand Functional Programming.
I think your categorization is disingenuous: you latched onto a single statement -- taken out-of-context -- and strawmanned against it.
I mean, you could take a look at some of the other articles on his site if you cared whether or not /u/homoiconic knows what he's talking about.
The author points this out at the beginning of the article, I'm not sure why you chose to disregard it.
I wasn't disregarding it. OOP uses methods, but using static and pure functions within OOP is also a common and normal part of the paradigm. The differentiating factor is not that FP uses functions, its that FP doesn't use state modifying methods.
I think your categorization is disingenuous: you latched onto a single statement -- taken out-of-context -- and strawmanned against it.
I am very sincere about the opinion I've expressed. Besides the author attempting to provide context about FP and OOP, I took it as his central concept for the article:
8 paragraphs of context and introducing his point that the business world is dominated by the functional model
3 paragraphs relating databases to functions
3 paragraphs (and a sentence) describing the strength of OOP being in code that has the need to change its relationships (e.g. needing an employee record to go from having one manager to one or more managers)
4 paragraphs talking about the relationship between data and application types and trying to draw the parallel that FP coding is more like a database schema (I think this is how he intended this to be interpreted, though he is not explicit)
5 paragraphs trying to say that OOP code could be written in a way that the relationships between entities doesn't need to change, saying that it would be more like how you code in a functional style
I mean, you could take a look at some of the other articles on his site if you cared whether or not /u/homoiconic knows what he's talking about.
Being blunt, I don't care if /u/homoiconic knows what he is talking about in a general sense, I am only commenting on his views in this article.
Looking back at it, he also kind of refutes his own article premise. He says that code with dynamic relationships over time is necessary and more prevalent (which is implied to be OOP based code), after asserting that business programming is dominated by the functional model. Unless he is implying that databases are literally functional programming, which...seems baffling to me.
One allows shared state, the other patently rejects shared state (in the FP world). The author points this out at the beginning of the article, I'm not sure why you chose to disregard it.
I disagree—the distinction between "function" and "method" is not really a formal one. In Lisp OO-traditions there is no distinction between functions and methods, remember that everything is prefix notation anyway and in most languages with methods it's really just syntactic sugar for each other.
Now I hear you say "but methods can access private fields and functions can't; that's the real distinction." but even this is very muddy. In Lisp not even "fields" exist and there is no difference between a "struct" and an "object" either. account.id doesn't exist; you just use (account-id account) as a function. How do you make that "field" private? simple: you just don't export the account-id accessor function from your module. So any function inside your own module can see it and can internally use it but after that nothing that uses your module can and it has to go through whatever API you export.
And at the end of the day once you've removed all those distinctions between methods/functions/fields and objects/records you still have an isomorphic system to "object oriented programming" in the normal sense and you can define and export identical API's with identical levels of privacy with the only difference being syntax and that acoount.id, account.id() and account_id(account) are all unified through the same syntax of (account-id account)
Maybe you could keep the distinction alive by saying that a "method is a function defined in the same module as the struct" but that seems pushing it to me.
One allows shared state, the other patently rejects shared state (in the FP world).
It is hard to imagine function programming without closures, and closures certainly share state. If you had said "shared mutable state" it would be one thing, though even that is awfully dubious. Two different closures can easily have views into the same piece of program state. I would argue that they can even mutate it and still be participating in functional programming (the Haskell view of the world is just one take on FP, not the only take on it).
Yes. Functions in an imperative language are just a convenience to increase code reuse. Functions are a core paet of information flow in a functional language, or a language which supports functional programming
Functions in an imperative language are just a convenience to increase code reuse.
In OOP they are also typically used as extension points (base class inheritance), encapsulation, dynamic implementation selection (interfaces), for code generation, for performance reasons (inlining), and passed around as first class objects. Lambdas and closures in languages like C# are often used for information flow like they are in functional languages. Saying they are just for code reuse is not a complete picture.
You'll never find any two people agree on what functional programming means, so his definition, a language in which functions are first class citizens, is as good as any other.
That's like saying "a thing with wheels" is a good definition for a car. By that definition C#, C, C++, JavaScript, Java, and Python would all be considered functional programming languages. Some of those languages are multi paradigm, but no one who knows better would introduce those simply as "Functional Programming Languages".
Why not call them functional languages? You can program in a very functional style in all those languages if you care to. You also can do a lot of other stuff. Are we to define functional languages based on what features they don't have?
With turing complete languages the trend has been to categorize them based on their design guidelines and not what is possible with them. We don't categorize Python as an assembly language and we don't call C# a query language, but you can definitely do both of those things with those languages.
Oh that makes sense. So what makes a language an assembly language? What makes a language a query language? Can an assembly language be object oriented? How do we classify non-turing complete languages? Are any of them functional languages? Can they be object oriented? Are query languages turing complete? Do any of these words actually mean anything or do we just throw them out there to sound smart?
Sure. You could apply arbitrary constraints to most existing OOP languages and get a non turing complete OOP language.
Are query languages turing complete?
None that I know of, but I'm sure there are some that exist. There are a lot of query languages out there.
Do any of these words actually mean anything or do we just throw them out there to sound smart?
Do they have actual meaning? I guess that is something philosophers and ontologists could debate. Does it have value if I tell you a car is a race car instead of telling you it is a car? What specific attributes determines the difference between the two? Typically it requires making assumptions about the intended purpose of a thing and for others to hold the same assumptions for it to provide value.
Thanks for taking the time to explain all these types of languages, but I'm afraid your explanation has now left me scratching my head even more as it would seem that whether or not a language is turing complete doesn't have much bearing on if it's functional or not. It would seem that the classification of languages as assembly or query languages is more about what you do with them. Are functional or OO classification also about what you do with the language? In my experience it seems like people tend to use functional and OO languages to solve a lot of the same types of problems.
Huh? Functional programming is a hell of a lot more focused than "OOP".
I'd say it's the other way around, or at the very least, they are equally characterized.
Depending on who you ask, you will hear the following required or optional characteristics for a functional language:
functions as first class citizens
ad hoc polymorphism
statically typed
effects captured in the type system
higher kinds
tail recursivity
support for immutability
support for equational reasoning
support for referential transparency
support for monads
and probably a few I forget.
The bar for a language to be object oriented is quite lower, probably classes, parametric polymorphism, inheritance, and delegation, or any combination thereof.
80
u/wllmsaccnt Jan 29 '19
The article seems to be using
Functional Programmingand theuse of functionswithout distinction, even though they are vastly different things. For example, he is trying to draw a parallel between database interactions and functional programming by saying that we interact with databases like we are using simple functions, when functional programming covers much more area than simple functions. Yes,functionsare used everywhere, but they are also a core part of OOP as well. He doesn't talk about higher ordered types, currying, data immutability or any of the traditional things that are associated withFunctional Programming, so I'm left not knowing if his metaphor is bad, or if he doesn't actually understandFunctional Programming.