How does this compare with graphviz, if I were to only create graph-node-like objects rather than tables and such?
graphviz can create tables and you can create arrows to specific table cells.
Nomnoml
141–150 of 165 posts
Re: Nomnoml
#142I have a hard time understanding why any engineering team I've ever worked on would use this. Can someone sell this idea to me? Seems like a waste of time when you can knock up fast and easier to understand diagrams with something like Miro which also can be done in a multi-user environment.
Three reasons: 1. I want changes to the diagram to be peer reviewable and understandable. 2. I want something else to manually lay out things, rather than have to adjust it personally on every addition or change. 3. I want a parsable structure I can feed into grafana or similar, so I can decorate the graph with metric data. It seems like it would be cool to have a graph of RPC calls and which links were red.
>I want a parsable structure I can feed into grafana or similar, so I can decorate the graph with metric data.
I don't think this can do it, but it would be cool if it could.
Maybe someone can make another diagramming DSL for the Grafana Node Panel.
Re: Nomnoml
#143Earlier quoted context omitted.
Three reasons: 1. I want changes to the diagram to be peer reviewable and understandable. 2. I want something else to manually lay out things, rather than have to adjust it personally on every addition or change. 3. I want a parsable structure I can feed into grafana or similar, so I can decorate the graph with metric data. It seems like it would be cool to have a graph of RPC calls and which links were red.
>I want a parsable structure I can feed into grafana or similar, so I can decorate the graph with metric data. I don't think this can do it, but it would be cool if it could. Maybe someone can make another diagramming DSL for the Grafana Node Panel.
Well, right now I have graphviz dot which should be enough to load in and transform as needed into whatever DSL desired.
Re: Nomnoml
#144This was very confusing, until I found the 'about' button. I guess I'm leading a charmed life, because I can not recognise UML on sight? (I thought at first this was describing a grammar of fake pirate language or something.)
The way to recognise UML is by the wide variety of arrow styles that nobody can remember. I'm 90% sure that's the main reason it didn't catch on.
You have to learn UML because of the stupid arrows. Compare it to something like this which acknowledges the fact that nobody is going to casually memorise 10 different styles of arrow just to read occasional UML diagrams:
https://buck2.build/docs/concepts/concept_map/
Much better.
Re: Nomnoml
#145Getting 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 ->[ e] [ start] -> [ plunder] -> [ more loot] -> [start] [Pirate| [foul mouth] mischief| bawl | sing || yell | drink ] [ Marauder] Jolly;Sailor] [sailor]->[rum] [Pirate]…
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, especia…
It seems like a situation that would benefit from separating the logical/structural definitions from the layout/presentation rules, much like HTML and CSS. The structural side would be clean and easy to maintain and all the fiddly presentation stuff would have space to be specific. Constraint-based layout rules a la flexbox would seem useful. Has anyone tried that approach?
Edit: You're probably still going to have to render it as part of the review for non-trivial changes but when the visual result matters I don't see any way to avoid that.
Re: Nomnoml
#146Re: Nomnoml
#147Getting 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 ->[ e] [ start] -> [ plunder] -> [ more loot] -> [start] [Pirate| [foul mouth] mischief| bawl | sing || yell | drink ] [ Marauder] Jolly;Sailor] [sailor]->[rum] [Pirate]…
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?
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.
Re: Nomnoml
#148Earlier quoted context omitted.
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, especia…
If you don't mind my asking, what aspects of "acceptable layout" is usually the first to get busted? Do the fonts overstrike? Does it shrink down so small the lines don't render? Is it just that all the boxes get thrashed in a blender and the diagram looks completely different? I'm extremely excited about using WireViz[1] to automate wiring harness diagram creation, and if I can, I'd like to know the speedbumps befor…
I have two main complaints that jump to the top of mind.
The first is lines and when they merge and when they cross. Not all lines from two separate boxes to a third box ought to merge, but some should. Crossing is inevitable in most complex diagrams but expressing where the crosses ought to happen is not something I have had any success with.
The second is that some diagrams are like a story, with a beginning a middle and an end. Using horizontal, vertical and even diagonal relationships visually can be important. Keeping that story clearly organized has always been a challenge and even requires some iteration when doing the drag-n-drop thing. Rarely does the story of the diagram just happen to pop out using the default placement algorithms of any text-to-diagram tool I have used. And so I find myself tediously massaging the order of statements or whatever crude controls I'm given to painstakingly move boxes into some semblance of the story. And then, once I've managed to convince the diagram to be as close as I can to what I envision, I realize I missed a key component or connection.
The last thing I'll point out is more a preference. In general, the output tends to be quite ugly to my eye. There are times I have been responsible for generating systems diagrams for potentially big deals. In those cases we want to put the best foot forward to external entities. There is something uncanny valley, or like generated text-to-speech in the appearance of the documents that can be undesirable in many contexts.
Re: Nomnoml
#149The language is very, very nice. However, if I ran into this incidentally (not posted to HN for review), I would never use this. I'd see the lack of a github link on the top right, and assume it's a some kind of startup making some prototype hosted tool. The only way to find out this is open-source is to click "about," read to the third paragraph, see github mentioned, click through the link, and click on the license…
> However, if I ran into this incidentally (not posted to HN for review), I would never use this. I'd see the lack of a github link on the top right, and assume it's a some kind of startup making some prototype hosted tool. Yeah, it's absolutely horrible when the GitHub link is in the bottom right rather than the top right. Completely unforgivable. Geez. Do (Free|Net|Open)BSD and GNU tools qualify as open source? No…
What's in the bottom right is still not the same. Plenty of projects use github issues for issue tracking without being open-source. This links to the github issues. It's still three clicks to find out it's open-source. In addition, the upside of following standard patterns is pretty well-established. Most of us are tuned to ignore pop-overs.
Ways I've seen this done:
- Clear github icon (visual cue)
- "Fork us on github" template
- Adding the words "open-source" somewhere (or even XXX-licensed). The "about" page could start "An open-source tool for drawing UML diagrams based on a simple syntax."
There's no reason to go over-the-top. Again, the reason people post things to HN is generally to generate visibility and to gain feedback. People don't write feedback to be mean but to help projects improve.
It's not "completely unforgivable" but I gave a bit of simple feedback which might reduce friction a bit and which would take a few minutes to implement. I appreciate similar feedback on my projects. In this case, for me (n=1), I've been derailed from adopting projects based on similar levels of friction. I will pull up a many things, prune them pretty quickly, and then do a deep dive into the most promising. I've always found user studies and friendly reviews helpful for avoiding these sorts of frictions in my own work.
Re: Nomnoml
#150Earlier quoted context omitted.
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, especia…
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://d2lang.com/
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.