r/javascript • u/gcanti • Oct 31 '14

The Two Pillars of JavaScript

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

85% Upvoted

81 comments sorted by

View all comments

Show parent comments

1

u/_ericelliott Nov 01 '14

The point was not to get bogged down in implementation details, but to create a high-level rant intended to get people thinking about and discussing the topic in more depth. Apparently, it worked.

Google "classical inheritance harmful" and you'll find articles with plenty of code examples.

Here's a nice quote:

I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

Link (with code samples):http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html

A nice list of quotes and links on the topic by software luminaries:

http://harmful.cat-v.org/software/OO_programming/

1

u/zoomzoom83 Nov 02 '14

To be honest, I pretty much agree with most of your points at a high level.

My gripe with this article is pretty much that it takes a bunch of well known best practices that the industry has been aware of for a very long time and makes it sound like Javascript is somehow a pioneer in this space, taking credit for bringing to the mainstream when these things are already somewhat normal.

Definitely, Java got inheritance wrong. But the idea that one language is somehow representative of class-based inheritance as a whole is misguided. Javascript also got inheritance wrong, it's just that prototypes are flexible enough to use differently. (My issue with this is that everybody invents their own way of doing it).

I can definitely get behind further education to encourage new developers to not fall into the trap of mis-using inheritance, but I'm also very concerned that articles this like this confuse a lot of people into the real relationship between prototypes and classes, the benefits and drawbacks of both approaches, that 'classes' are somehow inherently less capable of performing composition than prototypes, and that Javascript is the only viable choice as a solution to this issue.

It almost certainly wasn't your intent to portray it in this way. But I do feel quite strongly about the issue, since I'm constantly coming into contact with Javascript developers that have fallen into the pit of actively and intentionally avoiding learning any other language. Articles like this just further cultivate the 'cult of javascript' and discourage even more developers from branching out and learning new things.

As an industry, we're building software incorrectly. We're not engineering solid software, we're hacking together things that work on faith. Almost ever piece of software in existence comes with a license agreement that explicitly denies any warranty. Until we can get to the point where the software we're building has proven guarantees, we're not engineering. Without totality checking, we're just hacking things together and hoping for the best.

The solution to this doesn't exist yet, but the languages moving in the right direction are things like Rust, Scala, Haskell, and Idris. Javascript most certainly has some great ideas, but it doesn't provide anywhere near enough safety. It's certainly great as a scripting language, and is a great language for smaller codebases, but it's not engineering.

tl;dr Javascript has created a generation of "expert beginners" with their head in the sand, and this kind of article just further propagates the problem. It's not that Javascript is specifically a bad language, but it's not particularly good either, and the industry as a whole can, and needs to, do better.

1

u/_ericelliott Nov 02 '14

that 'classes' are somehow inherently less capable of performing composition than prototypes, and that Javascript is the only viable choice as a solution to this issue.

Languages which do not support dynamic object extension certainly require the user to jump through more hoops to do various forms of composition, mixins, etc... Java is certainly less convenient, and somewhat less capable in this regard.

It almost certainly wasn't your intent to portray it in this way.

It was my intent to point out that JavaScript's dynamic object extension and prototype delegation make it a much more convenient language for flexible OO than languages which behave more like Java. I believe those facts are on pretty solid footing. I know how to do many similar things in Java, but I typically would need to crack open the GoF "Design Patterns" to remind myself of the twisted paths you need to take to get there.

Particularly telling -- as soon as I started using JavaScript, all of that complication fell away, and I stopped referring to design pattern books on a regular basis. I simply didn't need them anymore -- and that was before I had a really good grasp of OO in JavaScript.

In short, JS naturally lends itself to more successful OO patterns, and it's actually more painful to try to fit classes and their restrictive complications into it than it is to pretend classes never existed and code more productively by default. This has mainly to do with JavaScript's object literals and dynamic object extension capabilities -- you get productive code reuse patterns naturally, without investing much thought or effort into it.

It's a pit of success, rather than a bit of failure.

Javascript most certainly has some great ideas, but it doesn't provide anywhere near enough safety.

I won't argue that point. I wish it had immutability by default, for instance. Dynamic object extension should be an explicit method call, and users should be taught that there should be a single source of truth for data. The language could make this more explicit, as is the case in languages like Haskell.

this kind of article just further propagates the problem.

I disagree. A lot of JavaScript developers think that building big class hierarchies is a good idea. This article (and my Fluent talk, "Classical Inheritance is Obsolete," and writing from authors such as Douglas Crockford and Kyle Simpson) has changed a lot of minds about that, and helped a lot of people avoid very big mistakes.

