[HN Gopher] 21 Algol 60 Compilers in 1962
___________________________________________________________________
21 Algol 60 Compilers in 1962
Author : elvis70
Score : 43 points
Date : 2024-12-03 18:47 UTC (4 days ago)
(HTM) web link (shape-of-code.com)
(TXT) w3m dump (shape-of-code.com)
| int_19h wrote:
| 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...
| pjmlp wrote:
| 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.
| fredrikholm wrote:
| 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.
| pjmlp wrote:
| 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.
| anthk wrote:
| 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.
| pjmlp wrote:
| 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.
| no1lives4ever wrote:
| 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.
| pfdietz wrote:
| 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.
| int_19h wrote:
| 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.
| pjmlp wrote:
| 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.
| int_19h wrote:
| 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.
| pjmlp wrote:
| 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.
| Rochus wrote:
| > _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.
| usr1106 wrote:
| How many C or C++ compilers are in wider use today?
|
| Not really working in the area and did not research now, but I
| can come up with:
|
| * gcc
|
| * clang
|
| * Microsoft probably has their own implementation
|
| * Intel probably still has their own implementation
|
| * ?
|
| Edit: OpenVMS maybe, but not sure whether that qualifies for in
| wider use
|
| Edit2: ARM of course
| shiomiru wrote:
| tcc is popular too, as a fast non-optimizing compiler.
| cenamus wrote:
| Similarly, cproc with the QBE backend. Focused on simplicity
| an getting to 80% of gcc/clang with 20% of the
| complexity/size.
| asplake wrote:
| Per [1], Zig seems to have its own C compiler (AFAICT it's not
| just a frontend to an existing one)
|
| [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-
| replace...
| flohofwoe wrote:
| Currently, zig cc _is_ the Clang frontend which is linked
| into the Zig compiler (most things in that blog post are
| about differences between the Zig toolchain and a typical
| Clang toolchain for cross-compilation, and how Zig invokes
| the Clang frontend).
|
| I'm not sure what the current plan is for C compilation after
| the LLVM divorce and after Clang will be moved into a Zig
| package (e.g. I remember talk that arocc [1] is going to be
| integrated into the Zig compiler, but not sure if that's
| still planned, or if C compilation will also be delegated to
| the new Clang package along with C++ and ObjC compilation).
|
| [1] https://github.com/Vexu/arocc
| senkora wrote:
| For C++, there are exactly four independent frontends in wide
| use (gcc, clang, msvc, edg) and three independent stdlibs
| (libstdc++, libc++, STL).
|
| I'm not sure how many independent compiler backends are widely
| used with those frontends and stdlibs.
| flohofwoe wrote:
| Clang, GCC and MSVC are the big ones, the rest are more or less
| niche compilers - with Clang and GCC only differing in small
| details.
|
| (one could argue that MSVC is slowly becoming a niche compiler
| too - it feels like it's not as important anymore as it was
| 10..15 years ago, maybe because a lot of new C/C++ programmers
| seem to start on Linux, not Windows - that's at least the
| 'general vibe' I'm getting)
| tliltocatl wrote:
| Probably not qualifies as "wide use" but embedded compilers
| like SDCC still matters. Yes, 8-bits are giving way to ARM, but
| there will be a few more millennia before they are out.
| jasode wrote:
| _> Intel probably still has their own implementation_
|
| Back in 2021, Intel moved the back end of their compiler
| toolchain to LLVM . Intel still has their own proprietary front
| end (icpx).
|
| https://www.google.com/search?q=intel+compiler+llvm+adoption
|
| https://www.intel.com/content/www/us/en/developer/articles/g...
| gpderetta wrote:
| Is icpx still and EDG derivative?
|
| EDG used to be the gold standard of ISO conformance.
| glimshe wrote:
| One cool thing about Algol is that, while the language itself is
| over 60 years old, most modern programmers can have a decent
| understanding of source code written in it. It's a bit like
| reading 17th century English. You don't quite understand
| everything, but you can grasp most of it.
|
| I wonder why the retrocomputing crowd hasn't done much in ALGOL.
| Perhaps because it's just easier to write in BASIC, which was
| influenced by it.
| pjmlp wrote:
| Probably because of the mix with nostalgia, and the folks that
| would be nostalgic about Algol 60 hardly care about computers
| nowadays.
|
| When I was a kid, the systems that we cared about were 8 bit
| home systems, starting with anything CP/M, and then there was
| the whole big machines being used at universities and our
| parents jobs, which we only knew from computer magazines.
| anthk wrote:
| Spaniard here; Spanish is like Lisp. Reading 17th century
| Spanish is almost a no brainer minus some Medieval knights'
| jargon (put from Cervantes on purpose on making fun on old-
| farts) and some 17th jargon too, specially from popular sayings
| just said in La Mancha region which are _still_ in use because
| they are related to daily farm /fields/food but the rest of
| Spain has no clear references off.
|
| Also the RAE institution for the Spanish Language does
| something similar to SRFI's + RSR?s for Scheme.
| flohofwoe wrote:
| IIRC Algol was already dead and buried in the 80's, it
| certainly wasn't relevant or even available on most computer
| systems an 80's teenager had access to. The most popular high
| level language on 8-bit home computers was certainly BASIC, for
| compiled languages probably some dialect of PASCAL, and maybe
| FORTH for something entirely different.
|
| BASIC didn't _have_ to be a bad choice either, Acorn /BBC BASIC
| even had proper inline assembly.
| TheOtherHobbes wrote:
| It was pretty much dead by the mid-70s. PASCAL, C, FORTRAN,
| and COBOL killed it on mainframes + minis and it was too
| complex for micros. (Thus - BASIC.)
|
| The twitching corpse lived on in the form of JOVIAL for DOD
| work (until ADA happened), and CORAL persisted in the UK
| because of bureaucratic momentum. Simula was another
| derivative that lasted for a while.
|
| But C and PASCAL were better, simpler, equally productive
| languages. As soon as they appeared ALGOL 60 didn't really
| need to exist any more. And ALGOL 68 was an ALGOL too far.
| leoc wrote:
| (Eleventh-century English is ... suprisingly approachable with
| the right textboox: https://ancientlanguage.com/vergil-
| press/osweald-bera/ https://youtu.be/YwECgGWCwis?t=508 .)
| algernonramone wrote:
| I think ALGOL nowadays would likely work best as sort of a
| lingua franca psuedocode, I don't think it would be too
| difficult to make that work. It kind of was already for a long
| time, as much of the Collected Algorithms of the ACM were
| originally written in it IIRC.
| jlarocco wrote:
| With a few exceptions (like APL), I've always found it pretty
| easy to read code in most languages, as long as I understood
| the paradigm, and the original author made at least a tiny
| effort to use sensible naming.
|
| Imperative languages only have a handful of concepts, like
| variables, type declaration, looping, branching, function call,
| etc. and the language and the context generally make those
| pretty easy to identify.
|
| The other language types (functional, forth-like, etc.) have
| similar (but often different) concepts, and once you understand
| the concept and can see it through the syntax, it's pretty easy
| to follow along.
|
| Writing new code in a new language is the difficult part.
| ggm wrote:
| Algol 68 ftw!
| smurpy wrote:
| My friend Colin Broughton completed the first full implementation
| of the Algo68 spec. Apparently there was some concern that it was
| not going to be implementable!
|
| https://en.wikipedia.org/wiki/FLACC
| gpderetta wrote:
| How many of them could pass Knuth test [1]?
|
| [1] https://en.wikipedia.org/wiki/Man_or_boy_test
___________________________________________________________________
(page generated 2024-12-07 23:00 UTC)