4 ms·
> The ExpressionProblem is a specific example of a larger class of problems known generally as Cross Cutting Concerns [...] Many languages include designs to he
by dahart 6y ago
> The ExpressionProblem is a specific example of a larger class of problems known generally as Cross Cutting Concerns [...] Many languages include designs to help solve the ExpressionProblem. Open functions (functions that can be extended with new pattern-matches), open data-types (data types that can be extended with new patterns), and MultiMethods ('open' specialized polymorphic functions with 'open' set of classes), and PredicateDispatching, are all viable approaches.
Working on GPU code, I feel like I'm always stuck in this problem of 'cross-cutting concerns'. I remember the guy who hired me years ago said during the interview, "we [programmers] have solved the problem of writing code for functionality, but we haven't solved the problem of writing code for performance." And this is what he meant, that cross-cutting concerns are ever present, and a new feature in the code can introduce the need for a complete refactor, or a major top-to-bottom flip in your data structures, etc.
Which languages & language features are good at both solving the expression problem functionally, and can do this with the highest priority being performance?
I also wouldn't mind hearing advice about how to evaluate when to use such features, because most often when I bump into this problem, it's not really due to lack of language features, it's due to having chosen not to use them from the start because there's some development time overhead, and I decided I most likely wouldn't use it, then over time painted myself into a corner.
- cxr 6y ago> it's not really due to lack of language features, it's due to having chosen not to use them from the start That itself is a language deficiency, though, right? Knuth on this topic: https://cr.yp.to/qhasm/literature.html https://cr.yp.to/qhasm/literature.html
- dahart 6y agoYeah, I suppose you're right it can be viewed as a language deficiency if the right thing to do is difficult and the wrong thing is easy & tempting. I guess I take responsibility for it though because I'm not sure I can imagine a time when there won't be a tradeoff to be made. Good engineering always has, and I'm guessing always will...? There definitely is something important in the ideas Knuth is expressing abstractly here, and thank you for the link. Perhaps this idea really is percolating slowly to the compiler writers, because at work we have conversations about how to talk to the compiler so that it can better optimize.
- cxr 6y ago> if the right thing to do is difficult and the wrong thing is easy & tempting That's not what I meant by linking to the Knuth piece. The deficiency lies in the language that doesn't allow you to start off doing the easy thing and then make it "right" through further dialogue, keeping the starting point easy. I'm pretty sure this is the real intent behind Knuth's focus on literate programming.
- dpc_pw 6y agoThis is not unlike any other engineering. One can't just arbitrarily change thermal isolation properties of a house without having to do some broader changes that can affect it's general structure and other aspects of it. Or you can't take a Cessna and dial up the performance requirements to make it fly as fast as a jet fighter. For some reason SWE oftentimes hope to achieve some general-AI level tooling and methodologies that would magically let them ignore everything other than than aspect they desire to change.