

AtScript Primer - skrebbel
https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/mobilebasic?pli=1&viewopt=127

======
malandrew
Why not use type annotations to accomplish this? Do we really need another
compile to JavaScript language for something that did not require changing the
language syntax?

There is no reason that a similar project could not have been made via smaller
modules using comment annotations.

This project really should be at least two projets: (1) one npm module for
parsing the type signatures with the line numbers of the functions it applies
to. (2) one module that takes in that intermediary representation and performs
the AST transform for wrapping the functions.

I don't see why this couldn't have been accomplished with:

    
    
      (1) the doctrine module [0] for parsing JSDoc comment blocks before functions 
          OR a custom module for recognizing a custom comment delimiter like //+ or 
          //! followed by the type annotation such as Haskell's type declaration 
          format.
    
      (2) a module for parsing closure compiler JSDoc type signatures
    
      (3) the racket-style higher order contracts module [1] for a way to do
          run-time checking
    
      (3) a module consisting of all the possible permutations of higher order 
          type checking functions based on rho-contracts
    
      (4) the node-falafel module [2] for performing the actual AST transform 
          that wraps those contract functions around the function described by 
          the JSdoc comment.
    

Furthermore, this approach of breaking this up in to modules allows multiple
people to propose alternative syntaxes for this for consideration in future
versions of ECMAScript. I wouldn't be surprised if sweet.js could also be used
for those syntax approaches that go beyond comment-based annotations and
involve modifying the syntax of the language itself.

For those that built this at Google, please please please consider breaking
this down into smaller composable modules. I'd love to be able to play with
the subcomponents of this myself without having to adopt yet another language
that doesn't parse with off the shelf tools [4].

