3 ms·

I don’t think that’s the problem. There are so many different ways to look at a system. An architectural diagram shows you how components connect. A procedural

I don’t think that’s the problem. There are so many different ways to look at a system. An architectural diagram shows you how components connect. A procedural diagram shows you what steps a program takes. An entity diagram shows you the major high level entities you’ve selected into your system. I just don’t see how a single language can express all the detail. Maybe a new one can be invented but I don’t see how S expressions solve this (the link you posted don’t have any indication that any diagram generation is part of the language). Also, diagrams can be useful even if they have birotted because discrepancies are a good teaching tool - “why does this diagram say x but the code seems to do y” is a tracing opportunity, an opportunity to update the diagram, and highlights which engineers are paying attention. Maybe if LLMs get sufficiently advanced they can generate this stuff more automatically with some minor prompting with the code as context, but I doubt it. Not until AI can actually start understanding sentiment from code.

mpweiher 3y ago
> An architectural diagram shows you how components connect. That's the one we're talking about here. > A procedural diagram shows you what steps a program takes Which is useful if the program is procedural. > An entity diagram shows you the major high level entities you’ve selected into your system. That's the top-level of your architectural diagram. > I just don’t see how a single language can express all the detail. When the program's architectural style is call/return, we can do this just fine. Using stepwise refinement we move up and down the abstraction ladder of our system and thus add/remove detail. No problem. The problem is that most systems these days are not primarily call/return, but have to be programmed in call/return languages. > I don’t see how S expressions solve this I don't either, and have no idea what S expressions have to do with this. > .... diagram generation is part of the language It's not part of the language. But it's part of the frameworks, and when the abstractions of your language are architectural in nature, there is a very close correspondence between the code and the diagrams. > ... discrepancies are a good teaching tool... Yes, since the diagrams are generated, it's easy to keep older version around and generate new ones on-demand. Then you can check the differences visually, in code, or as the difference between code and diagram. Take your pick. > Not until AI can actually start understanding sentiment from code. Again, the point is that architecture is not actually "sentiment". It is structural. The fact that it looks like sentiment in practice is purely a side effect of our programming languages being incapable of encoding architecture in the general case.

mpweiher 3y ago

> An architectural diagram shows you how components connect. That's the one we're talking about here. > A procedural diagram shows you what steps a program takes Which is useful if the program is procedural. > An entity diagram shows you the major high level entities you’ve selected into your system. That's the top-level of your architectural diagram. > I just don’t see how a single language can express all the detail. When the program's architectural style is call/return, we can do this just fine. Using stepwise refinement we move up and down the abstraction ladder of our system and thus add/remove detail. No problem. The problem is that most systems these days are not primarily call/return, but have to be programmed in call/return languages. > I don’t see how S expressions solve this I don't either, and have no idea what S expressions have to do with this. > .... diagram generation is part of the language It's not part of the language. But it's part of the frameworks, and when the abstractions of your language are architectural in nature, there is a very close correspondence between the code and the diagrams. > ... discrepancies are a good teaching tool... Yes, since the diagrams are generated, it's easy to keep older version around and generate new ones on-demand. Then you can check the differences visually, in code, or as the difference between code and diagram. Take your pick. > Not until AI can actually start understanding sentiment from code. Again, the point is that architecture is not actually "sentiment". It is structural. The fact that it looks like sentiment in practice is purely a side effect of our programming languages being incapable of encoding architecture in the general case.