4 ms·

Being graphical is probably not sufficient for a notation to fail; electrical circuit diagrams were/are a successful notation even though there is no obvious le

Being graphical is probably not sufficient for a notation to fail; electrical circuit diagrams were/are a successful notation even though there is no obvious lexicographic ordering of the symbols.

qikInNdOutReply 4y ago
Excellent example of how a notation can succeed and fail at the same time. Electric symbols are used as a programming language in the plc sector and fail horrible when programs accumulate ever more complexity.
lisper 4y ago
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. A line in a circuit diagram means that there are two physical things located in physical space with a physical wire going between them. There is no such natural correspondence for software because software does not exist in physical space.
- eternalban 4y ago
  > software does not exist in physical space 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-symbols/amplifier-circuits-symbols.htm https://www.electrical-symbols.com/electric-electronic-symbo... (amplifier, cache? semantics of the cache? ...) https://www.electrical-symbols.com/electric-electronic-symbols/electrical-symbols.htm https://www.electrical-symbols.com/electric-electronic-symbo... https://www.electrical-symbols.com/electronic-electrical-symbols/table-electronic-symbols.htm 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-button-led-circuit.png 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]
  - lisper 4y ago
    > 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.
    - eternalban 4y ago
      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.
      - lisper 4y ago
        > 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.
- mjevans 4y ago
  Data Flow Diagram should be the model you think of. How does the data flow? Split apart and recombine? It might be easier to understand as a flow diagram for a major industrial plant, functions and programs like robots and major machines.
  - tuatoru 4y ago
    The key part of the Data Flow Diagramming method (as I was taught it, anyway) was not graphical: the Data Dictionary. This was, as the name implies, a dictionary that was the single source of truth for definitions of data items: meaning, representation, meaning of enumerated values, synonym and their business contexts, examples, caveats, etc. Easily implemented as a single table in your database. Never done these days, although it would probably simplify learning a system quite a lot.
- jeremyjh 4y ago
  Another aspect is that in software, the code is actually the design. So a diagram that only approximates the design is not so useful as it is in electrical engineering where there still MUST BE a completely accurate design or the project fails.
- dan-robertson 4y ago
  I feel like you’re weaselling out of your earlier statement a bit. In your top comment you talk about it being hard to look up symbols. I point out that you need to look up symbols for circuit diagrams and you say that actually one doesn’t need to look them up because they are actually intuitive and you invent a new criterion for diagrams to fail so that circuit diagrams can pass through but UML cannot. I claim that circuit diagram symbols aren’t particularly intuitive (e.g. the symbol for a resistor is just a longer wire? The symbol for a transistor is very non-obvious, I think. The symbol for a potentiometer is pretty difficult even if you know how one works.) And another example of a visual representation that works well even though it is for something intangible is the kind of grammar diagram you can see in the SQLite documentation where terminal symbols are in rounded rectangles, non-terminal symbols in regular rectangles, and arrows indicate concatenation (I.e. production rules). To be clear, I don’t want to disagree with your overall opinion that UML is bad or that the symbols are intuitive, and perhaps that is the reason that UML failed, but I think the reasoning about visual notations and the reasons they fail in general is faulty and I don’t think the answer is to find ever narrower definitions of the cases where visual notation systems don’t work.
  - lisper 4y ago
    Fair points all. A few nits though: the symbol for a resistor is not "just a longer wire", it's a zig-zag shape, and IMHO the symbol for a potentiometer is pretty intuitive. And yes, SQL's syntax diagrams work well. But I think the reason they work well is that they aren't trying to describe software, they are trying to describe (the structure of) a certain kind of text and text is spatial. Electric circuit notation could probably be improved. Same for math notation. But both of these are pretty deeply entrenched at this point. (I will note, however, that I am currently working on maintaining a chip design tool that describes circuits using S-expressions so the situation is not hopeless. :-)
    - rini17 4y ago
      How do you bridge the gap between trees (s-exprs) and graphs with cycles (actual circuits)?

