Google SoundScript: faster OOP for JavaScript

http://www.2ality.com/2015/02/soundscript.html?hn

by jashkenas • 11 years ago

68 60 11 years ago

dracolytch• 11 years ago

So there have been a lot of contenders to replace JavaScript, and it hasn't budged from it's market seat at all. Here's why:

You can do almost anything in JavaScript these days. The down side? You can do almost ~anything~ in JS these days. Including lots of stupid things.

Since JS works extremely well for user interaction, and is "good enough" for simple object-oriented programs, it will likely never go away in the foreseeable future in these realms. What I think things like SoundScript are for, is 1) for people who are used to strongly-typed programming languages to feel more comfortable on the web (which is actually pretty important), and 2) for larger OO or enterprise-style systems that really shouldn't have been written in JS in the first place (I'm looking at you Angular).

I wonder if it will end up like Go, though. An interesting language which never gets more than a niche market.

estava• 11 years ago

Google are trying to find a direction for web programming. The browsers have made plugins obsolete, but the plugins did bring something that the standard web technologies may have been missing.

What is hard is to change JavaScript from the outside. They may have found that impossible to do. The direction started with asm.js shows that JavaScript needs to change from the inside. JavaScript can be changed and remain largely compatible, but it will not be without the drawbacks. The path started with transpiling and polyfills may help to keep some backward compatibility, for example. :-)

Not all problems can be solved with just 1 technology. It will continue to look more like a mash-up. The challenge is to make it cross-platform. Google have to run ads on those things for it to help with the bottom line.

smrtinsert2• 11 years ago

In my opinion Javascript is on its path to marginalization. Just glancing the recent tooling options for ClojureScript and TypeScript, I'm pretty sure now is the time to start putting your alt-js experience ahead of Javascript on the resume. The syntactical checks are great (typescript ides) or instant feedback (clojurescript figwheel) but for me the killer is the performance optimization over 'raw' Javascript due to compilation optimizations.

Better tooling, better performance, why would I want to go back?

The language of the future includes a Javascript compilation target.

htilford• 11 years ago

The typing notation of TypeScript is on it's way to becoming part of Javascript. See http://www.2ality.com/2014/10/typed-javascript.html

Going forward does not mean abandoning Javascript, just abandoning ES5

untog• 11 years ago

Before you start talking about what to put on your resume, I'd look at what job descriptions are asking for. I haven't seen many asking for ClojureScript or TypeScript yet.

TypeScript (and to a lesser extent CoffeeScript) seem fine to me, but ClojureScript looks very different to JS. I'd always advise someone to learn JS first, then your compiled language of choice.

jerf• 11 years ago

I'm not sure you read the article. "Soundscript" is just a fancy name for "notifying the Javascript interpreter that you promise never to do certain things, thus the interpreter can stop checking for them on every access and the optimizer is allowed to make stronger assumptions". It's not a new language so much as slightly different 100%-backwards-compatible dialect.

It is a way of deliberately putting down some of the often-silly dynamism Javascript provides.

Whether it takes off or not, I can't call it a "contender to replace Javascript" when it is Javascript.

fineline• 11 years ago

100% Backwards compatible? So this will work in IE6? Or 7, or 8, or 9, or 10?

I think you meant 100% backwards compatible with ES6. As far as that goes, it sounds like a pretty good addition to the ES6 standard.

adrianlmm• 11 years ago

I thing this is a testament that strong typed is more desired than dynamic.

greggman9• 11 years ago

This makes sad, as Douglas Crockford said in this recent talk

The prototypal school has a lot of advantages particularly compared to the classical school
So in the classical school you have to create a classification of all the objects that are likely to be in your system. And, it's a lot of work to figure out what they all are and identify them and what their characteristics are and so on and then you have to determine how they are all related to each other, what’s going to inherit from what, what’s going to implement what, what’s going to interface with what, and that’s really complicated. And it usually happens at the beginning of the project before you fully understand what all this stuff means. So it’s likely your going to get the taxonomy wrong. It’s inevitable.
And then you’ve got two hard choices. One is you have to live with a broken taxonomy and if you do that then with each new class you introduce things get weirder and weirder because everything’s wrong, or you have to refactor and refactoring is hard and it’s error prone and it’s another world of hurt.
Those are your two choices and people who grew up in the classical school assume that’s just the way life is so no sense in complaining about it since that’s life.
But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it.
So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off)
And so that’s why I think classes in ES6 are a bad part because they lock you into that paradigm.
applause
So when you’re locked in a paradigm like that, when you can’t see past it, you just have no understanding how miserable you are. And you’ll never know until you change your model

from https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s

jashkenas• 11 years ago

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.

greggman9• 11 years ago

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.

Touche5• 11 years ago

