3 ms·

The baseline difference seems to be the difference between organizing GUI elements as stored method+field entities, vs. dynamically combined function+argument e

The baseline difference seems to be the difference between organizing GUI elements as stored method+field entities, vs. dynamically combined function+argument entities. It is a lot like the difference between greedy and lazy execution. Which code style is best depends on the structure of the items it is applied to. -- With 100 different views, respectively over 100 different items to be viewed, storing 100 view+item pairs as objects is both general and efficient. With 10 different views, repeatedly over 10 different items to be viewed, there are still 100 interface elements. But repeatedly joining view and item information at draw time provides a 10x space/object savings. And allows for other code simplifications. -- General takeaway: Pre-compiled general libraries, that cannot be treated as inlined compile-time optimizable templates (in the code context where the templates are applied), will be inefficient and overbuilt for cases with more structure and simplicity than they were designed for.

eru 3y ago
Wouldn't link-time-optimization take care of your 'general takeaway'?
- Nevermark 3y ago
  Yes, definitely. Link, optimize, compile/code-gen. Instead of optimize, compile, link.
crq-yml 3y ago
I see it as the crossover between approaches amenable to static order and iteration, vs those that demand constraint optimization. This is a recurring problem in programming, because if you code towards the optimal result, you end up making a static, linearized computation that doesn't need further configuration. But if your goal is to provide interfaces and automation, you are tasked with a constraint problem, where you have multiple potential solutions and you either have to filter them down to a single unambiguous result, or find a heuristic that defines the "best one". The problem occurs with type systems, graphical layout, multi-body physics simulation, dependency management and a host of other things. I consider it the most unaddressed subject in CS because it's so relevant to applications and yet industry continually reinvents it in terms of a bespoken algorithm for that one application. And depending on what you're doing, you end up biasing to one or the other method first: a small, well-defined problem only needs the computer to do "brute" things, while a problem dependent on the computer managing the complexity of the problem needs it to find and correct errors.

eru 3y ago

Wouldn't link-time-optimization take care of your 'general takeaway'?

Nevermark 3y ago
Yes, definitely. Link, optimize, compile/code-gen. Instead of optimize, compile, link.

crq-yml 3y ago

I see it as the crossover between approaches amenable to static order and iteration, vs those that demand constraint optimization. This is a recurring problem in programming, because if you code towards the optimal result, you end up making a static, linearized computation that doesn't need further configuration. But if your goal is to provide interfaces and automation, you are tasked with a constraint problem, where you have multiple potential solutions and you either have to filter them down to a single unambiguous result, or find a heuristic that defines the "best one". The problem occurs with type systems, graphical layout, multi-body physics simulation, dependency management and a host of other things. I consider it the most unaddressed subject in CS because it's so relevant to applications and yet industry continually reinvents it in terms of a bespoken algorithm for that one application. And depending on what you're doing, you end up biasing to one or the other method first: a small, well-defined problem only needs the computer to do "brute" things, while a problem dependent on the computer managing the complexity of the problem needs it to find and correct errors.