I don't mean to be argumentative (being argumentative on HN is so passé), but what you just quoted is so full of shit that I feel like someone is obligated to comment.
In the prototypal model — as it exists in JavaScript — you do do all of that. You make a series of prototypes that you intend to use in your application, and those prototypes (or classes), serve as the effective taxonomy for many of the objects you're making in your app.
Classes in ES6 are prototypes. They don't lock you into any such Java-esque paradigm unless you're going to be willfully ignorant about them.
Please don't repeat baloney just because Crockford said it.
---
For example, to be concrete:
class Crockford {
speechify() {
return "...you're going to get the taxonomy wrong. It’s inevitable.";
}
}
A class. A terrible, inflexible, prototype-destroying, paradigm-locking-in, JavaScript class. Eww, gross.
But wait! What's this?
Crockford.prototype.speechify = function() {
return "...the shape of an object can change at any instant, because \
someone can fiddle with the prototype.";
};
You can have your classical cake and eat prototypal cookies too. Because in any decent dynamic language, the two concepts are synonymous.
It's not baloney IMO. As someone who's coded C since the 80s and C++ since the 90s I find JavaScript massively freeing.
In C++ (and similar classical languages) in order to be able to pass in different implementations of a class you need to create a base class or interface. You don't need to do this in JavaScript.
In JavaScript you can build objects on the fly. In fact he goes on to say
> so I used to think that the important thing in JavaScript was prototypal inheritance I now think it is Class Free object oriented programing. I think that is JavaScript’s gift to humanity. That’s the thing that makes it a really interesting important language, is that it did that. That we can use functions in order to create objects and it simple and elegant and powerful and fast...
And it's true. Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript. In my own experience I have a mutli-user networking system written in JavaScript and a library in C#. To reimplement the same things in JavaScript in C# is a huge amount of code bloat. I have to make classes and meta classes and all kinds of other indirection just so I can make an Event system that is generic. In JavaScript that's 2 or 3 lines
That we don't actually need all the structure to get shit done is what people are finally coming to realize.
The problem with 'class' in ES6 is that it will prevent people from learning this new, easier, faster, simpler way of working because instead they just bring the classical baggage to JavaScript. That's in fact what most programmers from classical languages do. It's what I did for years until I started actually grokking JavaScript. ES6 "class" will only make it take longer for people to actually get pass their old ways.
> As someone who's coded C since the 80s and C++ since the 90s I find JavaScript massively freeing.
I've gone back and forth between dynamic and static and strict and loose in every combination and I don't find the dynamic/loose to be particularly freeing anymore. The problem is you can't really rely on anything. It doesn't so much as solve the problem that Crockford is talking about, it just moves it somewhere else. You don't have to refactor but you're going to end up with two (or more) different things that exist at the same time instead of one.
> Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript.
This is a great point and it's a perfect example of the advantages and the horrors of the JavaScript model. A mock is supposed to be an object that does something completely different (typically nothing) but otherwise looks and functions like the real thing. Maybe just in one slight exceptional way. JavaScript makes this easy. But it also makes it easy to make those same changes outside of mocking and tests and that is just debugging hell waiting to happen.
It could but some of us have had the experience of massive productive increases in JavaScript over our decades of experience in statically typed languages.
And note I'm specifically calling out JavaScript. Other dynamic languages IMO haven't provided the same benefits because they're still following old models.
When you truly grok JavaScript and stop trying to use it like your other languages it really starts to shine. It's not perfect but it is different.
> And it's true. Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript. In my own experience I have a mutli-user networking system written in JavaScript and a library in C#. To reimplement the same things in JavaScript in C# is a huge amount of code bloat. I have to make classes and meta classes and all kinds of other indirection just so I can make an Event system that is generic. In JavaScript that's 2 or 3 lines
That does not follow from what you quoted, and what you quoted is a non-sequitur to start with.
What you're raving about can be achieved just as easily in any dynamically typed language. Hell you probably get 80~90% of that in a structurally typed language (OCaml objects, Go).
> In JavaScript you can build objects on the fly.
Which you can do in many other languages, including statically typed ones. Here's an object in Ocaml:
# let s = object
val mutable v = [0; 2]
method pop =
match v with
| hd :: tl ->
v <- tl;
Some hd
| [] -> None
method push hd =
v <- hd :: v
end
And that's statically typed.
> The problem with 'class' in ES6 is that it will prevent people from learning this new, easier, faster, simpler way of working because instead they just bring the classical baggage to JavaScript.
That's patent nonsense, not to mention ES6's class shortcuts apply to object literals as well, the only thing the class statement does is remove the bullshit and mostly useless boilerplate Javascript demands when creating a reusable prototype due to it being a garbage language, and its "prototypal" object system being there not because it's good and going to save the masses but because it was the easiest way to have an object system working in a week. It's just a sad and pitiful shadow of Self's object system from which it draws so little you have to know the relation's there to find it.
> That we don't actually need all the structure to get shit done is what people are finally coming to realize.
Getting stuff done until the code base grows and others have to adapt or build up on the code you've written : the idea of bringing in structure is to encode knowledge about the problem you are solving and keeps it all maintainable (admitted, if done right).
> In C++ (and similar classical languages) in order to be able to pass in different implementations of a class you need to create a base class or interface.
And that is a good thing IMHO, see above. However I agree that, particularly in C++, an interface definition is very verbose. Unfortunately it has no pure Interface concept.
As a javascript programmer, I have perceived es6 "classes" as nothing but syntactic sugar. They should just construct the equivalent constructor+prototype combo. You can still create anonymous objects quickly, and use any object as prototype for another.
Yes, but let's admit it, the presence of classes will inevitably lead to their ever-presence, if only for the fact that they are what most people coming from other languages are used to.
The absence of class already leads to their ever presence, each project simply reimplements its own instead of using the built-in syntactic sugar. The class sugar is simply a way for the creation of (prototype + constructor) pairs not to be a pain in the ass, nothing more and nothing less.
" They're sooooooooo much easier to
write than anything for classical languages
because it's so easy to do in JavaScript."
You can do that in a language with classes and even one with optional types e.g. you can use jasmine perfectly well to mock typescript objects (because they are just JavaScript dynamic objects)
" I have to
make classes and meta classes and all kinds of
other indirection just so I can make an Event
system that is generic."
I remember reading Gilad Bracha saying somewhere that enabling exactly this kind of system was exactly one of the use cases for Dart which is class based with optional types. You can have your cake and eat it too!
I think you're confusing this new Chrome-only thing with ES6 classes that just saves you from using a library to create constructor/prototype objects. In ES6 "class" is just a keyword that makes it easy to contruct objects that are very typical in day-to-day JS. Inheritance is already a thing that happens.
I'm not. See above, "class free object oriented programming". You don't need prototypical inheritance to have inheritance in JavaScript. Crockford gives examples. You don't need the "class" keyword. All it's going to do is steer people in the wrong direction.
That is not inheritance. `instanceof` doesn't work. There would be no way to know that an object from derive dis of the type of base.
That's also very memory inefficient. The method function gets made for every instance. With prototypes there would be only 1 function in memory. This stuff matters at scale.
You've got a gig of ram in your pocket. Memory doesn't matter for 99.99999% of apps. The memory taken by your objects isn't where your memory goes. It goes to images and other big stuff. A few extra bytes per object isn't going to kill you. Optimize for programmer time not memory, especially not in memory on things that don't matter.
Why are you using "instanceof". The whole point of inheritance is you shouldn't have to ask. If you are asking your doing it wrong
and then how do you implement super with your system? because that's the point of prototypes,the fact that you're not overloading methods but you have access to the prototype chain.much harder to do with your method.
In the prototypal model — as it exists in JavaScript — you do do all of that. You make a series of prototypes that you intend to use in your application, and those prototypes (or classes), serve as the effective taxonomy for many of the objects you're making in your app.
Classes in ES6 are prototypes. They don't lock you into any such Java-esque paradigm unless you're going to be willfully ignorant about them.
Please don't repeat baloney just because Crockford said it.
---
For example, to be concrete:
A class. A terrible, inflexible, prototype-destroying, paradigm-locking-in, JavaScript class. Eww, gross.But wait! What's this?
You can have your classical cake and eat prototypal cookies too. Because in any decent dynamic language, the two concepts are synonymous.