danielearwicker

Java approach: create the JVM to support one language, so it has rich high-level concepts that are unfortunately skewed toward certain assumptions about language design, and it can be reused only for other languages that are similar enough.

WASM approach: start very low-level so C is definitely supported. Thus everything is supported, although every language has to roll its own high-level constructs. But over time more patterns can be standardised so languages can be interoperable within a polyglot WASM app.

In TS this is controllable. If noEmitOnError is true, then any error (including type errors) will stop it emitting JS output.

I think of probability as a summary of the structure/symmetries in a model. A model of a jar of red and blue beads is characterised by the ratio of red to blue, and that beads are only distinguished by colour.

It ought to be possible for the page to disable JavaScript with a meta tag:

  <meta name="noscript">

This must be the most unnecessarily awkward way of doing it (have to do it from the console after navigating to the site, so the request is allowed).

    fetch("https://heydonworks.com").then(x => x.text()).then(x => { 
      var f = document.createElement("iframe"); 
      document.body.append(f); 
      f.style.left = "0px";
      f.style.top = "0px";
      f.style.width = "100%";
      f.style.height = "100%";
      f.style.position = "absolute"; 
      f.style.border = 0;
      x = x.replace(/\<\/?noscript\>/gi, ""); 
      x = x.replace(/\<script\>.*\<\/script\>/gi, ""); 
      f.contentDocument.write(x); 
    });

That future possibiilty reminds me of https://en.wikipedia.org/wiki/Singularity_(operating_system) - where process/address-space isolation was replaced with fine-grained static verification of high-level code (presumably not the first experiment in this area).

I developed a kind of meta programming pattern and supporting library, based on Redux, called Immuto, to get absolute and complete static typing (via TypeScript) and minimal boilerplate, also referentiality and modularity (cursors that accepted actions). It was fun, but ultimately pointless, as it was never as straightforward as using the automatic observable approach that I'd learned from Knockout.js. Then I heard about MobX (which is the same ideas from KO but better implemented and without any quirky UI templating thrown in) and so now I used that.

Also I use my json-mobx library to get serialisation and undo/redo. Example: https://github.com/danielearwicker/baltar

Odd. Erlang uses GC.

It's very likely that JS will adopt some things tried initially in TS. Both TS and Babel have implemented extensions to the class syntax, for example, which are being considered for JS-future.

Interesting last line in that presentation:

"Flow written in OCaml, Typescript in Typescript"

You may be traumatised if you ever hear Crockford talk about JavaScript!

Not sure how well this analysis explains Facebook's widespread use of React.

Definitely an aim of TS to make it easier to continue using JS for those who prefer a half-way house, see: https://github.com/Microsoft/TypeScript/issues/4789

The example you give has been supported since day 1. Example: document.createElement("canvas") returns HTMLCanvasElement. A limited form of string literal types has always been supported specifically for overloading return types. The newer support added in 1.8 is a way more powerful generalisation.

I've been playing with https://github.com/danielearwicker/doop

+1 Knockout is a treasure chest of powerful patterns from remarkably few core concepts.

Thanks for the plug!

Caveat: Carota does not solve Right-To-Left text or complex scripts, and I'd really appreciate help with that. It's the only blocking issue against me using it in my main work project.

(By a strange coincidence I use the codename Primrose in an unrelated project...)