> probably most of the time we don't need to do fancy type manipulation or dynamic dispatch at runtime The fact is, I really wish there were a way to have the

> probably most of the time we don't need to do fancy type manipulation or dynamic dispatch at runtime The fact is, I really wish there were a way to have the ability to build systems that you can recompile at runtime that had types. The recompilation itself is the "problem," or at least an inconvenience. You have to interrupt your flow in order to test even the smallest change. Yes, this is a selfish programmer desire to make building things easier. The general consensus is that it's not worth having flexibility over the stability that types enforce, and for most cases I would agree. It would be ridiculous to program critical systems like financial software with the expectation you'd be able to walk right up to it and deploy changes whenever you want. There isn't a need for extensibility with that use case. But there are some cases where extensibility is a key part of the development cycle, like Emacs or Excel or game development. Iteration is important in those cases, seeing that you can make some changes and test them out, "teaching" the program what you want until it's just right. My experience is that this is an optimal development cycle, where I'm not prone to be distracted easily and lose more time than I needed to when I intended to just compile something. It's just that I'm not seeing why having types means you must use a machine-compiled language, meaning you now have to reboot the program to see your changes. I wish there was a best-of-both-worlds solution that works in the weird way I expect. The closest thing I know of is Teal, which compiles to Lua, but it will be a while before it's production-ready.