[HN Gopher] Diagrams * Diagram as Code
___________________________________________________________________
Diagrams * Diagram as Code
Author : ulrischa
Score : 91 points
Date : 2024-11-04 18:46 UTC (4 hours ago)
(HTM) web link (diagrams.mingrammer.com)
(TXT) w3m dump (diagrams.mingrammer.com)
| smoll wrote:
| nifty tool!
|
| > NOTE: It does not control any actual cloud resources nor does
| it generate cloud formation or terraform code.
|
| would be kinda cool if it could, though
| robertlagrant wrote:
| Yep. Or implemented an interface that let someone else build
| that.
| afandian wrote:
| Interesting decision to implement a DSL in a programming language
| when the output is a static data structure. Seems more complex
| than writing the structure directly as YML or JSON (or a custom
| language like Mermaid or DOT).
|
| I can see the point of DSLs where the output is used by other
| code (e.g. builder pattern, LINQ). But this seems like overhead
| compared with the alternative?
| Veuxdo wrote:
| I'm biased, but I think it's a bad decision. Programming
| languages are for writing, well, programs. Programs execute,
| accept input, have state, and all manner of other things that
| just don't apply to diagrams. Diagramming in a programming
| language is just weird.
| CactusOnFire wrote:
| My counterpoint would be: If you can write data
| visualizations with code, why not write diagrams too?
| Closi wrote:
| Why not write recipes in code too?
|
| Or a screenplay?
|
| (Because there are better formats for them)
| chuable wrote:
| How about music as code...Sonic-Pi would like to offer a
| counterpoint :)
|
| https://sonic-pi.net/
| Veuxdo wrote:
| You _can_ do it, certainly, but it is overkill. It also
| limits your potential editors to people who know Python and
| are willing to install it on their machine. In contrast to
| Python (or other programming languages), a language like
| YAML or JSON can be learned in minutes by just about
| anyone.
| bunderbunder wrote:
| This is a program that executes and produces an output. It
| also has state - every step of executing that DSL is creating
| and manipulating a piece of state that builds up a
| declarative description of what the final output should look
| like.
|
| The other thing you list, input, is optional. I write
| programs that don't take any input all the time. Monte Carlo
| simulation, for example. The entire demoscene is largely
| devoted to creating incredibly sophisticated programs that
| don't take any input. Postscript is a full, Turing-complete
| language whose primary purpose is to create programs that
| generally don't take any input
| cdchn wrote:
| I don't think its even a DSL, its just Python.
| wetmore wrote:
| It's an embedded DSL or "eDSL", see
| https://en.wikipedia.org/wiki/Domain-
| specific_language#Exter...
| Veuxdo wrote:
| > It will be saved as web_service.png on your working directory.
|
| Nice and simple, but unfortunately you lose all accessibility
| with a .png diagram. Specifically, they're impenetrable to screen
| readers.
| hmottestad wrote:
| Apple has gotten really good at text selection in images. I can
| take a screenshot of a webpage and then select the text in the
| screenshot, or I could take a photo of a sign and select the
| text in the sign.
|
| Do you know if there is anything similar for screen readers?
| bberenberg wrote:
| If you had to list the top 3 best formats for use cases like
| this, what would they be?
| aren55555 wrote:
| I personally have been using mermaid for sequence diagrams and
| flow charts: https://mermaid.js.org/
|
| DaC seems nicer for infra
| adsteel_ wrote:
| Mermaid is fantastic for diagramming architecture. A little
| quirky, but not too bad.
|
| If you're using GitHub it's supported in any markdown file, and
| therefore accessible to any other dev with repo access. No
| permissions issues, edits can go through code review, and no
| dependencies necessary.
| cybrox wrote:
| Same with GitLab. I really appreciate the builtin Mermaid
| support.
| nshkrdotcom wrote:
| Mermaid is great, but is quirky.
|
| LLM's are well-trained on Mermaid. Gemini specifically is
| fantastic as a 'diagram assistant'. I was able to create this
| diagram and a ton of other such diagrams quite easily with
| Gemini and Mermaid's live editor:
| https://nshkr.com/SecureSphere-Overview-20241102.png
| rpncreator wrote:
| I'm leaning on both Mermaid JS and PlantUML as my daily drivers
| for diagrams.
| rafamvc wrote:
| For databases, DBML is my preferred choice. I wish there was a
| javascript ui viewer that is not owned by company.
|
| https://dbml.dbdiagram.io/
| tbiehn wrote:
| This project (and others like it) are graphviz wrappers - they do
| some really cool stuff to emit styled .dot files that look better
| than writing and rendering raw gv.#
|
| Allowing specification in Python offers very little advantage -
| in theory you think, hey, I've got hi-lighting, autocompletion,
| and so on from an IDE. It'll play nice in VCS. Maybe I can
| interrogate orchestration layers and so on to produce dynamic
| views.
|
| 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. Secondly, we can't JUST graft a DSL front-end onto these
| tools because the styled components are baked into the project.
|
| My personal experience with layout engines is that they work OK
| for very small architecture diagrams, but become ugly or
| inelegant at useful scales.
|
| I (and the teams I've worked with) settle on draw.io, either the
| desktop app, or committed as part of confluence, as the best way
| to describe intent/design - and rendering graphviz with a style
| up top for anything dynamic.
|
| Would welcome seeing a true extension to the dot language that
| can unlock reasoning engines (like to do threat modeling) and
| render-time styling.
| almostgotcaught wrote:
| > 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.
| darau1 wrote:
| I have a love/hate relationship with diagrams, and diagrams-as-
| code-things (plantuml, mermaid, etc). As a programmer, I find
| myself trying to turn everything in to a software project:
| everything must be version control-able. Same with these
| diagramming solutions -- except I nearly never know what I want
| the digram to look like, when I start "writing" it. This means
| I nearly always end up on something like lucid.app just
| sketching out the solution, and thinking to myself that I'll
| turn it in to a beautiful diagram with one of the earlier
| solutions, later -- that never happens. So now I have a diagram
| I can link to (yay), but can't version control (boo).
|
| Then, I discovered excalidraw[1]: it lets me sketch like lucid,
| but isn't nearly as polished or robust: you can throw together
| simple shapes, draw lines between them, and the lines stick to
| the shapes, so you can move them around and the lines move too.
| You can also group things together, and draw freehand, and also
| include text -- what more do you need?
|
| The cool thing about excalidraw is that you can share your
| drawings, and export them as SVG files -- yay! I can version
| them again. You can also self-host it, which is a massive plus
| in my book.
|
| /rant
|
| [1]: https://excalidraw.com/
| tbiehn wrote:
| Nice (and MIT Licensed!) - I'll give this a shot.
|
| Another thing these types of tools bring is multiplayer
| support. Which I found my distributed teams really benefiting
| from over time.
| cassianoleal wrote:
| I've been mostly using the VS Code Excalidraw plugin. Any
| file with name ending on `.excalidraw.svg` or
| `.excalidraw.png` is an Excalidraw-editable image of the
| respective format. This means you can save it alongside your
| markdown docs and embed them directly, but also edit the
| exact same file on the IDE.
| jimmcslim wrote:
| This looks great, and I am glad that there is a "Generic" set of
| nodes. I'm always a bit uncomfortable about architecture diagrams
| that lean too heavily into the names/icons of the specific cloud
| platforms that they use... i.e. describing WHICH AWS/Azure/GCP
| tech is being used rather than concern for WHAT or WHY those
| components are there for, which is much more important! It
| doesn't look like the edges between the nodes are labelled with
| any useful information either in this case.
| Veuxdo wrote:
| Yeah, just about every diagram you see online commits these
| sins. Probably because companies that create detailed diagrams
| don't make them public. What's left is mostly diagrams by tech
| companies (e.g. cloud providers) created specifically to
| promote the technologies themselves.
| russellbeattie wrote:
| _" Those that don't learn from UML are doomed to repeat it"_
| howard941 wrote:
| Rational Rhapsody enters the room
| stego-tech wrote:
| Oh _heck yes_ , this is absolutely my jam. I _loathe_ digging
| around in Visio /LucidChart/etc because I am an _absolute
| perfectionist_ with OCD-enhanced symmetry mandates, which is just
| a mouthy way of saying I spend way too much time obsessing over
| placement details and line thickness instead of just diagramming
| the dang architecture.
|
| Bonus points it's running via Python, which gives me a reason to
| fire it up and kill two birds with one stone (I'm a PowerShell
| junkie, so my relationship to Python thus far has been
| "reluctantly professional").
___________________________________________________________________
(page generated 2024-11-04 23:00 UTC)