I have always found "diagrams as code" tools to be limiting. There will be that scenario where the generated diagram is not what you expected. The flexibility you get by using code is outweighed by these limiting scenarios. I switched to Mermaid.js but ended up switching back to normal diagramming tools because of these limitations.
Our team uses diagrams-as-code (plantUML) to document processes, interactions, and state machines. Because our use case is functional, they don't have to look good - just good enough and understandable.
Some reasons on why we still use them: (1) They're source-control friendly. And (2) in some cases, we could generate them directly from code. We deal with a lot of state machines on embedded devices, and whenever management asks for "documentation", we run a transformer script that consumes the source code and spits out state diagrams that would placate them.
I think the point of those tools is to abandon the idea that one needs full say over every aspect of a diagram. Or even that all diagrams must be done in one tool - the most flexible one. Having more version-controlled documentation next to code is only a plus to me.
Right; there seem to be cross-cutting benefits and drawbacks for declarative text-based specification of diagrams vs direct manipulation. One research project exploring this tension is Sketch-n-Sketch https://ravichugh.github.io/sketch-n-sketch/ which tries to combine both together in a single system via bidirectional programming. We've been wanting to explore similar ideas more in Penrose, but it's definitely challenging.
Barring bidirectionality, another possibility could just be to make it easier to integrate Penrose into existing workflows; for instance, if you're writing a LaTeX document then it'd be nice to have a package for Penrose diagrams rather than having to switch back and forth between your LaTeX editing environment and the Penrose editor.
But then, let's say you make a Penrose diagram and you want to tweak it in Illustrator to make it look better, because as you mentioned, the text-based input modality of Penrose is limited. So we could try to make it smoother to export Penrose diagrams to put in Illustrator. You edit the diagram and add it to your LaTeX document. But now, you decide you want to make a tweak to the original diagram by modifying the Penrose source code. This obliterates any changes you made in Illustrator, so now you have to manually repeat the tweaks you already made.
I'm not really sure what the best solution is... it seems hard to have a good workflow story without either being entirely text-based, supporting bidirectionality, or forcing a lot of repetitive manual rework when edits are made.
I also find them limiting if I want to diagram something from my brain. However I found them splendid for drawing logs, the internal state of my software, or other data. Sometimes it's great to just printf() stuff in a format that can be drawn.
Same here. My problem is that I consider these diagrams to be low value documentation gimmick. They are nice but not really worth spending a lot of time on.
The promise of text driven diagrams is that you don't spend a lot of time on them. Which is nice. But of course then you run in a brick wall when it's not that nice to look at and you want to fix it and it turns out that there are a lot of things that you just can't do with them.
And of course the real problem is that if it's simple, it probably doesn't need a diagram at all (or it will just state the bleeding obvious). And if it's not simple, the diagram is probably going to be a PITA to get right no matter what tool you use. Especially if you are not sure what the diagram is going to be exactly. These tools are almost universally horrible for sketching stuff out quickly because you get sucked into doing a depth first let's specify everything and the kitchen sink mode. And then you get it wrong and it's a pain to change everything. My brain just works a couple of orders of magnitude faster than most of these tools and I get frustrated with just spending ages on the stuff I already understand (i.e. the stuff that I already know the design for) vs. the stuff I'm still unsure about (i.e. the hard to diagram stuff). As a design tool these are horrible tools. As a documentation tool they are mostly redundant.
I default to just skip diagramming it entirely. I don't enjoy it. I don't believe in it. I usually have better things to do. I find the output is write only: nobody ever looks at it or appreciates it beyond a "ah cool, we have stuff". I've found extremely few counter examples in my decades long career of diagrams that actually add value and are widely appreciated. It's mostly just endless nonsense of trivial amounts of boxes and arrows connected in mostly unsurprising and obvious ways.
If I need something quick and dirty, whiteboards are much nicer. And you can just take a photo and call it a day. And in my experience, nobody ever looks at those either. Those photos have very little value. You draw something on a whiteboard, you use it as a talking point, and then you wipe the whiteboard. Photo optional. Do it if it makes you feel good. You could spend a lot of time translating those into a pretty diagrams. But that sounds like the kind of monkey work that somebody should automate and that you shouldn't be spending time on.
Mermaid.js is pretty great, but I agree you usually get to something that doesn't express nicely. I was hoping to find a graph language I might be able to tweak into a DSL. Mermaid is easy to onboard and get things done with but then it didn't quite cover what I wanted to achieve.
