Max Heiber mheiber
Summary: I describe why and how we built "Autobang", a tool that automatically converts JS projects to strict TypeScript. This is an unusual solution to a problem that previously seemed intractable for large projects.
We built a tool to automatically convert a JS codebase to strict TypeScript with some interesting trade-offs. This is a hard and interesting problem I've never heard discussed
Entity Component Systems notes from someone who doesn't write games and didn't know what ECS was.
- State shape is more explicit, so much more likely to make good sense as an app grows
- ECS encourages much less plumbing for data flow between parts of an app, since systems can just read whatever they want.
- For big stateful apps, OO seems to encourage an 8-to-1 ratio of data plumbing compared to biz logic
- easier to safely share behavior
- Supports state serialization for record/replay debugging
| const main = () => { | |
| const x = 2 | |
| const y = 3 | |
| ;[1, 2, 3].forEach(v => { | |
| console.log(v, y) | |
| }) | |
| console.log(x, y) | |
| } |
Three error cases for private name semantic errors:
- shadowing (the nested classes case). See also suggested error message.
- accessibility violation
- name not found
(1) and (2) are special cases of (3)
Confusing note on terminology: in the semantics, '#foo' is the description for a private name, what a Muggle would call a "spelling" and a philosophyer would call an "orthography." From a semantic point of view, the private name itself (
#foo) is unforgeable and cannot be written down, even thought it's clear exactly where the private name node in the syntax is.
Rough algorithm for generating the most accurate error message for leftHandSide.#foo:
| class A { | |
| #foo; | |
| #bar; | |
| method() { | |
| class B { | |
| #foo; | |
| methodNested(a) { | |
| a.#foo; // error: shadowed | |
| a.#bar; // OK | |
| } |
| :tnoremap <Esc> <C-\><C-n> | |
| :tnoremap jj <C-\><C-n> | |
| :tnoremap <C-w><C-w> <C-\><C-n><C-w><C-w> | |
| :source ~/.vimrc | |
| au TermOpen * setlocal nonumber norelativenumber | |
| :nnoremap <leader>e <C-w><C-w>pa | |
| Plugin 'tpope/vim-surround' | |
| Plugin 'tpope/vim-commentary' |
| nnoremap <leader><space> :noh<return> | |
| nnoremap <leader><leader> :b#<CR> | |
| nnoremap <leader>S :source ~/.vimrc<CR> | |
| nnoremap <leader>g :e ~/.vimrc<CR> | |
| nnoremap <right> <C-w>10> | |
| nnoremap <left> <C-w>10< | |
| nnoremap <leader>1 :bp<Cr> | |
| nnoremap <leader>2 :bp<Cr> | |
| nnoremap <leader>] @: |
| MobX observable | Rx Observable | |
|---|---|---|
| common use case | facilitating updating a UI when data changes | composing frequently-updated data from multiple sources and/or implementing a lot of timing logic |
| better name is | "sneaky KVO" | "composable streams" |
| very similar to | reactive data in Meteor and Vue | Node streams if Node streams were always in object mode and had things like through2 and multipipe built in |
| implementation in JS requires |
| MobX observable | Rx Observable | |
|---|---|---|
| has to do with things changing | yes | yes |
| "reactive" | yes | yes |