2 ms·
> The end-game is just dissolving any distinction between compile-time and run-time This was done in the 60s/70s with FORTH and LISP to some degree, with the f
by packetlost 2y ago
> The end-game is just dissolving any distinction between compile-time and run-time
This was done in the 60s/70s with FORTH and LISP to some degree, with the former being closer to what you're referring to. FORTH programs are typically images of partial applications state that can be thought of as a pile of expanded macros and defined values/constants (though there's virtually no guardrails).
That being said, I largely agree with you on several of these and think would like to take it one step further: I would like a language with 99% bounded execution time and memory usage. The last 1% is to allow for daemon-like processes that handle external events in an "endless" loop and that's it. I don't really care how restricted the language is to achieve that, I'm confident the ergonomics can be made to be pleasant to work with.
- andyferris 2y agoYeah that would be cool. For bounded execution, you should look at “total functional programming” (which always terminates). They have this concept of codata for the other 1% to make practical, interactive apps - codata represents things like event streams.
- astrobe_ 2y ago> This was done in the 60s/70s with FORTH and LISP to some degree Around 2000, Chuck Moore dissolved compile-time, run-time and edit-time with ColorForth, and inverted syntax highlighting in the process (programmer uses colors to indicate function).
- packetlost 2y agoFORTH was around long before ColorForth