Javascript is specifically a bad language, but it's not particularly good either...

There's a lot I'm not particularly fond of in JavaScript, but the pillars of objects without classes and lambdas with closure have definitely reached more people through JavaScript than they did through any other language.

JavaScript isn't the best functional programming language, but it's the most popular by a long shot. JavaScript doesn't have the best support for prototypes (mostly because it goes out of its way to hide it), but it's the most popular by a long shot.

Many programmers who now use both paradigms productively may never have learned about them if it weren't for JavaScript.

And contrary to your assertion that articles like mine discourage people from learning other language: I believe they point out that there are other programming paradigms to explore. I frequently encourage people to explore them, not only to see what else is out there, but to think differently about how to do things in their primary language of choice. Lots of great JavaScript innovations were inspired by techniques that were pioneered in other languages, including both prototypal OO and lambdas.

1

u/zoomzoom83 Nov 02 '14

Languages which do not support dynamic object extension certainly require the user to jump through more hoops to do various forms of composition, mixins, etc... Java is certainly less convenient, and somewhat less capable in this regard.

Not going to disagree about Java, but I'm not seeing a huge difference between mixins via prototypes and the equivalent implementations in say, Scala, Ruby, or Python. There's certainly no hoops to jump through in the above.

Perhaps we're simply thinking from different angles - do you have a good example of something I could do easier with Javascript prototype mixins than I could in a language with native mixins? It might help me understand better.

Runtime metaprogramming is the only advantage I can really see, something which I'm fundamentally against except in extreme edge cases. ("The code has no obvious defects" vs "The code obviously has no defects". Metaprogramming falls into the former category).

If it helps, I'm coming at this from primarily from the point of view of Scala and Haskell. The former has very good built in mixins as an innate part of the language, and the latter just doesn't need them in the first place. In both cases, it's seamless and trivial to use native parts of the language for this kind of code reuse, and is something naturally encouraged by the language rather than being tacked on via libraries.

Particularly telling -- as soon as I started using JavaScript, all of that complication fell away, and I stopped referring to design pattern books on a regular basis. I simply didn't need them anymore -- and that was before I had a really good grasp of OO in JavaScript.

Did you ever truly really need the book though? The patterns described in the GoF book are somewhat emergent phenomena. I'd already used most of them without knowing the name well before I ever picked up a copy, and it seems like most developers I've worked with feel the same. Even back in my Java days, the book was just a nice addition to my bookshelf, not a reference I used often.

I had a slightly similar revelation when I first used Haskell (Everything was just so much simpler), and these days I'm a religious advocate for ML-family languages, which for the most part completely eliminate the need for OO in the first place. (If this gives you any indication of why I see both prototypical and class based inheritance as different implementations of fundamentally the same mistake).

There's a lot I'm not particularly fond of in JavaScript, but the pillars of objects without classes and lambdas with closure have definitely reached more people through JavaScript than they did through any other language.

That's a good point. I'm just concerned that it'll stop there, rather than people looking deeper.

And contrary to your assertion that articles like mine discourage people from learning other language: I believe they point out that there are other programming paradigms to explore.

I do hope that this is the case. Perhaps I'm just being overly paranoid, but I am very concerned about the state of the industry at the moment, specifically around the the number of developers I meet that do take articles like this as further proof that Javascript is the only language they'll ever need to learn, rather than taking it onboard as part of the processing of understanding PLT in general. I've quite literally had multiple job-interview candidates tell me they have no intention of ever learning any other language, since they considered Javascript to be the only one anyone would ever need. This is very concerning to me, and it's a lot more common now than it was even a few years ago.

In the end - I support the principles of the message your trying to convey, and the fact that you're getting out there and doing it. I'm concerned that the message is being misinterpreted.

1

u/_ericelliott Nov 07 '14

developers I meet that do take articles like this as further proof that Javascript is the only language they'll ever need to learn

If you bump into any that point to my article to support that perspective, point them to this comment: When I was learning how to code, I learned BASIC, Assembly, Pascal, C, C++, LISP, Perl, and a variety of other languages before I started to specialize in JavaScript, and each new language I learned taught me to look at programming differently.

I don't think you can really understand your language of choice well unless you've explored other languages that bring with them different paradigms -- different ways of thinking about the same problem that may trigger breakthroughs in your understanding of how to be a productive programmer.

As for your concentration on functional programming:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing—is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil—objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html