Being graphical is probably not sufficient for a notation to fail; electrical circuit diagrams were/are a successful notation even though there is no obvious lexicographic ordering of the symbols.

qikInNdOutReply 4y ago

Excellent example of how a notation can succeed and fail at the same time. Electric symbols are used as a programming language in the plc sector and fail horrible when programs accumulate ever more complexity.

lisper 4y ago

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. A line in a circuit diagram means that there are two physical things located in physical space with a physical wire going between them. There is no such natural correspondence for software because software does not exist in physical space.

eternalban 4y ago
> software does not exist in physical space 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-symbols/amplifier-circuits-symbols.htm https://www.electrical-symbols.com/electric-electronic-symbo... (amplifier, cache? semantics of the cache? ...) https://www.electrical-symbols.com/electric-electronic-symbols/electrical-symbols.htm https://www.electrical-symbols.com/electric-electronic-symbo... https://www.electrical-symbols.com/electronic-electrical-symbols/table-electronic-symbols.htm 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-button-led-circuit.png 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]
- lisper 4y ago
  > 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.
  - eternalban 4y ago
    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.
    - lisper 4y ago
      > 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.
mjevans 4y ago
Data Flow Diagram should be the model you think of. How does the data flow? Split apart and recombine? It might be easier to understand as a flow diagram for a major industrial plant, functions and programs like robots and major machines.
- tuatoru 4y ago
  The key part of the Data Flow Diagramming method (as I was taught it, anyway) was not graphical: the Data Dictionary. This was, as the name implies, a dictionary that was the single source of truth for definitions of data items: meaning, representation, meaning of enumerated values, synonym and their business contexts, examples, caveats, etc. Easily implemented as a single table in your database. Never done these days, although it would probably simplify learning a system quite a lot.
jeremyjh 4y ago
Another aspect is that in software, the code is actually the design. So a diagram that only approximates the design is not so useful as it is in electrical engineering where there still MUST BE a completely accurate design or the project fails.
dan-robertson 4y ago
I feel like you’re weaselling out of your earlier statement a bit. In your top comment you talk about it being hard to look up symbols. I point out that you need to look up symbols for circuit diagrams and you say that actually one doesn’t need to look them up because they are actually intuitive and you invent a new criterion for diagrams to fail so that circuit diagrams can pass through but UML cannot. I claim that circuit diagram symbols aren’t particularly intuitive (e.g. the symbol for a resistor is just a longer wire? The symbol for a transistor is very non-obvious, I think. The symbol for a potentiometer is pretty difficult even if you know how one works.) And another example of a visual representation that works well even though it is for something intangible is the kind of grammar diagram you can see in the SQLite documentation where terminal symbols are in rounded rectangles, non-terminal symbols in regular rectangles, and arrows indicate concatenation (I.e. production rules). To be clear, I don’t want to disagree with your overall opinion that UML is bad or that the symbols are intuitive, and perhaps that is the reason that UML failed, but I think the reasoning about visual notations and the reasons they fail in general is faulty and I don’t think the answer is to find ever narrower definitions of the cases where visual notation systems don’t work.
- lisper 4y ago
  Fair points all. A few nits though: the symbol for a resistor is not "just a longer wire", it's a zig-zag shape, and IMHO the symbol for a potentiometer is pretty intuitive. And yes, SQL's syntax diagrams work well. But I think the reason they work well is that they aren't trying to describe software, they are trying to describe (the structure of) a certain kind of text and text is spatial. Electric circuit notation could probably be improved. Same for math notation. But both of these are pretty deeply entrenched at this point. (I will note, however, that I am currently working on maintaining a chip design tool that describes circuits using S-expressions so the situation is not hopeless. :-)
  - rini17 4y ago
    How do you bridge the gap between trees (s-exprs) and graphs with cycles (actual circuits)?