AOT vs. JIT Type Checking
2025-12-17
Emil H’s video contains some intriguing ideas regarding static vs. dynamic type checking.
Some thoughts that occur to me as I watch:
What about `eval()` and other hard-to-check language constructs? Eval is incredibly useful during development, but is actively shunned by traditional “static”, syntactically-scoped programming languages
Type checkers are tools and should not be hard-wired into compilers nor directly affect the syntaxes of programming languages. If type checkers were implemented as separate linters, then the decision to use compile-run-anyway vs. compile-run-only-perfect-code becomes a trivial act of just plugging an appropriate linter into the workflow.
Languages like Smalltalk and Lisp have the ability to save out the “image” - the full state of the compiler / interpreter / developmentEnvironment - then load it back in. So you can quit and go home at the end of the day and resume from where you left off the next morning. In such environments, the most recent definition of a function shadows all previous definitions of functions with the same name.
Prototypal inheritance languages, like Self, are more flexible - more dynamic - than class-based languages. Classes - as we know them - are born out of the AOT type-checking mindset. In a good REPL environment, you can retroactively change the definition of a class at runtime, i.e. when you change your mind during Design.
Common Lisp has the concept of a restart where you can fix something after an “error” occurs and just proceed from where you left off.
Should syntax-checking be an AOT-only concept, or should you be able to run programs that contain syntax errors?
Does the concept of worlds relate to this video?
I think that we need to use two languages - one for iterative Design of programs and another for Waterfall Production Engineering of programs. Our current programming languages tend to fall into the Production Engineering category IMO. I’ve been experimenting with code transmogrification. The thinking is that we perform multiple “takes” on a Design, choose the “best” one, then transmogrify it into a Production Engineering language, using a transmogrifier tool (parse, rewrite scripts). We get to save and view the provenance from Design to Production in the form of transmogrification scripts. Using older compiler techniques, like peephole optimization, can greatly aid the process of rewriting. My impression is that there is some overlap here - this video is probably going to give new inspiration.
Possibly-related trains of thought, previously published on my substack...
See Also
Email: ptcomputingsimplicity@gmail.com
Substack: paultarvydas.substack.com
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Bluesky: @paultarvydas.bsky.social
Mastodon: @paultarvydas
(earlier) Blog: guitarvydas.github.io
References: https://guitarvydas.github.io/2024/01/06/References.html