The Three Big Lies About JavaScript | Hacker News Reader

The Three Big Lies About JavaScript

linkedin.com

8 pointsnathanjames5 comments

>> Prototypes are flexible. They don’t have all the ceremony that’s behind class-based OOP. In that sense, they’re fun to use. But they don’t scale well for larger applications and that’s why people jump straight to classes.

Yeah, well, unfortunately class-based OOP (as the article puts it) also doesn't scale that well, as anyone would know who's had to work on a 10+ years old codebase written in Java or C# (the typical big-OOP languages). That's why you can google 'dependency injection' and get some 2,180,000 results. Because even with all the big-OOP you can get, scaling up and maintaining a project long-term is pain.

Btw, I've mostly worked with C# and it's not that I like javascript particularly (I mostly hate it and left to my own devices I'd use Prolog everywhere) but the whole OOP thing just sucks so badly. There must have been a better way to use Dr Minsky's great idea [1], what we got now is no good.

[1] https://en.wikipedia.org/wiki/Frame_%28artificial_intelligen...

Managing large complex applications is always a major pain. There is no shortcut, no ideal solution. For all of its imperfections, class-based OOP is the best tool we have today to aid in this onerous task.

The popularity of class-based OOP is undeniable. People understand that there is no perfect solution. What would you use in its stead?

Well, OOP abstracts data, but to do it mutates many shared states across many functions, causing side-effects, breaking context of mutations, forcing to think about unpredictable order of mutations, etc., which leads to a tremendous amount of accidental complexity, hard to understand and hard to test code.

There is an inverse approach, that abstracts state mutations instead of data itself. Which means no more shared mutations, no more side-effects, no more breaking context of mutations, no more uncontrolled mutations, everything is in exact order it is supposed to be used, everything is easy to understand and easy to cover with tests, etc. And it's just as flexible in Javascript, since it supports higher-order programming, but doesn't lead to nearly as much accidental complexity. However, it's not popular and not taught at schools, like OOP.

>> Why then aren’t people screwing up when using other FP languages such as C#, Clojure, Dart, Elm, Erlang, F#, Julia, Haskell, Scala and Scheme?

First, none of those languages are required when writing for the browser. The author even states later in the article that people are indeed "forced" to use JS.

Second, who says people aren't "screwing up" when using those languages? How would you even know? Badly written JS is often public for the world to see because it's running on the client side. Those other languages are not. How would you even know if people are "screwing up"?

You gauge this be looking at complaints on the web. There are numerous posts about how JavaScript programmers abuse the language and don't understand the functional nature of programming. With most of the other FP languages, you hear the odd complaint now and then, but for the most part, if people tackle FP, they get it right. The worst complaint I've ever heard is that Haskell's monads are really hard to wrap one's head around.

Reply on news.ycombinator.com