

Alex Russell: Class Warfare in TC39 - jashkenas
http://infrequently.org/2012/04/class-warfare

======
scott_s
This is a good read even if you don't have a dog in the fight - maybe even
_especially_ if you don't, because it's easier to evaluate the arguments
objectively, and see how they apply to your world.

An observation: JavaScript and Java are arguing over adding complementary
features.

~~~
gruseom
But what arguments? His answer to "why classes at all" is that higher-level
languages are good because they reduce complexity. OK. But then he takes for
granted that his class-based approach is what does this. That's not an
argument, that's assuming your conclusion.

The rest of the post says that because a committee has been arguing for 10
years, we're overdue for just adding _something_. That hardly follows.
Sometimes adding "something" for the sake of it fucks things up. First do no
harm?

Personally I'm glad that "luddites" have blocked these attempts to "fix"
arguably the most important language in the world by making it be more like
Java. As the OP points out, while the committee has been arguing, "JS has gone
from being important to being critical to the construction of large systems",
i.e. succeeding massively.

(Not that I don't empathize with how frustrating it must be to have a
committee block what you think are all the good ideas.)

~~~
slightlyoff
Hi gruseom:

I'm the author of the original post.

There seems to be some serious (willful?) misunderstanding here about what is
being proposed. Instead of adding something foreign, the class syntax that
we've nearly got settled is sugar for what we usually write in JS, albiet
under a dozen or so different patterns and library conventions. See:
[http://infrequently.org/2011/09/why-class-doesnt-mean-
what-y...](http://infrequently.org/2011/09/why-class-doesnt-mean-what-you-
think-it-means/)

I'm also not suggesting that length of debate necessitates action. The near-
consensus on the committee for adding classes isn't my doing; I'm merely
arguing that it's worth doing a smaller thing and debating what extensions to
make in due time. And if you look at what's being added (again, I'm not sure
you have a grasp on it in any way), it's clear that we _are_ doing no harm
with Max/Min classes.

Invoking Java to describe what's being proposed is purely a slur. Indeed, the
arguments which I'm attempting to talk down are the ones which would drag a
class proposal _more_ towards Java (not less).

What's frustrating, in the end, is to see someone so obviously smart making
such spurious arguments. Please read up before engaging further:
[http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...](http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes)

Regards

~~~
gruseom
I hear your annoyance. I hope it's only that my comment seemed that way
because we're coming from very different perspectives.

By "more like Java" I just meant adding classes at all. I'm uninterested in
that way of programming - not out of ignorance, I did it for years and I think
it's a gigantic cargo cult. That JS somehow escaped it is, in my view, a small
miracle. That we have JS at all is a miracle. For all its flaws, it's a small,
hackable, dynamic language that retained enough magic from its Lisp/Self
inspirations to spawn a new galaxy of creativity. I don't believe that if it
had been done more "properly" we'd be better off today. Great inventions often
live on the improper side of the proper/improper divide. JS succeeded on the
web while its "proper" cousin, the one designed for "programming in the
large", the one organized around "good" practices (including classes), failed.
I think that fact is deep and mysterious and the most important thing is not
to mess with it.

So while you say it's clear that you'd be doing no harm, that's far from clear
to me. I read the links you provided and still think that.

But I acknowledge there are degrees here, and if you're mostly trying to
prevent JS from turning into Java, thanks. I confess, though, that when you
say the _near_ consensus, my sympathies immediately leap to whoever the
holdout is :)

Not trying to persuade you; just trying to unpack what I said enough to not
seem thoughtlessly rude.

------
jamieb
>Not only should we write off the luddites, we should consider every step
towards lower complexity good and steps towards complexity and slower
understanding to be bad and actively harmful.

Fine. Here is a program written in my new JS proposal:

    
    
      everything;
    

That's it. Just one line. It does everything. Of course, "everything" means
exactly this one kind of app that I have decided is good enough for everyone.
We're all writing Facebook apps, after all. If someone is going to complain
that "everything" isn't flexible enough to do what they want, well we can just
write-off those luddites because they want to be able to write "everything(
more detail)", which is obviously more complex.

Reduced complexity must be balanced against reduced expressivity. "Well, way
to take it to the extreme, Jamie. Classes are hardly so radical, and you don't
have to use them".

Ok, well we'll just delete all C compilers from our systems, and use C++
compilers, right?

>But then why any language feature at all? Why isn’t assembler good enough for
everyone? Or C? Or C++?

Why isnt C++ good enough for C programmers? Or assembler programmers?

