Hacker News Reader

Hacker News

Comment by int_19h | Hacker News Reader

Full thread

int_19h

Algol 60 is also ... not exactly the easiest language to compile, even today. Here's the spec:

https://www.masswerk.at/algol60/report.htm

Call by name in particular can be very tricky, especially where it intersects with higher-order functions.

It can also be interesting to read contemporary discussions of problematic spots in the language, e.g.:

https://dl.acm.org/doi/10.1145/366193.366209

https://dl.acm.org/doi/10.1145/363717.363743

And the original ALGOL bulletin which has committee reports and mailing lists for the design process:

https://archive.computerhistory.org/resources/text/algol/alg...

View on HN

Yet it has relatively fast compilers, than a couple of modern languages, even on aging hardware versus the gaming rigs required for those modern languages.

I wonder if there's some type of generational amnesia where the subjective definition of what constitutes fast gets slower and slower with time, where communicating ones frustration with slow software is met with comments about how software is not actually slow.

There is definitely one, see the amazement of Go compile times, versus what Turbo Pascal was doing on MS-DOS computers running at 20 MHz.

Turbo Pascal is just an example from the days when C and C++ were yet to rule the Zeitgeist, and we had scripting all over the place.

Free Pascal is not a powerhouse building large FP+SDL projects such as GearHead 1 and 2. A comparable 486 program for DOS would be almost as slow if it was backported to DOS+FPC.

Maybe, but that isn't Borland's Turbo Pascal compiler, nor Borland/Inprise/Embarcadero's Delphi.

Most likely a consequence of how many compiler writers care about optimizations in FPC codebase.

Turbo Pascal back in the day was super fast. One of the fastest compiled languages I had used before we had incremental compilers and background incremental compilation. C/C++ compilers have mostly been a lot slower than those old Turbo Pascal implementations. MS Quick C 1.1 was a notable exception in the C compiler space. It could do 1 pass in memory compilation of most c code. Modern frameworks feel way slower even with scripting languages that require no compiles.

Coming to think of it, my 486 from early 90s when running DOS was one of the fastest computers I have used when it comes to bootup and applicaion load times. I was like type name of program, press enter and the program is up and ready to use. The systems that I had before that did take a lot longer to launch programs and anything with Windows has always felt an order of a magnitude slower. Modern tiny linux disros can match that speed, but then that is only with a very slimmed down system minus any gui. The MacBook Pro with M1 Pro did feel a lot faster than previous macs or windows machines when it came to application launch times and general gui responsiveness, but still no match to those DOS systems.

My experience as well. Apparently the Turbo Pascal developer implemented the compiler as a one pass compiler generating machine code while parsing. It dramatically reduces memory usage and increase speed, while reducing the opportunity to optimize the machine code at a higher level.

Even the original Turbo Pascal for CP/M was fast (e.g. running on the 2MHz Z80 SoftCard for the Apple II).

This is accompanied by surprised reactions when maintained and polished old implementations come across as fast. I'm thinking of you, Common Lisp.

I think there's also the effect that old, polished software can tend to become increasingly optimized.

Modern languages generally have much fancier type systems (Algol 60 didn't even have records!). Perhaps more importantly, modern compilers do optimizations that I doubt anyone back in 1960s even dreamed of.

Yet the specific problem of compilation times only affect a subset of modern languages, e.g. it takes a fraction of time to compile an Ada/SPARK application versus C++, or Rust, although the type system is equally rather complex.

Or the development workflow in Haskell and OCaml is much better than Rust, despite having a rather complex type system, because those ecosystems have invested into having interpreted toolchains, also able to load compiled code.

The way Ada handles generics removes a lot of complexity wrt things like inference and overload resolution, but at the expense of making things less convenient for the programmer because of the need to explicitly instantiate.

Rust and C++ are at this weird intersection of features where, on one hand, they need to have very fancy optimizers to remove all the overhead that idiomatic high-level library code (including stdlib) has, and on the other, they have generics and some degree of type inference that results in lots of generated code that consequently needs to go through the optimizer.

You can argue that it is that intersection that it itself problematic. But then again, C++ is arguably so popular precisely because it offers it, and Rust became popular because it was the first thing other than C++ that targeted the same broad niche.

Ada 2022/SPARK has plenty of complex language features, not sure why callout to generics in particular.

Using C++23 modules (import std) is quite fast, even more so with binary libraries, or the proprietary C++ Builder packages, and has been proven that the reason Rust is slow is the amount of unoptimized IR code the frontend shoves down into LLVM backend, and not the type system.

What I argue is the lack of investment in compiler tooling, once upon a time IBM and Lucid, showed the world how to have a Smalltalk/Lisp Machine like experience with C++ for example.

> not exactly the easiest language to compile

Besides "call by name", also using gotos for dynamic non-local exits, even by passing labels as an argument to a procedure, is pretty tricky.

Reply on news.ycombinator.com