And #3 is also an area where Functional Programming falls completely flat.
There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%".
Specialization is a very, very powerful aspect of OOP, one that's extremely easy to explain and which comes in handy to model a surprisingly wide variety of problems.
The sad reality is that since so many people are only familiar with the strawman version of OOP rather than the real thing intelligently discussing the advantages and disadvantages of these paradigms is very hard.
For example, partial evaluation is limited by the fact that parameters need to be ordered a certain way and you can't realistically cover all combinations.
Higher order functions don't enable any kind of useful specialization at all. And of course, all modern OOP languages also support higher order functions, so they are the ones giving you more tools.
As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%.
https://docs.racket-lang.org/reference/procedures.html#%28de... (god links into the racket docs are ugly...)
Surely you see how this doesn't scale, right?
You would need to first write your code, then abstract every single piece of it as a call to a function passed in parameters. Now your function is accepting five different functions in parameters, and calls them.
This is a terrible and impossible to scale way to emulate class specialization.
Haskell’s typeclasses and OCaml modules solve this problem neatly. It is not as easy as in Java, because you need to spend a few minutes thinking how to abstractly specify the interface you expect, but really if your object hierarchy is supposed to satisfy Liskov’s substitution principle, you need to do that just the same.
Neither do, really.
Imagine you have an existing typeclass with three functions. How do you create your own typeclass that reuses two of these three functions but your own instance reimplements the third one?
Try it. It's pretty much impossible, or at least not without a lot of boilerplate and forwarding.
class Parent {
public void first() {};
public void second() {};
public void third() {};
}
class Child extends Parent {
@Override
public void third() {}; //change implementation of third function, reusing the first two.
} module Parent {
let first = () => ();
let second = () => ();
let third = () => ();
};
module Child {
include Parent; //add parent funcs to namespace
//@Override
let third = () => ();
};
module Foo = struct
let first = 1
let second = 2
let third = 3
end
module Bar = struct
include Foo (* Include contents of [Foo] *)
let third = 4 (* Override [third] *)
end module Foo = struct
let first() = 1
let second() = first() + 1
end
module Bar = struct
include Foo
let first() = 0
end
data Numberable = Numberable {
first :: IO ()
,second :: IO ()
,third :: IO ()
}
parent = Numberable {first = return (), second = return (), third = return ()}
child = parent { third = print 'third' }
data Env = { numberable :: Numberable }
doStuff :: (MonadIO m, MonadReader Env m) => Int -> Int -> m ()
doStuff num1 num2 = do
myNumberable <- reader numberable
print (show num1)
print (show num2)
liftIO (third myNumberable)> Reuse 90% of this piece of code but alter just this 10%
There is no general solution to this, in any programming language, without some foresight (unless you admit some crazy features like arbitrary code re-writing or source-level patches). If you have, say, a single function of 100 lines, and 10 lines need to be changed, you're going to have to edit that code to enable the change, and if that 100 lines is in a third-party library or code you otherwise don't control, you're going to have a hard time. However, if you control the code and are able to make changes to it to support new behaviors, FP languages give you plenty of power here, just as OOP languages do. There's not a lot of objective difference here in power and plenty of differences in taste and familiarity, so please be careful about repeating "you can't do X in language Y".
ML modules have modules and functors, which can exactly mimic this and in fact can be even more flexible because they are structurally rather than nominally typed.
Clojure can get some of this via multimethods, but it's not quite the same thing.
Haskell has Backpack. This is fairly new, but takes an approach similar to ML modules. (Interestingly enough to your point elsewhere in this thread, this is a good example of how type classes were not sufficient for this use case).
Scala has it, but that's cheating :). Although it does have a really cool thing which is that every object instance is itself an importable package, which leads to some really nice code reuse at times.
Stepping back, I actually think "Reuse 90% of this piece of code but alter just this 10%" is actually best captured just with splitting things up into functions/procedures in imperative and functional programming languages, rather than building a large class hierarchy, but that's another story altogether.
EDIT: I suppose what you're talking about specifically is overriding an already implemented method, which you can get via module name shadowing and re-exporting of a parent module as Hermitian909 points out elsewhere.
Honest question: why does the Common Lisp Object System not do this for you?
Yes, CLOS offers all of that.
I just didn't quite consider it to be in the bucket of FP languages I had in mind (which to me means: statically typed, and some derivative of Haskell or OCaml).
complex_function small_part = do
a <- complex_thing_a
b <- small_part a other_variables_in_scope
more_complex thing
original = complex_function orig_version
mine = complex_function my_version