5 ms·

Getting a good layout is too dependent on the order of definition. I can see that becoming unsolvable for the user for large diagrams but seems ok for small one

Getting a good layout is too dependent on the order of definition. I can see that becoming unsolvable for the user for large diagrams but seems ok for small ones. For example the following gives an ugly yet valid layout of the example: [more loot] no ->[<end>e] [<start>start] -> [<state>plunder] -> [<choice>more loot] -> [start] [Pirate| [foul mouth]<:-[beard] [parrot]--[beard] ] [<table>mischief| bawl | sing || yell | drink ] [<abstract>Marauder]<:--[Pirate] [Pirate] - 0..7[mischief] [<actor id=sailor>Jolly;Sailor] [sailor]->[rum] [Pirate]-> *[rum|tastiness: Int|swig()] [sailor]->[Pirate]

bmacho 3y ago
edit: I thought that it goes top to down, but no, it determines order other ways. Original Pirate table: [Pirate| [beard]--[parrot] [beard]-:>[foul mouth] ] parent posts Pirate table [Pirate| [foul mouth]<:-[beard] [parrot]--[beard] ] this is upside down. Defining beard and parrot the order we want them to appear doesn't help: [Pirate| [beard] [parrot] [foul mouth] [foul mouth]<:-[beard] [parrot]--[beard] ] it is still upside down.
- ororroro 3y ago
  Thanks for treating this as a puzzle. I think it proves the point that you either need to reverse engineer the layout engine in your head or guess and check to get good layouts.
Veuxdo 3y ago
This pirate example is not doing us any favors. Is there a way to arrange these jumble of words in a way that makes any sense?
- p1mrx 3y ago
  Arrr, it be fine as it be, now sail off ye scallywag.
  - p1mrx 3y ago
    Edit: If ye wish to see, Ctrl-C, Ctrl-V.
- kstrauser 3y ago
  I get what you’re saying. What’s the relationship between beard and parrot, if all you had was the text of the diagram and didn’t already know nomnoml? A great example would use new syntax to illustrate relationships you already understand to demonstrate how to write them.
Savely 3y ago
We need another tool that would optimise permutation of statements for least overlap in the resulting diagram.
zoogeny 3y ago
One problem with these tools is that even if you manage to get a good layout for a document then as soon as you need to add/remove/update then you have to wrestle with them all over again. I've used a few of these code-as-diagram products because I dream of a world where technical documentation, including diagrams, are part of the source code of a project. But my experience is that getting acceptable layouts, especially for external distribution but also just for internal use, is arduous. And that frustration leads to at least two possible undesirable outcomes: the diagrams become unreadable or the diagrams become unmaintained. To be honest, the idea of code-reviewing the documents during check-in is also a myth. In general the diffs on these kind of documents are extremely difficult to grok. It is almost impossible to meaningfully check the document is correct without rendering it and reviewing the output. It is the kind of thing I really wish worked. Maybe one day it will become a solved problem.
- dangets 3y ago
  I've thought the same quite a bit. On one end of the spectrum you could use something like SVG if there were standard or dominant tools used to import/export, but then you lose the ascii readability benefit of tools like this, dot, or d2. It'd be nice to have a mixed text & GUI editor for something like Pikchr diagrams. https://pikchr.org/home/doc/trunk/homepage.md https://pikchr.org/home/doc/trunk/homepage.md https://d2lang.com/ https://d2lang.com/
  - zoogeny 3y ago
    Something in the direction of SVG is probably correct. I like the idea of having arbitrary paths available. One common annoyance with existing tools is that there is sometimes a lack of shapes and colors that express what I want. I find the same even with Google's rudimentary drawing tools. It may be the case that these diagraming tools are aiming to be too high level. But where the middle ground lies I am not too sure. It is nice to express high level concepts like "Actors" or "Process" or "Class". And it is nice to have convenient syntax for things like UML sequence diagrams. I don't think it would be an equal exchange to give me rectangle and line drawing primitives since now I'd have to manage the connections by hand. And there would be no semantic meaning in such text formats, even if you managed to retain "readability". But on the other hand ... to get the diagram solutions into a visual format I like I tend to lose the readability anyway. If you have several boxes with many connection - even reading the text becomes difficult. It is hard to keep the connections in your head once they get 2 or 3 hops deep. And you end up with 15 lines of connection spam, like "EntityA -> EntityB", "EntityC -> EntityB", "EntityA -> EntityD". And you end up trying to manage hierarchical relationships, fussing over what is the correct order to declare things, like manually doing your own dependency resolution. So maybe strict readability isn't really even a property I can expect to maintain. I really hope it gets solved one day.

