Alex Russell: Class Warfare in TC39 | Hacker News Reader

Alex Russell: Class Warfare in TC39

infrequently.org

27 pointsjashkenas21 comments

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.

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.)

An government run monopoly is also massively successful. That doesn't mean we like it and want it to continue.

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

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

Regards

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.

> making it be more like Java

And Smalltalk, Simula, C++, Ada, Common Lisp, Objective-C, Delphi, Visual BASIC, C#, Dylan, PHP, Python, Ruby, ActionScript, Scala, OCaml, F#, and CoffeeScript.

You say that like it's a good thing. That's far from obvious.

The argument that they are formalizing a common code pattern.

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

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.

1) Classical inheritance is a restricted form of Prototypal inheritance. They can coexist. The vast majority of the world uses Classical inheritance, and there are folks (like jashkenas) who make the case that all uses of the inheritance pattern are classical (See: http://news.ycombinator.com/item?id=2594521 ).

2) Isn't this entirely naive speculation of a technical topic? If classical inheritance can be optimized to be faster than prototypal... isn't that a good thing? Do you really think that Classical vs Prototypal inheritance is a zero-sum game?

I'll defer to language designers on whether classical is inherently faster or not. I don't know that the question has been answered yet or not. What will be optimized is a matter of priority, however, and likely classes will be given a high priority on optimization (as they should).

#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.

> 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).

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.

> 1) Prototypical inheritance is different from classical inheritance.

This may be true, but JavaScript's flavor of prototypal inheritance is much closer to classical than it is to pure Self-style prototype delegation.

In Self, you make new instances by taking an existing object and cloning it. That creates a new object that delegates directly to the one you clone from.

In a class-based language, you make new instances by invoking a constructor, which is often a method on some other object that represents the class. That creates a new instance which shares a set of methods that all other objects created from that constructor share.

Which of those sounds more like JS? JS by virtue of having constructors and `prototype` already is 90% of the way to being class-based. It just lacks the syntax to make that pleasant to work with.

In JS you share the prototype. It's dishonest to say you share the methods. Of course in most instances you only want to share the methods as sharing objects and arrays isn't often useful, but that's the way JS works.

In a classical language the methods are shared and the non-function properties are copied. I would qualify this as a more than 10% difference.

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.

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(...).

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.

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"

Reply on news.ycombinator.com