
Anders Hejlsberg on Modern Compiler Construction (2016) [video] - ehaskins
https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction
======
octref
One take away for me was: Language designers & compiler writers today need to
consider editor support as one of their goals.

On the top page there's another thread about rust-analyzer vs RLS. What
Aleksey said[0] about RLS that "[RLS's] current architecture is not a good
foundation for a perfect IDE long-term," feels similar to my coworker's
conclusion in her effort to provide better editor support for PHP[1].

Parsers for compiling code into machine-executables vs parsers to serve LSP
responses have different tradeoffs. For example, Anders mentioned TS parser
need to have good error-recovery, can respond with completions/errors when one
file changes inside a thousand-files-project. I vaguely remember TS had a goal
to provide completions in < 50ms and errors in <150ms. Such goals are hard to
achieve as after-thought. If your core compiler doesn't do error recovery,
such as PHP, you need someone to write a new compiler from scratch for a
language server implementation. If tools such as RLS rely on compiler to dump
all JSON metadata and figure out LSP responses[0], it's too slow for editors.

TS's good editor support doesn't come free. I think one of the most under-
appreciated achievement of TS is how it took editor support seriously and
designed its compiler infrastructure to do it well. That's why I don't believe
in those hot-new-web-languages that try to take over TS by designing a better
type system. TS brought the average developer's expectation of a language to
having fast completion, fast error reporting, editor autofix, F2 to rename and
renaming-a-file-in-editor-to-update-all-references. It's 2020 and people
aren't going back to write code like in Notepad.

[0]: [https://ferrous-systems.com/blog/rust-analyzer-2019/](https://ferrous-
systems.com/blog/rust-analyzer-2019/)

[1]: [https://github.com/microsoft/tolerant-php-
parser](https://github.com/microsoft/tolerant-php-parser)

\---

EDIT: grammar.

~~~
Kinrany
> One take away for me was: Language designers & compiler writers today need
> to consider editor support as one of their goals.

In a way this is very intuitive: a programming language is a kind of a UI for
the language's runtime. The IDE is just another UI layer on top of that.

------
W-Stool
Turbo Pascal (which he authored) was quite the accomplishment back in the day
- editor and compiler in 64K. Think about that for a minute.

~~~
yesenadam
That was my first language after BASIC - I loved it!

I may be remembering this wrong, but it seemed virtually free - it was about
$100 when its competitors and most software was $500+. That was in about 1986.
The only way to get a manual was to buy the software. Another world..

~~~
tomcam
You do remember wrong. It was $49.95. It changed my life.

~~~
noir_lord
Mine too.

Started with ZX BASIC then when we got a second hand PC I switched to TP -
Pascal was and is an excellent first language, in that sense it met it's
design goals well.

------
tybit
This is a great talk, I was struck by how similar some of the high level
design goals are to LLVM
[https://www.aosabook.org/en/llvm.html](https://www.aosabook.org/en/llvm.html)

I kind of hope Anders moves on from TypeScript soon, he’s done a fantastic job
there considering the constraints of JavaScript, but I’d love to see him
tackle something new.

~~~
zackbrown
Between Delphi, C#, and TypeScript the man has already had a storied and
impactful career.

~~~
tybit
Yes, he’s fantastically accomplished and capable, and I think he could do
amazing things in a new area.

I’d love to see him take lessons learned from C# for a language designed for
WASM from the get go.

~~~
AshleyGrant
Unfortunately, he is quite adamantly not a fan of WASM.

~~~
cm2187
Why is he not?

~~~
symlinkk
Only thing I could find of him mentioning WebAssembly was here at 19:45:
[https://youtu.be/MxB0ldQfvT4?t=1185](https://youtu.be/MxB0ldQfvT4?t=1185)

In that video he says that it’s not a suitable target for TypeScript to
compile to because WebAssembly doesn’t have a garbage collector. They’d have
to basically implement an entire JavaScript engine in WebAssembly which would
be pointless.

He gives some examples of things it could be good for, which are all CPU
intensive things like image processing and video games, but he doesn’t seem to
think it’s really suitable for making normal web apps.

------
dang
A thread from 2018:
[https://news.ycombinator.com/item?id=17280589](https://news.ycombinator.com/item?id=17280589)

Discussed at the time:
[https://news.ycombinator.com/item?id=11685317](https://news.ycombinator.com/item?id=11685317)

------
bordercases
It sounds like that content-addressed code as in the Unison language
[https://www.unisonweb.org/](https://www.unisonweb.org/) could end up
facilitating the design of a _very_ effective IDE since the language can
naturally generate an immutable structure by default.

I don't know enough to know if this hunch is correct, I'm wondering if anyone
better informed can chime in.

~~~
zubairq
Yes this is correct. We use content addressable code, inspired by Unison for
yazz Pilot, and it makes so many things in the ide really simple, including
dependency management and stuff like that

------
zubairq
Very interesting, even though we don’t have a compiler in the traditional
sense for yazz Pilot as a container image is our output format, many of the
points are still valid.

Also very interesting how rosalyn had the idea of compiler as an API, we went
in the opposite direction and did not have any extensibility, instead we made
the Code editor an API

------
davidjnelson
Something I’ve observed with languages he designs are that they end up with a
ui form builder. I wonder if that will happen with typescript. It’s harder,
because they’d either need to pick a framework, or design it for at least
react, vue, angular.

------
oaiey
At that time I wanted to read about compiler building. Missed that I'm
University. That video made me skipping that. The standard books do not exist
for this level of evolvement.

------
pbiggar
This is kinda how the compiler-stuff in Dark is written.

Everything - the editor, semantic analysis, version control, execution engine,
everything - all use the same data structures (the same abstract syntax tree).

We use functional data structure everywhere and we do functional updates
within the AST all the time; that's even how text entry in the editor updates
the program.

~~~
chrisseaton
> Everything - the editor, semantic analysis, version control, execution
> engine, everything - all use the same data structures (the same abstract
> syntax tree).

Is that data structure suitable for all those purposes though?

How do you do optimisations like GVN on an AS->T<-?

~~~
pbiggar
It's not suitable for all purposes, but it's suitable for all editor purposes
(including an in-editor execution engine). We don't do GVN, or any
optimizations really, right now - I'm sure when we have a compiler of sorts
we'll have other structures, SSA, etc.

