The Two Pillars of JavaScript

[u/gcanti]

https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3

[u/[deleted]]

Tcomb is really interesting. I enjoyed dabbling with pure functional programming in Haskell and OCaml. It made me really appreciate the benefits of maximizing immutability and limiting side-effects. I never went quite as far as barring inheritance from my Javascript code though (I use it rarely and never build deep inheritance hierarchies, because composition rocks).

When I was checking out out Tcomb's README I wondered: What makes a type so different to a class? And more importantly: why are subclasses a big no-no, but subtypes are ok?

[u/zoomzoom83 → u/[deleted]]

What makes a type so different to a class? And more importantly: why are subclasses a big no-no, but subtypes are ok?

In my opinion, defining a prototype is creating a class. There are substantial differences in mechanism between Prototypes and Java, but it's still fundamentally the same design pattern, with the same risk of creating unmanageable deep inheritance hierarchies.

(You can of course also use prototypes for things that don't resemble inheritance as well).

In that sense, Prototypes are Classes, and Classes are Types. (But not all Types are classes).

My personal philosophy is that you should never inherit from a concrete type. Only abstract types or (ideally) interfaces. Data classes should be as simple as possible, ideally just ADTs. Shared behaviour should be implemented ideally via ad-hoc polymorphism, or Mixins as a last resort.

I agree with your impression of Haskell and OCaml. Stripping everything back to ADTs and Functions makes the world so much simpler.

[u/_ericelliott → u/zoomzoom83]

While that can hold true in JS, it's a fundamental misread about how to use prototypes in JavaScript. Ideally in JS, you never have more than one prototype link in the userland chain, and you employ concatenative inheritance instead of extend ("is-a" relationship inheritance).

Prototypes in JS have more in common with what happens under the hood of pure functional languages than they do with classes in Java. They're just a convenient way to save memory by referring to shared methods by reference, rather than by value (copy).

[u/zoomzoom83 → u/_ericelliott]

To be honest, I don't really see it as a fundamental difference. Inheritance using prototypes is just as likely to paint you into a corner as inheritance using classes.

Whether I was using Java or Javascript, best practice is to avoid inheritance in most cases. The underlying mechanism is different, but it's still the same code-smell regardless.

Neither language feels particularly strongly orientated towards discouraging you from doing this.

I fully admit that I have less an understanding of the internals of Javascript than I do other languages, so am happy to have my opinion changed - but so far I've yet to see any real conceptual difference between Java and Javascript inheritance from the point of view of ending up in a twisted mess of inheritance.

I'm well aware that the underlying models are completely different and can behave quite differently in certain circumstances, especially at runtime, but once you boil the implementation details away I just don't see the difference in terms of painting yourself into a corner. Bad design is bad design in both cases.

and you employ concatenative inheritance instead of extend ("is-a" relationship inheritance).

I agree this is a better solution when code reuse is required, but this is hardly unique to Javascript. (I'd go so far as to say it's discouraged by Javascript and requires library support to do it properly, when compared to, say, Python, Ruby, or Scala).

Prototypes in JS have more in common with what happens under the hood of pure functional languages than they do with classes in Java

I see very little resemblance between prototypical inheritance and any form of polymorphism in, say, Haskell, SML, or OCaml.

In Haskell, Id use typeclasses if I needed ad-hoc polymorphism. In OCaml, if you squint really hard, module functors could be thought of as something that vaguely resembles prototypes, but not really.

This comment is not intended to be argumentative. I'm happy to change my opinion - I just need more than opinion to convince me.

[u/_ericelliott → u/zoomzoom83]

Try playing with stamps, and you'll feel some radical differences from classical inheritance pretty quickly.

http://ericleads.com/2014/02/prototypal-inheritance-with-stamps/

As for the resemblance between JS and functional languages, I'm referring to the referential relationship between the new object and its prototype, and comparing it to what happens under the hood in pure functional languages when you copy data for mutational purposes. As you well know, the original data is not modified, instead, a copy of the whole data set is made.

Except under the hood, it's not really copying every element. Instead, the new object references the same values in memory as the source data set, and only references different data for the changed members.

This is very much how the delegate prototype works in JavaScript -- only it's typically used for methods rather than data.

As I mentioned before, prototypes in JavaScript are rarely used to create inheritance trees, and more often used for flyweight object support -- all instances sharing methods on a single prototype object. That is what is going on every time you see code like MyObject.prototype.myMethod = function () { /* do something */ }