ES6 classes are just syntactic sugar for constructor/prototypes like we write them today. You can mutate them as much as you like.

greggman9• 11 years ago

not in SoundScript they aren't

adamlett• 11 years ago

I feel like the concepts are being abused here. Prototypical — at least in my understanding — refers to a mechanism of inheritance or delegation, and not as Crockford uses the term to the way you build your objects. Confusingly, JavaScript didn't even have prototypical inheritance until relatively recently, because even though every object had a prototype, it couldn't be set or changed on an individual basis, but was determined solely by which Constructor (read: Class) that created it, which made JavaScript's inheritance mechanism essentially indistinguishable from the classical, albeit with more obscure nomenclature.

bad_user• 11 years ago

I don't get it. I know how prototypes in Javascript work, I can agree that you get a certain degree of flexibility that you don't get with class-based languages, which sometimes is useful, however people are still modeling classes in Javascript and people blaming education have the burden of proof - show problems that could have been solved with classes, but that were solved with a "class free" design instead.

And heck, I'll go further - in my mind, both class-based and prototype-based OOP, at least as present in Javascript or other mainstream languages, sucks because it mixes data with behavior and still suffers from the expression problem, because while you can take any object and modify it for a new interface, a process called monkey patching, that's just a terrible way of doing it.

OOP as a means to achieve polymorphism is simply inadequate for many use-cases. Sometimes it is much better to have type-classes (or similar, like protocols in Clojure). So you know, comparing 2 ways of dealing with OOP, misses the point that OOP on the whole is not enough, even broken as some would say.

masklinn5• 11 years ago

I can agree that you get a certain degree of flexibility that you don't get with class-based languages

That's not even the case. Not in Javascript anyway. The only thing you get is not having a separate hierarchy of class objects.

munificent2• 11 years ago

You just make an object, if you don’t like the way it works you make another one and that is literally it.

This is, like jashekanas eloquently puts it, so full of shit.

You're still creating a bunch of objects. Unless you are a mashocist (or a sadist, if other people have to maintain your code), you are still going to want to reuse methods between those objects.

Once you do that, you have to have some organization between what gets reused how. Sure, prototypes give you more freedom to define different ways of organizing and reusing behavior across objects. In practice, single-delegation actually works pretty well most of the time.

So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off)

It's not that you don't have to create a taxonomy in JS. It's, "First you have to conceive and implement the very idea of a taxonomy itself. Then you get to use that to create a taxonomy."

You need to reuse code somehow. Figuring out a scheme for doing that is metaprogramming. JS basically says, "Well, you have to do this metaprogramming before you can get to the task you actually care about."

Using classes (or any other baked-in reuse scheme like parent slots in Self) just means the language has done the metaprogramming for you and you can use it out of the box.

The flexibility JS gives you is nice when the language's built-in mechanisms for code reuse aren't a good fit. But, so far, most homegrown code-reuse-systems don't seem to be that much better than what classes (with maybe some mixin or trait special sauce on top) provide.

drapper2• 11 years ago

You're still creating a bunch of objects. Unless you are a mashocist (...) you are still going to want to reuse methods between those objects.

Aaaaaaand solution for that doesn't have to be a class (or something pretending to be a class), but for example a collection of functions/methods that you attach to an object, so you for example assign behaviour to data. This is something that Reginald Braithwaite for example advocates.

coldtea• 11 years ago

But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it.

Yeah, which goes to show you shouldn't listen to Douglas Cockford.

First, what he describes is playing in a REPL at best. You don't just "make another [object] if you don't like the way the fist one works" when you write a program, unless you write a structureless blob. You still have to think about your objects and/or inheritance chain, be it prototypal or not.

Second, ES6 classes are nothing more than syntactic sugar over barebones prototypal inheritance.

Third, you already do all that stuff in JS. You have to write a lot of boilerplate code (and usually everyone does a slightly different version) to get the same end result.

randomguy7788• 11 years ago

although i agree somewhat, prototypal inheritance does nothing to help solve the taxonomy.

the article below i think explains the situation much better: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...

cromwellian2• 11 years ago

I see the 'stricter' mode (without types) as a kind of asm.js assertion. The code is 100% legal JS and will work on all JS VMs, you're just telling the VM that it can assume you won't modify class prototypes after load. The VM can check this assertion and fail if you violate it, and then run at fulls peed.

On other VMs that ignore "use 'stricter'" the same code runs, just less optimized by the VM.

The stricter+types stuff will be harder to swallow by the community since it extends the language grammar. That will break other VMs without transpilation.

Maybe they could do a "use 'stricter+asm'" which has the class-sealing properties SoundScript, but with the type-declaration syntax of asm.js (|0, 0, etc)

azakai• 11 years ago

