Hacker News Reader

Functional programmers will reply that you can use partial evaluation and higher-order functions to do that.

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.

Yes, I've heard them say that indeed. They often gloss over a lot of issues about these.

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.

Could you give some concrete examples? At the moment it's just assertions.

Do any functional languages support partial evaluation using named parameters? That would solve the parameter ordering complaint.

As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%.

OCaml has named (“labeled”) parameters, and of course you can use combinators like flip to bind positional parameters like the second or third. I'm not sure what the relevance to inheritance is, though, and “partial evaluation” usually means an optimization strategy rather than just currying.

Racket's curry supports keyword arguments.

https://docs.racket-lang.org/reference/procedures.html#%28de... (god links into the racket docs are ugly...)

> As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%.

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.

So put those parameters in a single record type and just override the 10% of them that you need to.

Abadi and Cardelli identified some ways that this solution falls short—in particular, the self parameter isn't covariant—and how to fix them.

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

Honest question: why does the Common Lisp Object System not do this for you?

Honest answer: you have a point :-)

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

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

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.

> Haskell’s typeclasses and OCaml modules solve this problem neatly.

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.

Not sure what you mean, exactly. Could you sketch a simple example with some types and typeclasses?

This is how it would be done in Java:

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

third = first + second

I would accomplish this in modules in the following way. I use reasonML syntax but it's OCaml under the hood

  module Parent {
    let first = () => ();
    let second = () => ();
    let third = () => ();
  };

  module Child {
    include Parent; //add parent funcs to namespace
    //@Override 
    let third = () => ();
  };

I make regular use of this pattern production.

In OCaml:

    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

OCaml has real objects and classes. Moreover, it is trivial to demonstrate that your example doesn't work in practice:

  module Foo = struct
   let first() = 1
   let second() = first() + 1
  end

  module Bar = struct
    include Foo
    let first() = 0
  end

Bar.second () will still be 2 because of static binding. Thus you cannot use this approach to replace 'first' by itself without creating inconsistencies.

  data Numberable = Numberable {
    first  :: IO ()
   ,second :: IO ()
   ,third  :: IO ()
  }

  parent = Numberable {first = return (), second = return (), third = return ()}

  child = parent { third = print 'third' }

And if you wanted to DI into a function:

  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)

Do you mean your own instance of a typeclass? Because that's the direct Haskell analogy to a subclass in Java. I'm not sure where the difficulty is here, as what you're describing is quite straightforward. You can also have the same type be an instance of as many typeclasses as you want, which is something that inheritance-based subclassing and tree hierarchies (is-a rather than has-a) has always made awkward.

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

Give me a new function that is a partial of some other function where I can define the 10% to change than any of the arcane polymorphism magic.

It doesn't seem hard to add a parameter and then make two stubs:

  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

There are some issues if you have a lot of parameters where you might want a record to pass them around, but specialization is easier to use than inheritance in all the cases I've seen.

I actually think FP languages I know of have this functionality, although it's used to differing degrees in each ecosystem.

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.

Haskell’s typeclasses[1] support this use case—though they are oftentimes a bit clukier to use than OOP approaches.

[1]: https://en.m.wikipedia.org/wiki/Type_class

Isn't this just composition? Function A calls B, C, and D. You make a new function E that calls B, C and F. Or higher order functions like map?

When I stopped thinking about code and data as being inherently intertwined it liberated me as both an OOP and Functional programmer.

https://news.ycombinator.com/item?id=21304512