[almostgotcaught]

> In practice diagrams are produced by folks who might not want to use or learn python [or golang, their other implementation]. Instead a lean purpose-build DSL, maybe even an extension of graphviz dot, is easier and more portable for some audiences to pick up

This is so absolutely ludicrously absurdly wrong that it's comical.

No one wants to learn a new programming language. Cf. all of the old algol languages that are still around and all their "replacements" that are no longer around.

Some people (not even a majority) are willing to learn a new language if compelled by force or incentive. Diagramming is absolutely not enough incentive to learn a new language.

[cheeze]

I agree with both of you, but I still don't want to use Python to generate my diagrams.

Diagrams are a visual thing. I prefer a visual designer. I can send that to some random nontechnical person for a presentation and they can edit them, etc.

I find with things like this, it works pretty well until you want to do something off the beaten path, then it's a pain where you're trying to figure out how to get it to render like you want it to.

Reminds me of the ole "just move it 2px to the right" in the CSS of yesteryear

[irjustin]

> This is so absolutely ludicrously absurdly wrong that it's comical.

Quite the hyperbole, but I do agree that python isn't so wrong of a choice, but the problem is diagrams eventually interact with non-technical people and that's where it gets tricky.

I LOVE mermaid, d2, but at somepoint I hand the diagrams off to someone who knows nothing about markdown and honestly they shouldn't have to know it to interact with a diagram.

All these "diagrams as code" are great for an isolated group. I can pump them out WAY faster than manual drawing programs (draw.io, etc), but then run into the iterop wall w/ other teams.

I'd LOVE a place that could be like AWS's graphical editor that sort of goes in between the two. It's a hard problem I 100% agree and would require yet another DSL, ugh.

[baq]

I upvoted you for the hyperbole but absolutely don't agree.

People who don't want to learn a new special purpose language are basically saying that 'I've got a hammer and everything is a nail' is fine, which is (to your point) absurd. Languages are tools, use tools to solve problems the tools were designed to solve.

Where I do agree is what you haven't said clearly: it isn't obvious what problems 'diagrams as code' solve. The idea is cool and I've used plantuml with some success, but in the end the diagram is supposed to be consumed visually (including changes - to preserve spatial relationships between versions).

[v3ss0n]

I love python and I found diagrams fine but after tried for a few time , it comes down to me that diagrams as code only good for diagrams that are already sketched out on how it would look like in design tools like draw.io . Diagrams need a Visual editor. Designing using code is very hard to visualize how it will look like by just looking at code and running , editing , looking back is not fun. Since code provides easy versioning and search and replace , refactoring is easy , what we need is visual editor that generates code and so we can keep that code versioned in github.