The root of all the blessings and curses of software.
> The reason graphical notation works for circuits is that circuits are actual physical things and so there is a natural correspondence between the graphical notation and the thing that notation describes.
This really just boils down to complexity and verbosity, so 'fundamentally' it has nothing to do with virtual nature of software. Hardware people lucked out (in this case) but as the semantics of components get more involved, so do the component notations:
Right now it is unmanageable to do this for software. OP's write up actually mentioned the cause: they were trying to bootstrap UML with UML, defining 'semantics' using the core notation. This is the sort of 'elegant' approach that generally ends up getting buried under its own weight. So the question boils down to 'Is this complexity irreducible and open ended?'
Not sure about the reducible but am definitely bullish on it being 'closed'. [Software may lack physics, but it certainly has both form and structure.]
p.s. I think in isolation, specific aspects of software components can be [completely] described simply. For example, there are only so many ways bits can go in and out of a black box. Same for interaction patterns, there are a handful of modalities (such as caller, server, peer). Etc.
> This really just boils down to complexity and verbosity
No, it doesn't. Hardware really is fundamentally different from software because it is constrained by the laws of physics (and economics) in ways that software is not. So, for example, even complicated components tend to get fabricated in a way that the constituents are physically co-located with each other. That's why you can take a photo of an actual physical chip and draw boundaries around the various parts. Not only that, but those boundaries tend to be rectangles. So even complex hardware naturally lends itself to simple representations in 2-D space with intuitive mappings between the representation and the underlying (physical) reality. None of that is true for software.
One can get lost talking about such details. It is a fact that the act of programming is a very elaborate means of modeling physical events. In fact we can simply map language->compiler->machine-code->physical-device and note that our programs in language x are in fact obscure models directing physical devices.
Fundamentally (as significant to software), physics gets you Pauli Exclusion, relative time, distance, and of course energy (computational power). This has huge ramifications for software and why it resists becoming an 'engineering' field. But it does -not- imo preclude the possibility of effective and comprehensive notation for software definition.
p.s. since you are a lisper, you are already 1/2 way there to a universal modeling approach. I assume you would answer in affirmative to the question 'is there a viable universal textual notation for defining software?' with "Yes, it's called s-expression'. [In that case you would be] simply denying that a graphical analog can be developed. On that, consider the janky [early] attempts of everyone's ancestors in developing their alphabet/glpyh systems, currently in use.
> programming is a very elaborate means of modeling physical events
The operative word being events. Hardware design is not about events, it's about putting the right kind of atom in the right place, which is a lot harder than moving some electrons from A to B at the right time.
The root of all the blessings and curses of software.
> The reason graphical notation works for circuits is that circuits are actual physical things and so there is a natural correspondence between the graphical notation and the thing that notation describes.
This really just boils down to complexity and verbosity, so 'fundamentally' it has nothing to do with virtual nature of software. Hardware people lucked out (in this case) but as the semantics of components get more involved, so do the component notations:
https://www.electrical-symbols.com/electric-electronic-symbo...
(amplifier, cache? semantics of the cache? ...)
https://www.electrical-symbols.com/electric-electronic-symbo...
https://www.electrical-symbols.com/electronic-electrical-sym...
Right now it is unmanageable to do this for software. OP's write up actually mentioned the cause: they were trying to bootstrap UML with UML, defining 'semantics' using the core notation. This is the sort of 'elegant' approach that generally ends up getting buried under its own weight. So the question boils down to 'Is this complexity irreducible and open ended?'
Not sure about the reducible but am definitely bullish on it being 'closed'. [Software may lack physics, but it certainly has both form and structure.]
p.s. I think in isolation, specific aspects of software components can be [completely] described simply. For example, there are only so many ways bits can go in and out of a black box. Same for interaction patterns, there are a handful of modalities (such as caller, server, peer). Etc.
p.s.s:
Consider https://circuits-diy.com/wp-content/uploads/2020/01/push-but...
Will you still insist there is a 'natural correspondence' if I naively decide to run wires from DC to LA for a that 'circuit'?
Would it work? [spoiler: no, it won't]