
The Three Big Lies About JavaScript - nathanjames
https://www.linkedin.com/pulse/three-big-lies-javascript-richard-eng
======
YeGoblynQueenne
>> 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...](https://en.wikipedia.org/wiki/Frame_%28artificial_intelligence%29)

~~~
nathanjames
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?

~~~
zzzcpan
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.

------
matmar10
>> 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"?

~~~
horrido
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.