bmacho 3y ago

edit: I thought that it goes top to down, but no, it determines order other ways. Original Pirate table: [Pirate| [beard]--[parrot] [beard]-:>[foul mouth] ] parent posts Pirate table [Pirate| [foul mouth]<:-[beard] [parrot]--[beard] ] this is upside down. Defining beard and parrot the order we want them to appear doesn't help: [Pirate| [beard] [parrot] [foul mouth] [foul mouth]<:-[beard] [parrot]--[beard] ] it is still upside down.

ororroro 3y ago
Thanks for treating this as a puzzle. I think it proves the point that you either need to reverse engineer the layout engine in your head or guess and check to get good layouts.

Veuxdo 3y ago

This pirate example is not doing us any favors. Is there a way to arrange these jumble of words in a way that makes any sense?

p1mrx 3y ago
Arrr, it be fine as it be, now sail off ye scallywag.
- p1mrx 3y ago
  Edit: If ye wish to see, Ctrl-C, Ctrl-V.
kstrauser 3y ago
I get what you’re saying. What’s the relationship between beard and parrot, if all you had was the text of the diagram and didn’t already know nomnoml? A great example would use new syntax to illustrate relationships you already understand to demonstrate how to write them.

Savely 3y ago

We need another tool that would optimise permutation of statements for least overlap in the resulting diagram.

zoogeny 3y ago

One problem with these tools is that even if you manage to get a good layout for a document then as soon as you need to add/remove/update then you have to wrestle with them all over again. I've used a few of these code-as-diagram products because I dream of a world where technical documentation, including diagrams, are part of the source code of a project. But my experience is that getting acceptable layouts, especially for external distribution but also just for internal use, is arduous. And that frustration leads to at least two possible undesirable outcomes: the diagrams become unreadable or the diagrams become unmaintained. To be honest, the idea of code-reviewing the documents during check-in is also a myth. In general the diffs on these kind of documents are extremely difficult to grok. It is almost impossible to meaningfully check the document is correct without rendering it and reviewing the output. It is the kind of thing I really wish worked. Maybe one day it will become a solved problem.

dangets 3y ago
I've thought the same quite a bit. On one end of the spectrum you could use something like SVG if there were standard or dominant tools used to import/export, but then you lose the ascii readability benefit of tools like this, dot, or d2. It'd be nice to have a mixed text & GUI editor for something like Pikchr diagrams. https://pikchr.org/home/doc/trunk/homepage.md https://pikchr.org/home/doc/trunk/homepage.md https://d2lang.com/ https://d2lang.com/
- zoogeny 3y ago
  Something in the direction of SVG is probably correct. I like the idea of having arbitrary paths available. One common annoyance with existing tools is that there is sometimes a lack of shapes and colors that express what I want. I find the same even with Google's rudimentary drawing tools. It may be the case that these diagraming tools are aiming to be too high level. But where the middle ground lies I am not too sure. It is nice to express high level concepts like "Actors" or "Process" or "Class". And it is nice to have convenient syntax for things like UML sequence diagrams. I don't think it would be an equal exchange to give me rectangle and line drawing primitives since now I'd have to manage the connections by hand. And there would be no semantic meaning in such text formats, even if you managed to retain "readability". But on the other hand ... to get the diagram solutions into a visual format I like I tend to lose the readability anyway. If you have several boxes with many connection - even reading the text becomes difficult. It is hard to keep the connections in your head once they get 2 or 3 hops deep. And you end up with 15 lines of connection spam, like "EntityA -> EntityB", "EntityC -> EntityB", "EntityA -> EntityD". And you end up trying to manage hierarchical relationships, fussing over what is the correct order to declare things, like manually doing your own dependency resolution. So maybe strict readability isn't really even a property I can expect to maintain. I really hope it gets solved one day.