20:38
@libby My point was that difficult problems are difficult, and it can take a lot of time/experience to arrive at something that feels right.
The software in question is essentially a HTML template engine or markup language.
HTML elements are specified in terms of the Document Object Model (DOM). In early drafts I tried emulating that, or to at least have different classes for elements like “<p> paragraph” or “<a> hyperlink” or “<br/> linebreak”. After all, they have different properties and behave differently. But all of that was too complex.
What ended up working was a simple data structure to represent the content that just used strings to identify the element type, and a separate hash table that described the details of each type.
As one advantage I didn't have to hardcode element types but could just load them from a configuration file.
So by giving up trying to directly model the interactions of various types in my system, I instead created a mechanism that allowed these details to be defined externally. My software is then more like an engine or an interpreter, less like the actual model I'm building on top of it.
This may be transferable to your problem: instead of directly modelling concepts like temperature within your software, you may get further by treating that concept as just some kind of data.
Of course, all software is data. But the question is whether we use a given language to model our concepts, or whether we create a language that allows our concepts to be expressed easily.
That's why I mentioned Entity-Attribute-Value systems previously: those are a way to represent arbitrary data models within a relational database. Horrible for query performance, but awesome for flexibility. They are an example of a technique that helps escapes the restrictions of the language you are using.
The Whiteboard
The Whiteboard