HotSpot's sea of nodes IR is far beyond anything Turbo Pascal did in terms of balancing compile time and runtime. It's not even comparable.

Few people are as consistently right in their field as Cliff Click is with JITs and language runtimes.

Dude is brillaint and did great work. Yet, the Oberons and Pascals compiled so fast my finger was barely off the key when they were done. Even the C/C++ editors werent that fast for Java. Allowed rapid iteration while maintaining mental flow. When done, you turn all the options on with that or a slower compiler to get fastest, production version. This has been true going back to the old, Ceres workstations where commenters here that used them reported instant compiles on CPU's with tens of MHz.

Yes, and they didn't do any optimization. That's not particularly interesting; TCC is there if you want it.

Barely any. Which leads us to differentiate between iterative and release requirements. Language like Go will kill on the former with Wirth-style compilees. A LLVM extension might have been better for latter. That was my recommendation a while back. Even still, the language is simple enough it should compile faster. Should != will of course.

On a Pentium 3? Don't you think such a comparison might be out of date? Java has changed a lot since those days.

Yes, Pascal/Delphi also compiles very fast, it's true, but they also forbid circular dependencies and impose other restrictions that caused a lot of developer pain.

Let's say we port it from P3 to multi-core, 2GHz x86. We want to know if prior performance was relevant as a predictor. As in, will difference choices made on old platform apply to new? Here's a few examples to illustrate:

1. Interpreted vs compiled language.

2. Simple, Oberon-like type checks vs Rust or Ada.

3. Several pages of BNF in grammar vs 1 or 2.

4. Designed for abstract, heap machine or just above real, stack machine?

5. Number of steps needed between source and efficient exdcution.

6. Number of times you perform those steps (eg AOT vs JIT).

7. Cache-awareness of design.

These are a few key differences between Java and Wirth-style languages then. They made compiles rapid on P3. Updating to multicore or 64-bit would be trivial given each update at ETH was a few undergrads work for 6mo-2yr. So, do lessons learned that those attributes Wirth-style greatly aid performance of compilers and runtime still apply today?

I think so given what Go accomplished in its time and resources. Other languages too with design decisions that proved out over time. It took truly epic work and investment to get Java to its current situation.

I havent heard people say Pascal caused them lots of pain aside from functional crowd or some wanting a few C++ features. What specifics bothered you? And why did you need circular dependencies?