Somehow always, someone somewhere rediscovers that cutting down the time between coding and code execution makes our lives easier and to a degree be able to write better programs.
Perhaps the earliest and best attempt was Lisp's computational model. Since then, the idea manifested itself again[1], again[2], and again[3] in different forms.
This implies that Rust build times haven't been a topic of discussion for the last 10 years. They don't have long build times just for funsies, Rust is completely different from Lisp.
I beg to differ. It's not that Rust is completely different from Lisp. PL writers get so caught up with their 'killer feature' which in the case of Rust is the borrow checker, that they completely abandon the other 50% which is the environment.
If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.
The borrow checker is an example of a certain kind of reasoning that Rust benefits from. There's a reason a Lisp can be inspected and rewritten as the process runs, and it's the same thing that makes Rust difficult to rewrite in the same way. Not sure the exact term for it, but it's very easy to have profound nonlocal effects, for example with TAIT (type alias impl trait).
Perhaps the earliest and best attempt was Lisp's computational model. Since then, the idea manifested itself again[1], again[2], and again[3] in different forms.
[1]: Inventing on Principle, Bret Victor: https://www.youtube.com/watch?v=PUv66718DII
[2]: REPL-Driven Development, Stuart Halloway: https://vimeo.com/223309989
[3]: LIVE, Live Programming workshop: https://liveprog.org/
If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.
Just tell Opus 5.5 to "redesign the UI to not look like AI slop, design it like a human expert designer would" at bare minimum.