Bruno Jouhier (2018-01-14T11:34:47.000Z)
I'm coming from a long journey through dynamically typed (mostly LISP and
JavaScript) and statically typed (mostly C, C++, Java and C#) languages,
I'm now using TypeScript and I really like the mix of power and
flexilbility that OST provides.

>From my experience, the main benefits of OST are the following:

* self-documentation: I work with a large team and developers often need to
explore code or use APIs written by others. Types are very helpful and save
a lot of time. Even more with modern code editors thanks to intellisense,
jump to definitions, ...
* code refactoring: I work on prototypes and I do a lot of code refactoring
in the early stages of a project. Refactoring is painful without types: you
either have to tediously check that you have put all the pieces back
together, or accept to run several debugging passes to eliminate all the
silly refactoring errors. OST reduces the cognitive load (you don't have to
remember all the loose ends) and it saves a lot of time overall.

The pain point is that code needs to be transpiled. There are tools to help
(and the TypeScript compiler has a file watch option) but for simple
scripts/projects it would be nice to be able to run directly without
preprocessing.

I don't mind if type systems remain outside of the ES spec but a nice
improvement would be to have a provision for OST syntaxes in ES so that ES
engines could load and execute code that contains type annotations, by just
treating them as comments. Then, we would not need to transpile during
development.

I don't know if there are enough syntax markers to allow this without
adding complete type grammars to the language. I imagine that a lookahead
that kicks off after certain markers (colon, as/type/interface/declare
keywords) and that skips certain token types (identifiers, literals, |, &)
and balanced parentheses/curly braces/brackets may be able to do the job.
But this might be easier said than done (and ASI might get in the way).

Could this be a viable compromise?

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180114/6375c56a/attachment.html>
bjouhier at gmail.com (2018-01-14T13:03:47.833Z)
I'm coming from a long journey through dynamically typed (mostly LISP and
JavaScript) and statically typed (mostly C, C++, Java and C#) languages,
I'm now using TypeScript and I really like the mix of power and
flexilbility that OST provides.

From my experience, the main benefits of OST are the following:

* self-documentation: I work with a large team and developers often need to
explore code or use APIs written by others. Types are very helpful and save
a lot of time. Even more with modern code editors thanks to intellisense,
jump to definitions, ...
* code refactoring: I work on prototypes and I do a lot of code refactoring
in the early stages of a project. Refactoring is painful without types: you
either have to tediously check that you have put all the pieces back
together, or accept to run several debugging passes to eliminate all the
silly refactoring errors. OST reduces the cognitive load (you don't have to
remember all the loose ends) and it saves a lot of time overall.

The pain point is that code needs to be transpiled. There are tools to help
(and the TypeScript compiler has a file watch option) but for simple
scripts/projects it would be nice to be able to run directly without
preprocessing.

I don't mind if type systems remain outside of the ES spec but a nice
improvement would be to have a provision for OST syntaxes in ES so that ES
engines could load and execute code that contains type annotations, by just
treating them as comments. Then, we would not need to transpile during
development.

I don't know if there are enough syntax markers to allow this without
adding complete type grammars to the language. I imagine that a lookahead
that kicks off after certain markers (colon, as/type/interface/declare
keywords) and that skips certain token types (identifiers, literals, |, &)
and balanced parentheses/curly braces/brackets may be able to do the job.
But this might be easier said than done (and ASI might get in the way).

Could this be a viable compromise?

Bruno