Hacker News new | ask | show | jobs
by kiitos 1039 days ago
ASCII diagrams can easily be drawn and maintained directly. That's kind of the whole point! Generating them from some more primitive declaration language makes them harder to use, not easier. This kind of tool is frustrating.
2 comments

No; these diagrams are not drawn from a semantic declaration language. They are drawn from ASCII diagrams. They are just inferring a "skin" made of nicer-looking Unicode symbols.

The examples don't show the source code next to them, but you can just view the page source in your browser (e.g. Ctrl-U in Firefox).

So the purpose of the tool is to transform an ASCII diagram to a Unicode diagram? I struggle to understand the value of such a thing.

    +---+   +---+
    | A |-->| B |
    +---+   +---+
is actually better than

    ┌─┐ ┌─┐
    │A│→│B│
    └─┘ └─┘
because it can be manipulated without external tools. Right?
Maintaining them by hand seems like a really excessive level of manual work. Most tools are basically raster drawing based, and raster graphics requires you to have a general layout of where things go in your head, or else spend a lot more time on the trial and error.
This has never been my experience. Any editor with multi-cursor support can easily be used to produce or maintain ASCII diagrams like the ones described so far.
I've never used multi-cursor, but it still seems harder than markup, or vector graphics. If you do anything complex, and you're not happy with your layout, you can't just drag the boxes around.

Seems like you'd kind of have to have a clear idea of where everything goes before you start to really work effectively. Or is that part of the appeal, practicing skills you normally would use as a coder?

The nice thing about ASCII diagrams is that they they naturally push back against complexity. That is, a diagram that's too complex to express in ASCII is (almost always) too complex in general. And the nice thing about doing ASCII diagrams manually in a (multi-cursor capable) editor is that this essential property is reinforced at the editing stage.

Definitely you should have a clear idea of your diagram before you arrive at your editor. If you want to experiment with layouts or whatever, you do that in a different tool, often pen-and-paper.

As you note, the same is true of programming! Experimentation is a totally different modality than writing a production-quality program. It's not a spectrum, you're either doing one or the other.

edit But, really, if you have a reasonable diagram in your head, it's really not difficult at all to express it as ASCII in a (multi-cursor capable) editor. I can do diagrams faster in VS Code than Monodraw, usually.

That's interesting that there's an actual reason!

I always thought they were kind of like the art you see on silicon chips, not really practical but accepted because trying to only do 100% practical things for a solid 8 hours isn't really the best plan, and only done by the programmers with a talent for raster art in general.

It does seem a bit time consuming unless you have a strong ability to visualize entire layouts. Being able to imagine 3 boxes is a lot different from being able to imagine 3 boxes on a screen all at once in proportion, and that's pretty far outside of what programmers ever are trained for unless you specifically seek out ways to learn that.

Using real pen and paper for diagrams is an interesting idea! Sometimes I see other coders with a notepad on their desk but I never got into it and am never quite sure what it's for, usually people seem to be making a lot of bullet points of text.

Yeah, diagramming with ASCII in a text editor is actually quite virtuous!

I wonder if it would be useful to publish a series of screen-capture videos demonstrating how to build these kind of diagrams. It's really not difficult!