4 ms·

> A Hare program written on the day that 1.0 releases will still compile in 50 years on contemporary Hare compilers. In fact, a Hare compiler written on the sam

by msla 3y ago

> A Hare program written on the day that 1.0 releases will still compile in 50 years on contemporary Hare compilers. In fact, a Hare compiler written on the same release date will compile new Hare programs 50 years from now. That’s something which hasn’t really been done before [snip] Because fifty years ago, 16-bit systems and 36-bit systems were still commercially interesting. Code meant to be performant on systems with 36-bit words and 18-bit pointers, where it's possible to operate on arbitrary bitfields within a word using native opcodes, would probably not fare well on systems from a later era, where a machine word is a power-of-two multiple of eight, a pointer is a machine word, and a byte is eight bits practically by definition. It's taken decades to nail down the fundamental shape of the basic machine-level data types. We weren't there yet in the early 1970s.

tremon 3y ago
I get what you're saying, but I don't think you've identified the problem correctly: with the proper programming abstractions, it shouldn't matter what the word size or byte size of the machine is. The problem with code from that era is that compilers were as anemic as the processors that they ran on, so there was not a lot of room (and experience, as you say) to conceive programming languages that were fully decoupled from the software architecture (someone will come in now and shout LISP). We still have that same problem today when it comes to vector code (and graphics/LLM/tensor processing): the abstractions we use are tightly coupled to the hardware capabilities, which means lots of redesign surrounding the compiler and code structures every time a new hardware iteration comes out. I fully expect that in another 10-20 years, our current approach to vector programming will look as primitive as how we look at system code from 50 years ago. So while Hare may still be able to compile single-issue imperative code 50 years from now, I don't think it's too far left-field to posit that the sequential/imperative paradigm we use now might end up being replaced with different processing/signaling paradigms on both the language design and the processor design front, leaving Hare as nothing but a quaint footnote like B.

by msla 3y ago

tremon 3y ago

I get what you're saying, but I don't think you've identified the problem correctly: with the proper programming abstractions, it shouldn't matter what the word size or byte size of the machine is. The problem with code from that era is that compilers were as anemic as the processors that they ran on, so there was not a lot of room (and experience, as you say) to conceive programming languages that were fully decoupled from the software architecture (someone will come in now and shout LISP). We still have that same problem today when it comes to vector code (and graphics/LLM/tensor processing): the abstractions we use are tightly coupled to the hardware capabilities, which means lots of redesign surrounding the compiler and code structures every time a new hardware iteration comes out. I fully expect that in another 10-20 years, our current approach to vector programming will look as primitive as how we look at system code from 50 years ago. So while Hare may still be able to compile single-issue imperative code 50 years from now, I don't think it's too far left-field to posit that the sequential/imperative paradigm we use now might end up being replaced with different processing/signaling paradigms on both the language design and the processor design front, leaving Hare as nothing but a quaint footnote like B.