If I don't like C++ I can program in C. While in theory I can write run plain
old C through a C++ compiler, the reality is that some things are different.
Most importantly, the thought being put in by the compiler developers to solve
language problems were being spent solving C++ problems, not C problems.

Why does this matter? Question: are browsers going to support two different
languages? JS and JS++? No?

So now imagine that we were proposing deleting every C compiler and only
allowing C++. Would there be a shitstorm? Quite.

Here are two much more relevant questions:

1\. why are people writing Scala, or Clojure?

2\. How does the JVM's class-only system make certain Scala constructs non-
optimal.

------
MatthewPhillips
I'm against the class keyword for a couple of reasons:

1) Prototypical inheritance is different from classical inheritance. If we add
the class keyword with either have to make it work like most classical
languages work (Python, Java, C#, Ruby) or we confuse new JS developers with
keywords that look familiar but work differently.

2) The argument is that "you don't have to use it", which is fine, but in
reality we know that browser vendors will optimize the hell out of the class
keyword and we'll be forced to use it for that reason alone.

~~~
slightlyoff
#1 is just FUD. JavaScript is JavaScript. Class in JS is a shorthand for
function and functions prototypically delegate. That you're not writing in
Java/Python/C#/Ruby should be pretty obvious.

#2 doesn't bear much relationship to reality. There will be near zero
correlation between "class" and performance. What can (and today, does) change
the performance of objects is having their shape change markedly after
construction. V8, for instance, already includes heuristics to know when a
class is "done" being constructed, allowing it to apply most of the typed-
language tricks in the bag for objects which are entirely unfrozen. In current
code, it's actually a _de-optimizer_ to call Object.freeze() and there's no
reason to think you'll get anything faster for using "class" than by writing
code which doesn't change its shape very much.

You will, however, finally be able to read and share code more easily.

~~~
MatthewPhillips
> That you're not writing in Java/Python/C#/Ruby should be pretty obvious.

I don't think it's obvious at all that the keyword "class" is going to be
fundamentally different from whatever OO language you are coming from. Isn't
this the single biggest reason why many developers have difficulty learning
JavaScript?

> There will be near zero correlation between "class" and performance.

There already is performance differences between constructor functions and
Object.create (in terms of initialization, that is).

~~~
slightlyoff
Object.create() creates no closure. You've already paid for in the context in
which you're .create()-ing. In any case, performance optimization is what
happens when something becomes common enough to work its way into benchmarks.
And calling out a delta now that's probably not your bottleneck
seems...um...less than useful.

------
voidr
Never in my life I have read so much rambling in one place. I can summarize
the whole article in one tweet(removing some nonsense along the way): "The
ECMAScript standard should make it easy to use 'classical' inheritance because
that's what kids learn in school."

This should have been just a tweet, not a gargantuan article, that just talks
about the same thing over and over.

If you want to write in a classical style, you can do it today, if you want
all your favorite class features, you could just write an abstraction that
does it all. If you are obsessed with doing it with syntax just use
CoffeeScript or something like that, heck you could just use GWT and just
write the whole thing in Java and not even care about JS.

The committee doesn't have a standard for class yet because it's really a hard
problem, they can easily turn JS into the next PHP if they get it wrong.

Something is needed to make classical people happy, but not the expense of
language integrity.

> Don’t add classes and the world at large thinks of JS as a joke and a toy

This is both ignorant and moronic, C must be a toy and a joke then also the
author probably failed to notice that both C# and Java are adding lambdas, and
other nice functional features.

------
ender7
I would love to see class syntax in JS. Until then, this is the system I use:

    
    
      var MyClass = classdef(SuperClass, MixIn, AnotherMixIn, {
        constructor: function() {
          ...
        },
        publicFunc: function() {
          ...
        },
        _privateFunc: function() {
          ...
        }
      });
    

Where the 'classdef' function takes an optional superclass, an optional set of
mixins (their properties will be copied to the class's prototype), and an
object defining the class. The function itself is fairly easy to write, and
allows you to define classes quickly, without having to retype
MyClass.prototype.blah all the time.

Some other implementations that I've seen add the ability to refer to super(),
or to say MyClass.extend(...).

~~~
MatthewPhillips
We've all been writing a hundred varieties of this same thing for years which
is why Alex is championing this "one correct way" so we can all move on to
arguing about something else.

------
zackzackzack
Modified quotation: "Where there’s a new fad in [anything], odds are high that
it is being touted as a solution to some aggregate behavior which causes a
reasonable local decision to become globally sub-optimal"