[0]
[https://github.com/Constellation/doctrine](https://github.com/Constellation/doctrine)

[1] [https://github.com/sefaira/rho-
contracts.js](https://github.com/sefaira/rho-contracts.js)

[2] [https://github.com/substack/node-
falafel](https://github.com/substack/node-falafel)

[3] [http://sweetjs.org/](http://sweetjs.org/)

[4] See JSX for the clusterfuck[6] that results when you add yet another
format that needs to be parsed in a unique way with no real benefit that
couldn't be accomplished just as easily without fucking with the standard
language syntax. See Wadler's Law [5]

[5]
[http://www.haskell.org/haskellwiki/Wadler's_Law](http://www.haskell.org/haskellwiki/Wadler's_Law)

[6] [https://www.npmjs.org/package/esprima-
fb](https://www.npmjs.org/package/esprima-fb)

~~~
malandrew
Another options besides comment-based annotations is property based
annotations.

Basically provide a library that contains all the possible primitive types
that can be checked and functions for composing higher order types.

Then in the code do something like so:

    
    
        var types = require('types');
    
        function foo(bar, baz) {
          var qux = '';
          
          /* do something */
    
          return qux;
        }
    
        foo.types = {
          args: [types.Array, types.Object],
          return: [ types.String ] // array to support ES6 destructuring assignment
        }
    
    

This interface makes it trivially easy to define the types, parse the types,
strip the types out on minification, etc.

This approach also makes it trivially easy to compose higher order types in a
separate modules and require them.

my-geometry-types.js:

    
    
        var types = require('types');
        var point = [types.Float, types.Float];
        module.exports.point = point;
        module.exports.rectangle = [point, point];
    

Then in another file, you can require these type modules and use them to set
the type signature of a function;

Anyways, my point is that building a tool like this is awesome, but a _null_
contribution if it requires me to throw out all my existing tooling,
especially for something that could have been implemented in a way that is
composable. It may even be a _net negative_ contribution if it gets traction
and causes an unnecessary schism (e.g. JSX) in the community that reduces code
sharing, interop and the ability for developers to stand on each others
shoulders.

The beauty and strength of the NodeJS ecosystem is not the language it is
based on (JavaScript) or its runtime (v8/libuv), but that it nailed a lot of
details related to common conventions among developers and allowing modules to
remain small and composable.

The modules created by people like prominent module contributors like
Substack, Raynos, Izs and Dominic Tarr are usually stellar examples of
publishing small, reusable module components. All of these guys have hundreds
of small modules published that are very composable, easy test and easy/fast
to replace if they don't meet your needs.

The tooling behind AtScript would be a huge contribution if it were made in a
way where the components that make up the tooling could be mixed and matched
for use in novel ways.

~~~
dragonwriter
> Another options besides comment-based annotations is property based
> annotations.

You mean, exactly like what the generated JavaScript from AtScript has in the
samples shown in TFA?

> The tooling behind AtScript would be a huge contribution if it were made in
> a way where the components that make up the tooling could be mixed and
> matched for use in novel ways.

As detailed in TFA, there are two main components that exist right now -- the
Traceur transpiler and the RTTS (runtime type system) library, the latter of
which provides the kind of functionality you discuss in much of your post.
Clearly RTTS can be used independently of AtScript proper.

There are future plans (also detailed in TFA), which include at least one
other standalone tool. So the "components which can be mixed and matched in
novel ways" seems to be exactly the plan.

If you had spent as much time reading what they actually have done and are
doing as you spent writing about what they should and shouldn't do, you may
have realized that you were basically asking for exactly what they are doing.

------
ceronman
I really like the idea of static type checking, but I'm not convinced about
the usefulness of runtime checking. It will introduce a performance penalty
and it will go against duck typing, which is one of the coolest features of
languages like JS.

It seems that this project is trying to build something in between of
TypeScript and Dart: they want the optional runtime type checking of Dart vs
the good interoperability with JS of TypeScript.

In this interview [1] Anders Hejlsberg and Lars Bak (from TypeScript and Dart)
discuss the idea of runtime type checking. They don't seem very convinced of
the idea either.

[1]
[https://www.youtube.com/watch?v=5AqbCQuK0gM](https://www.youtube.com/watch?v=5AqbCQuK0gM)

~~~
zackbrown
As I understand it, there is a 'production mode' that disables the runtime
type checking. This way developers can gain the development-time benefits of
type safety without sacrificing performance where it counts.

As for the benefits of duck typing, also as I understand it, the key point of
_runtime_ vs _static_ checking is that it eases interoperation with non-
annotated and non-typed code. So duck-type if and when you want; reap the
benefits of types when you want.

For a much better explanation, watch Misko Hevery's keynote about Angular 2
and AtScript from NgEurope yesterday:
[http://youtu.be/S8fE-w2DL8U?t=21m5s](http://youtu.be/S8fE-w2DL8U?t=21m5s)

~~~
malandrew
Yup. Plus it should also be possible to only turn on type checking selectively
for some functions in production. This way to you can implement it on
functions that are executed infrequently and don't have a material impact on
performance, but leave it off for those code paths that are critical for
performance.

------
rikkus
"The goal of AtScript is to enhance the language with these missing features
without infringing upon its current capabilities."

Looks like they decided TypeScript was Not Invented Here?

~~~
jbergens
If you watch the keynote video about AtScript you'll see that they describe
AtScript as a superset of TypeScript 2. They add features they think are
missing but are trying to keep the syntax wherever possible (actually they
hope that much of TypeScript will be in a future EcmaScript standard and then
they will follow that syntax).

------
paperstreet7
It seems to me they're trying to use the popularity of Angular.js to bring
AtScript on the scene. Everyone who doesn't like JS tries to replace it with
his own language or at least fix it. There are tons of different compilers
that hide real JS from their eyes behind language x but when it comes to
realtime debugging they inevitably have to dig into some real JavaScript
generated by those tools. AtScript is not an exception here.

------
santialbo
I was very excited when Facebook showed flow at @scale but I haven't heard any
update on the project since. Does anyone know when they are planning on
releasing it?

------
davidgrenier
Personally glad to be free of all that goofiness, Angular, JS or what have
you.

[http://websharper.com/](http://websharper.com/)

Almost two years in production.

I even had the opportunity to try the F# Type Provider for Sencha Architect
and although I do not like tooling I came away shocked at how productive the
experience could be for back-end application development using that tool.

~~~
ep103
What's it do, just compiles to js for the front end?

~~~
davidgrenier
Compiles your client-side F# code to JS such that you write all your code in
the same programming language.

You get to leverage the sophisticated type system of F# for your client side
code and get transparent interop between front-end and back-end code. There's
no need for http/ajax requests to your back-end code because the WebSharper
compiler takes care of wiring function calls from the client side directly.

    
    
      [<RPC>]
      let getName() = "David"
    
      [<JavaScript>]
      module Client =
        let page() =
          Div [
            Span [Text (getName())]
          ]
    

Not only is all of this statically typed, WebSharper takes care of
transparently wiring the call for you and serializes any data structure that
you may want to pass from the server to the client and vice versa.

WebSharper has no problem generating both server-side markup through server-
side combinators but truly reigns as a SPA architecture as you can choose to
simply return data from your RPC calls and generate the markup on the client-
side. Another benefit here is that you generally avoid the need to rely on
libraries like JQuery to query your DOM and interact with the markup. Being
able to simply keep a reference to any DOM element you create as opposed to
having to query your DOM to get is just simpler.

But WebSharper also offer a host of well thought-out abstractions on top of
Web Development in the form of Sitelets/Formlets/Piglets and now UI.Next. The
real benefit of those is composability.

If you are are already familiar with an ML-like language you will be pleased
at the benefits you get. If you aren't, I strongly recommend you take a look
at the landscape of programming languages as three great families stand out...
you would do yourself a major favor as a developer to learn at least one ML.
Those that do never go back.

------
svckr
Thanks for the link.

At [ngeurope](ngeurope.org) Miško pointed out that they we're specifically
_not_ aiming to create yet-another-language. Instead they are evaluating ways
for JS to evolve beyond ES6 and are planning to propose AtScripts features for
ES7 (or whatever is next).

This falls in line with the recent trend that new features start out in
transpilers instead of browsers.

------
ep103
Is anyone else simply getting tired of the number of ways google is attempting
to (in their words) "replace JavaScript as the lingua franca of web
development on the open web platform"? Dart, Angular, and AtScript are just
the three most recent iterations of completely overhauling js for and by
Google.

~~~
georgemcbay
No, I'm getting tired of other parties (most notably Mozilla) doing whatever
they can to block such efforts on political rather than technical merits.

Do we really want to be stuck with a mostly stagnant JavaScript _forever_?
Ugh.

~~~
ganarajpr
+1.

I hate this part about Mozilla and Apple. I dont have qualms about javascript.
It has its good parts and as a full time javascript contractor I earn my
living with javascript. But... I dont really want the next generation of
developers to be stuck with whatever we have today. I am not in favor of "Here
is what you get - do all your innovations inside this box" mentality. Yes,
there is scope for improving javascript or ECMAscript but there are limits to
this. As Peter Thiel says in his book - this is incremental-ism. This will
never produce 0 to 1. In order to produce something like that people should be
allowed to innovate - even if initially they have to do stuff like this
AtScript or Dart or TypeScript! Criticizing those attempts as "breaking the
existing tool-chain" is as foolish as criticizing a spaceship because it does
not make use of roads.

------
striking
Unfortunately it seems to me that the Google Drive folder linked is
inaccessible.. the individual documents are easily found via Google Search but
seeing them all in one place would be kinda nice.

------
danabramov
I like the parts before DI. TypeScript-ish syntax, pluggable runtime checks—I
really like that. But DI and annotations speak more of Angular's complexity
than anything.

------
ep103
If google is going to attempt to use angular to get developers to use this (as
opposed to just letting it fail naturally, like Dart), then I'm done using
angular.

------
muyuu
Another TypeScript or another Dart?

[http://xkcd.com/927/](http://xkcd.com/927/)

------
skrebbel
I'm really interested in this. Does anyone know if this has a publicly
available compiler already?

~~~
ganarajpr
FWIW, I believe they are using traceur-compiler.
[https://github.com/google/traceur-
compiler](https://github.com/google/traceur-compiler)

If you look at this page here [https://github.com/google/traceur-
compiler/wiki/LanguageFeat...](https://github.com/google/traceur-
compiler/wiki/LanguageFeatures)

You can see annotations in the "experimental" features list.

~~~
temperbens
[https://github.com/support11/discussions/wiki/Watch-QPR-
vs-A...](https://github.com/support11/discussions/wiki/Watch-QPR-vs-Aston-
Villa-live-stream-free)

------
timeu
This is used for the new AngularJS 2.0

