Anders Hejlsberg on Modern Compiler Construction [video]

TP was indeed amazing, though I think you're misremembering — TP 5.5 was the first version to add OO extensions.

It came with a separate little manual just for the object-oriented stuff (beautifully typeset with the same type of syntax flow diagrams that Apple did [1]; Borland's OO extensions came from Apple Pascal, after all), and I remember reading it from cover while on vacation when I was in my mid-teens, and having my mind blown by the ideas of object-orientation, which seemed like complete science fiction at the time.

Anything from your recollections you can add to this? Was there any collaboration with Apple at all?

[1] http://pascal-central.com/images/pascalposter.jpg

There were many wonderful things about TP, but it started much earlier than that. BLS Pascal on Nascom 2, COMPAS Pascal on CP/M, Turbo Pascal on CP/M, and finally TP on DOS. I met Anders at Herning Messen where he demoed COMPAS Pascal (running a Maze generator). From my recollection he was a few years older than me which suggests he wrote BLS Pascal as a young teenager o_O!

This thread has a big of this history: https://news.ycombinator.com/item?id=10202299

Last month I recovered an old backup tape with TP.EXE. Couldn't resist but to play with it in dosbox.

http://imgur.com/oT3u4fR

It really was a brilliant piece of software. 600KB.

ps: the text GUI shadows.

To assist you all in reminiscing? A lot of TP manuals are at bitsavers:

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/bor...

I've developed a couple of cool tricks to get very error tolerant parsers (I design/build live programming languages). We can go pure shunting yard (precedence parser), which will basically parse anything since it doesn't rely on grammar rules. Even if going with grammar based parsing (they are convenient), braces can be matched on tokens in a pre-pass before parsing occurs, eliminating an entire class of difficult to deal with errors, and allowing for brace stickiness in an incremental edit context; no need to rebalance because someone typed an opening paren without brace completion!

Though I can't help but think that someone will eventually develop an NN-based PL parser that will be much more error tolerant than straight grammar-based implementations could ever be.

If you run tsc with benchmarking on, you'll find that almost all the time is taken up by the typechecker. Increasingly, TypeScript is adding control-flow-analysis-based[1] and contextual type system features... Saying that it just 'removes' type annotations as a bit disingenuous, as processing the type constraints those annotations apply is one of the most time consuming tasks TS can perform! TypeScript is structural, too, so for every comparison it can need to get down to the nitty-gritty of comparing individual object members... Recursively. TS does heavy cacheing of not just types, but the relationships between types - just to avoid redoing any work, where possible.

FYI, the 'helicoptering in' doesn't affect full-program compilation time because of the mentioned cacheing. Since the state of the world is unchanged during a build, the parsetree and type hierarchy are only built once. Additionally, you'd find that incremental builds (tsc --watch) are relatively snappy because of the heavy cacheing done and the tree reuse, and so has benefitted from the architecture improvements for service work.

[1]https://github.com/Microsoft/TypeScript/pull/8010

The compiler doesn't just remove the type annotation, it has to go through and check that the annotations are valid and that the type safety is kept throughout the program. Type checking is often not a quick process, since it requires every single value in the program to have its type verified. If I declare that a variable is an integer and set it to the result of the function, the compiler has to make sure that that function returns an integer and not some other type, or that the type that function returns can be implicitly converted to an integer. And for that to be safe, it has to first prove that the function being called can be given that type, etc.

The C# compiler he is taking about is open source, so you could have a play around with it to see how they implemented it. https://github.com/dotnet/roslyn

Well he clearly has a curious mind... I think you only get burnt out once you can't keep up, or once nobody is interested in the things you spent your career on.

But he happened to spend his career on something that is still profoundly interesting to people. The open source world is very much in the old architecture he was talking about, so it appears that Microsoft compilers are simply more advanced. (And Borland and Jetbrains did this too, just not open source compilers)

There are several programmers at my company who are in their 60's, and I think even 70's, past retirement age. All of them are super sharp; they are not "code monkeys". I think those types tend to leave the industry sooner.

He's 56. What's your point? Do you imagine that people who devote themselves to a field have some kind of expiry date built in?

CS is like mathematics or chess - if you find it interesting or beautiful there should be no expiry date as such.

What burns people out, IMO, is lack of autonomy or broken work places, not the subject matter.

Certainly common in my experience. A coworker of mine just celebrated his 57th birthday. He's definitely better at this stuff than I am; experience counts. The youth bias in this industry has always been largely based on illusion.

I think this applies to many people in our domain, provided they're careful not to burn out: https://popperfont.files.wordpress.com/2014/04/lifesatisfact...

It's very common for professors and researchers, which I guess he kind of is.

He clearly is not JavaScript fatigued.

If you look at how compilers are written these days, one other thing has changed. Almost every book on compiler design, including the classics, will direct you towards separating the lexer, scanner and compiler stages using parser generators like Lex/Yacc or Flex/Bison. In practice, this isn't done anymore. If you look at modern compilers like Clang, Go or Rust, they all have hand-coded parsers that build syntax trees right out of tokens. It turns out that parser generators don't really give you that much, and only get in the way once you need to go beyond the basics.

The classic compiler architecture did change, unless you want to maintain two compilers. That's the main point of the talk.