3 ms·

So it's not that the classic compiler architecture that had to change -- it's the addition of languages services that broke the existing model.

by amasad 10y ago

chubot 10y ago
The classic compiler architecture did change, unless you want to maintain two compilers. That's the main point of the talk.
- amasad 10y ago
  Yes, I'm just saying that the requirement was external to the original function of compilers.
  - chubot 10y ago
    Sure... they mentioned the fact that the TypeScript compiler barely generates code, if that's what you mean by the original function of compilers. The architecture is completely dominated by the front end for usability and incrementality now. Generating JavaScript after all that is trivial. You can imagine that during a typical program's development lifetime, 99% of the time is spent with the program in a non-working state, and 1% is when it's working. The compiler has to help with the 99% case now, not just the 1% case.
    - amasad 10y ago
      Typically langauge services are decoupled from compilers. The 1% case still dominates how compilers functions. Furthermore, typically compilers are not deamons and build systems would take care of caching etc. Do you have other examples of consolidated tooling like that? It seems like a good idea but I don't think it's the standard thing yet or that everyone thinks it's a good idea.
      - pjmlp 10y ago
        Yes the model of programmer workstation as envisioned by Xerox PARC and followed up by ETHZ. Smalltalk, Interlisp-D, Mesa/Cedar at Xerox PARC, followed by Niklaus Wirth work at ETHZ with Oberon, Oberon-2, Active Oberon and Component Pascal environments. Also the initial Ada Workstation developed as the first product from Rational Software and Eiffel development environments. The Energize C++ environment created by Lucid after pivoting from Lisp Machines.
    - deleted 10y ago
      [deleted]
atombender 10y ago
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.

So it's not that the classic compiler architecture that had to change -- it's the addition of languages services that broke the existing model.

by amasad 10y ago

So it's not that the classic compiler architecture that had to change -- it's the addition of languages services that broke the existing model.

chubot 10y ago

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

amasad 10y ago
Yes, I'm just saying that the requirement was external to the original function of compilers.
- chubot 10y ago
  Sure... they mentioned the fact that the TypeScript compiler barely generates code, if that's what you mean by the original function of compilers. The architecture is completely dominated by the front end for usability and incrementality now. Generating JavaScript after all that is trivial. You can imagine that during a typical program's development lifetime, 99% of the time is spent with the program in a non-working state, and 1% is when it's working. The compiler has to help with the 99% case now, not just the 1% case.
  - amasad 10y ago
    Typically langauge services are decoupled from compilers. The 1% case still dominates how compilers functions. Furthermore, typically compilers are not deamons and build systems would take care of caching etc. Do you have other examples of consolidated tooling like that? It seems like a good idea but I don't think it's the standard thing yet or that everyone thinks it's a good idea.
    - pjmlp 10y ago
      Yes the model of programmer workstation as envisioned by Xerox PARC and followed up by ETHZ. Smalltalk, Interlisp-D, Mesa/Cedar at Xerox PARC, followed by Niklaus Wirth work at ETHZ with Oberon, Oberon-2, Active Oberon and Component Pascal environments. Also the initial Ada Workstation developed as the first product from Rational Software and Eiffel development environments. The Energize C++ environment created by Lucid after pivoting from Lisp Machines.
  - deleted 10y ago
    [deleted]

atombender 10y ago

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.