3 ms·

This author either doesn’t know about Niklaus Wirth or forgot to mention him. Wirth’s main metric for assessing language complexity was how fast the compiler co

This author either doesn’t know about Niklaus Wirth or forgot to mention him. Wirth’s main metric for assessing language complexity was how fast the compiler compiles in general and compiles itself. He ditched anything that slowed that down. The resulting compilers could never be as fast as C/C++. However, Oberon-2’s fast development pace with safe code was a major inspiration for Go. If anything, Wirth’s legacy went mainstream when someone finally did something non-academic with it. Author makes another mistake which is widespread: that fast-moving teams need languages with fast compilers. Sort of a half-truth. The alternative I push is a combo of REPL or fast compiler with ultra-optimizing compiler. Most of the iteration happens with the fast one. Everything that seems kind of finished gets compiled in background or on build server with more optimization, followed by lots of testing. It gets integrated into the new, compile-quick builds. Plenty of caching and parallelization in build system, too. See Section 2 in the pdf: https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806

vidarh 7y ago
> Wirth’s main metric for assessing language complexity was how fast the compiler compiles in general and compiles itself. He ditched anything that slowed that down. Indeed, one of the old stories about the Oberon compiler (I can't vouch for how strictly he stuck to it) is that optimizations had to "pay for themselves": Once recompiled with the optimization, the compiler needed to compile itself as fast as before the optimization was added. At least one of his thesis students did write papers on applying other optimizations that had no hope of making it into the standard Oberon compiler for that reason. I believe it was either Michael Brandeis PhD thesis or one of his other papers. But even though his optimization pass was "too costly" it was impressive how small it was given it also beat contemporary versions of gcc in terms of resulting performance. > https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 I love diving into old HN threads... Especially seeing my own comments on the top of the page. Less so to have my slow pace on my personal compiler project highlighted on them (apparently a GC was the next step for my Ruby compiler back in 2017 - it's just now sitting in a working state in my home directory; not yet committed). It's definitively not as fast as a Wirth compiler - in large part due to the sheer volume of small objects created. As much as I love to work with Ruby, as a fan of Wirth's work it also makes me want to bang my head through a wall...
- cpeterso 7y ago
  Niklaus Wirth fans will appreciate the (apparently out of print) book "The School of Niklaus Wirth: The Art of Simplicity", written by some of Wirth's students about his and their research work with languages, operating systems, and the Lilith computer. https://amzn.com/1558607234 https://amzn.com/1558607234
  - sitkack 7y ago
    I own this wonderful book, some of the chapters are available as publicly available papers. Like Compiler Construction - The Art of Niklaus Wirth [1] FFF97 - Oberon in the Real World. [2] [1] https://pdfs.semanticscholar.org/036f/c4effda4bbbe9f6a9ee762df717bd0af1324.pdf https://pdfs.semanticscholar.org/036f/c4effda4bbbe9f6a9ee762... [2] https://www.researchgate.net/publication/221349845_FFF97_-_Oberon_in_the_Real_World https://www.researchgate.net/publication/221349845_FFF97_-_O...
    - cpeterso 7y ago
      Thanks! I no longer own this book, so these papers online are a treat. :)
gnufx 7y ago
Of course, there's no good reason why compiling the compiler should be relevant to typical applications. I'm glad GCC doesn't drop optimizations for fast numerical Fortran that surely won't speed up the compiler.
- nickpsecurity 7y ago
  True. I didn't agree with his metric. Mine came from my experience with BASIC and Lisps. It was that the compile should happen in no more than a few seconds if iteration speed was the goal. My metric was about keeping the mind in a state of flow for maximum creative output. Otherwise, it could take all night if I wasn't staring at the screen waiting on it.
