3 ms·

Even if you can compile away the performance problems, how do you escape the analytical mess that is left being? Patching software the old-fashioned way is expe

by adamc 7y ago

Even if you can compile away the performance problems, how do you escape the analytical mess that is left being? Patching software the old-fashioned way is expensive because we have to integrate the changes into the model -- essentially, rethink parts of the software. But the result is certainly likely to be easier to understand down the line. In a layered, "historical" model, I now have to understand the entire history, and correctly deduce how the history has changed the functioning of the original model. That strikes me as horrible.

btown 7y ago
Is this not a tooling problem? There are two compiler targets: the runtime, and the engineer. A system like this is sustainable iff it can compile a subset of the runtime-necessary information into a readable, interactive, sequential form. And this very much exists in the real world: every moddable video game, every audio/video tool accepting plugins, every multi-team business workflow, every browser plugin architecture, every SQL trigger... all are collections of independently developed state machines, intercepting a global event list and interrupting with their own events, just waiting to conflict with each other. Plugins and (blocking/yielding) extension points are the only real way to build software with massive feature surface areas. The tooling to visualize and debug these flows is IMO quite lacking, and I don’t think this is helped by systems engineers’ general love for all things textual. One needs to not only understand the flows they think will happen, but also fuzz the ones they don’t, and all this needs to be presented in a way that doesn’t overwhelm human working memory. I don’t think that’s a solved problem by any stretch. And I doubt the solution will look like our current text editors. But it’s something I think about quite often.

by adamc 7y ago

btown 7y ago

Is this not a tooling problem? There are two compiler targets: the runtime, and the engineer. A system like this is sustainable iff it can compile a subset of the runtime-necessary information into a readable, interactive, sequential form. And this very much exists in the real world: every moddable video game, every audio/video tool accepting plugins, every multi-team business workflow, every browser plugin architecture, every SQL trigger... all are collections of independently developed state machines, intercepting a global event list and interrupting with their own events, just waiting to conflict with each other. Plugins and (blocking/yielding) extension points are the only real way to build software with massive feature surface areas. The tooling to visualize and debug these flows is IMO quite lacking, and I don’t think this is helped by systems engineers’ general love for all things textual. One needs to not only understand the flows they think will happen, but also fuzz the ones they don’t, and all this needs to be presented in a way that doesn’t overwhelm human working memory. I don’t think that’s a solved problem by any stretch. And I doubt the solution will look like our current text editors. But it’s something I think about quite often.