Lambda the Ultimate

Thanks, I was hoping for something that jarred my perspective. I like both resource and material. Mulling these over, I decided I didn't want a term, I want a metaphor that terms should follow. And here the metaphor I like is that digital materials are just like real world non-digital materials, so use the same word you would in a similar situation. If you take inventory of what is on hand, you call each thing by whatever word covers the role that matters to you: resources, assets, junk, bulk content, items with serial numbers, whatever. Material executing at runtime tends to favor words that imply behavior.

Each fragment of material is an instance of some general class in a usage domain. So domain is something general about a class of items. You can call items of digital content whatever you want, depending on a role emphasized. Term "fragment" emphasizes role as piece of some larger whole. Using fewer terms actually doesn't help, since information theory says you convey less by a word the more likely that word is to appear. A term repeated over and over thus becomes bleating, so varying synonyms can improve clarity.

This view makes my original point pretty uninteresting, which seems good. Little is left besides domain change across fragment boundaries.

I like your point about metaphors. It reminds me we have "desktops", and "windows" etc. I guess the human brain is hardwired by evolution to prefer certain physical representations. We will always find it easier to catch a ball, than we do to calculate it's trajectory by calculus, even though we are solving the same problem in both cases. Finding the right metaphor can make complex problems simple. There is already a link between software and construction as we already use the metaphor of architecture.

My point was partly that metaphors are not false. Some folks may assume, "You can't use metaphors because that's not what is actually happening." But I suggest if you are understood, then part of truth relevant at the moment is getting through. When you design something based on a metaphor, and code obeys that model, then metaphor is what actually happens at some level of abstraction.

Historically, "metaphors are great" is strongly associated with user interface design. Users are shown windows and desktops, but they are simulations and not "what actually happens". However, if code has frameworks and objects involving windows and desktops, maybe it really is partly what actually happens. I suppose there's no reason to limit metaphors to just GUI entities. And in practice we don't because we have all kinds of abstract models in software systems, like heaps and stacks and processes. These are real when the model applies, as opposed to convenient figments.

I was suggesting there is no level of abstraction where metaphor is inappropriate. When you speak figuratively, but it captures a model correctly enough, then it is true to the extent anything we say in natural language approaches true. Even when determined to hew to a hardware perspective, hardware must be designed to follow models that makes sense to us, so metaphors are present. Sometimes the metaphor is a story with numerous actors. (This is practically what instruction architecture means.)

Calculus of moving objects is sometimes less impressive than it seems when "constant rate of closure" is a good enough approximation. To stay on a collision course, you need only maintain the same bearing with a target. Pretend I say something clever here, something about drawing a business plan on a napkin, and how this metaphor is useful despite being simple.