- vidarh 7y ago
  It's not so relevant for compiler suites that handle many languages, but for Wirth-style compiler the compiler is largely a bunch of branches and IO, so while it won't be representative for everything, it is quite representative. And of course it will mean the result is slower, but it represents a belief that the speed and simplicity of the compiler matters more for a whole lot of uses. Thankfully nothing prevents us from having multiple compilers, or settings, so we can get both very fast compiles and optimizations. Indeed, several of Wirth's thesis students did optimization work that plugged in optimizations in the Oberon compiler.
  - gnufx 7y ago
    I don't necessarily disagree, and I grew up with rather fast compilers on rather fast interactive systems; they may even have been Wirth-style, but I didn't study the source. It's just that it's not a useful metric for, say, numerical code that doesn't look like a compiler. Also I suspect the difference in hardware architecture in those days was relevant.

vidarh 7y ago

> Wirth’s main metric for assessing language complexity was how fast the compiler compiles in general and compiles itself. He ditched anything that slowed that down. Indeed, one of the old stories about the Oberon compiler (I can't vouch for how strictly he stuck to it) is that optimizations had to "pay for themselves": Once recompiled with the optimization, the compiler needed to compile itself as fast as before the optimization was added. At least one of his thesis students did write papers on applying other optimizations that had no hope of making it into the standard Oberon compiler for that reason. I believe it was either Michael Brandeis PhD thesis or one of his other papers. But even though his optimization pass was "too costly" it was impressive how small it was given it also beat contemporary versions of gcc in terms of resulting performance. > https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 I love diving into old HN threads... Especially seeing my own comments on the top of the page. Less so to have my slow pace on my personal compiler project highlighted on them (apparently a GC was the next step for my Ruby compiler back in 2017 - it's just now sitting in a working state in my home directory; not yet committed). It's definitively not as fast as a Wirth compiler - in large part due to the sheer volume of small objects created. As much as I love to work with Ruby, as a fan of Wirth's work it also makes me want to bang my head through a wall...

cpeterso 7y ago
Niklaus Wirth fans will appreciate the (apparently out of print) book "The School of Niklaus Wirth: The Art of Simplicity", written by some of Wirth's students about his and their research work with languages, operating systems, and the Lilith computer. https://amzn.com/1558607234 https://amzn.com/1558607234
- sitkack 7y ago
  I own this wonderful book, some of the chapters are available as publicly available papers. Like Compiler Construction - The Art of Niklaus Wirth [1] FFF97 - Oberon in the Real World. [2] [1] https://pdfs.semanticscholar.org/036f/c4effda4bbbe9f6a9ee762df717bd0af1324.pdf https://pdfs.semanticscholar.org/036f/c4effda4bbbe9f6a9ee762... [2] https://www.researchgate.net/publication/221349845_FFF97_-_Oberon_in_the_Real_World https://www.researchgate.net/publication/221349845_FFF97_-_O...
  - cpeterso 7y ago
    Thanks! I no longer own this book, so these papers online are a treat. :)

gnufx 7y ago

Of course, there's no good reason why compiling the compiler should be relevant to typical applications. I'm glad GCC doesn't drop optimizations for fast numerical Fortran that surely won't speed up the compiler.

nickpsecurity 7y ago
True. I didn't agree with his metric. Mine came from my experience with BASIC and Lisps. It was that the compile should happen in no more than a few seconds if iteration speed was the goal. My metric was about keeping the mind in a state of flow for maximum creative output. Otherwise, it could take all night if I wasn't staring at the screen waiting on it.
vidarh 7y ago
It's not so relevant for compiler suites that handle many languages, but for Wirth-style compiler the compiler is largely a bunch of branches and IO, so while it won't be representative for everything, it is quite representative. And of course it will mean the result is slower, but it represents a belief that the speed and simplicity of the compiler matters more for a whole lot of uses. Thankfully nothing prevents us from having multiple compilers, or settings, so we can get both very fast compiles and optimizations. Indeed, several of Wirth's thesis students did optimization work that plugged in optimizations in the Oberon compiler.
- gnufx 7y ago
  I don't necessarily disagree, and I grew up with rather fast compilers on rather fast interactive systems; they may even have been Wirth-style, but I didn't study the source. It's just that it's not a useful metric for, say, numerical code that doesn't look like a compiler. Also I suspect the difference in hardware architecture in those days was relevant.