I'm still unclear on the relevant details, though. If this is just a hint - no semantic effect - then JS engines already speculate and assume you won't modify class prototypes after load. Such speculation is what JS engines put a lot of work into.

Maybe the hint would justify more aggressive speculation, I suppose?

Or, if this is more than a hint - if it has semantic effects, like "use strict" does - then this would be very different than "use asm".

I guess when more info comes out this will become clearer.

cromwellian2• 11 years ago

I'm guessing that it implicitly implies Object.seal() on all prototypes.

Any legal program that uses 'stricter' and depends on sealed prototypes would be a legal program on a VM that ignores stricter, except in the case of bugs where code was modifying prototypes when it shouldn't, but those would presumably be caught during testing on VMs which did use it.

Presumably, "use stricter" on a codebase that contained attempted prototype modifications would generate errors instead of silent failures.

I don't know the full reasoning behind this, but it might be more about startup time than runtime speed. If you assume early-bound classes, snapshotting becomes a lot easier, you can ahead-of-time trivially compile hidden classes without having to discover them after the fact, and without having to put in code to revert the assumptions later.

Seems like this would be a startup and memory win mobile web, especially if you can easily snapshot a previously loaded app.

mraleph• 11 years ago

Sealing prototypes is easy - V8 already "pseudo"seals them: it removes the map checks against prototypes and instead deoptimizes the code depending on hidden classes when somebody changes them.

Similar pseudo-sealing technique can be applied to objects: when optimizing some code you can assume that if some hidden class is a leaf in the transition tree it is no likely to change - then make the code depend on this assumption. This would mean you only need to check this once.

I think the most interesting part that stricter-minus-types mode brings to the table (at least it's informally described part) are hole-less arrays. This is something that is missing from the ES as it is described now: new Array(N) is producing a hole-full array. V8 is capable of tracking whether array is containing holes or not - but the way to efficiently preallocate holeless version is simply missing from the ECMAScript.

misfo• 11 years ago

Could this be (partially) motivated by making Dart-compiled JS run faster in Chrome?

chipsy• 11 years ago

If I had to place a bet now, it would be on asm.js. It's the abstraction that nobody wants but everyone can live with, because it takes the standards bodies out of the equation on the higher level decisions that have to be done differently per domain.

tracker12• 11 years ago

IMHO for the most part, programming with classes in JS is just waiting for pain. If you use generic objects for state, then compose your applications by using generic functions passing in state, and any other arguments that function needs to operate, it goes much smoother than OOP.

You can create wrappers by binding independent methods against said state for composite objects with encapsulation... It tends to keep code cleaner and more modular. Sometimes just thinking about the problem differently will lead to a more elegant solution...

    var Promise = require('i-promise')
        ,getDealerPendingStream = require('./process-get-dealer-pending-stream')
        ,transformDealerPending = require('./process-transform-dealer-pending-stream')
        ,calculatePayment = require('./process-payment-calculation')
        ,logTransaction = require('./process-log-transaction')
        ,updateSalesforce = require('./process-update-salesforce')
        ,runPayment = require('./process-payment')
        ,logItemOutput = require('./process-log-item-output')
        ;

    module.exports = function(){
      return new Promise(function(resolve, reject) {
        getDealerPendingStream()
          .pipe(transformDealerPending())
          .pipe(calculatePayment())
          .pipe(runPayment())
          .pipe(logTransaction())
          .pipe(updateSalesforce())
          .pipe(logItemOutput()) //email notifications for processing errors (dataObject.error)
          .on('error', reject) //should never happen
          .on('end', resolve)
          .resume() // needed so last stream can process data
          ;
      });
    }

aikah3• 11 years ago

How would you write a GUI framework with this method? because that's where OOP shines.Here,you're just doing sequential operations on a chunk of data.How would you write layouts and widgets? people often forget that OOP was kind of created because it solves the UI problem.

masklinn5• 11 years ago

Same way Elm does?

tracker12• 11 years ago

You can still uses events and state against UI constructs without going full-on OOP. An application can render in similar ways to how flux, mercury, elm and other patterns are handled. (not suggesting a virtual DOM... but there's more to an application than the UI alone, and there are more functional ways to apply state and eventing to a UI.

    uicontrol.on('eventName', handleSomeEvent.bind(null, state, uicontrol));

In this case, you still have a uicontrol, that raises events, and can use that to trigger a generic handler pre-bound against a given state. You can remove this farther by having the handleSomeEvent being a method that is already part of a state machine that is bound against an instance of said state.

If you follow 1-way dataflows (like flux) you can break some of the other constructs down... just the same, the above example is not OOP, but can still use UI events, and be composable.

Google SoundScript: faster OOP for JavaScript

Related Stories