Hacker News Reader

Comment by lisper | Hacker News Reader

> The act of designing the components, objects and interactions allowed me the time to think out many design problems and unanticipated interactions

Sure. But you can do all that without UML. Text is perfectly adequate technology for planning ahead.

View on HN

Well, I can pick up a piece of paper with classes, or a sequence diagram and external systems, and then tell the story from many perspectives to another person.

"This depends on that, this calls that, and then calls that external system via this interface..." and so on.

With a only text I would find that much harder to communicate. That's why I find diagrams much better - you can just jump in at any point and explain things in any order you like, usually with the aid of a pointing finger :-)

> With a only text I would find that much harder to communicate.

And yet you just did it:

"This depends on that, this calls that, and then calls that external system via this interface..."

I really don't see the salient difference between

    this depends on that

and

    this <-- that

(Or is it this --> that? Or this --<> that? this --<>* that? I can never remember.)

In my experience, the difference comes when you have many relationships which are organized into higher order relationships (eg, subsystems).

English is linear in a way diagrams are not.

"Text" != "English". Text in general need not be linear, e.g.:

    System1
      sub-system1a
      sub-system1b
    System2
      sub-system2a
      sub-system2b

(This is the reason indentation in programming languages is a thing.)

But trees are trivially linarizable. What will you do when you need to describe a graph, when there's some direct relationships between sub-systems?

(Yes most programming languages use trees, it has some advantages. But most people program in excel anyway.)

> But trees are trivially linarizable. What will you do when you need to describe a graph, when there's some direct relationships between sub-systems?

Graphs are reducible to lists of nodes and edges which are very linearizable.

That may not be the most useful form for comprehension, but linear forms are quite good for writing and storing. Visual notation is useful for presentation here, but IME quality is much lower in drawn diagrams than rendered-from-linearly-authored-text diagrams, which explains why most of my diagramming is done in a text editor (e.g., in Markdown+Mermaid) with visual preview.

> What will you do when you need to describe a graph

What will you do when you need to describe a graph with (say) more than a thousand nodes? I hope you won't try to draw a picture of it.

Why not? Feeding it to graphviz is one of the viable avenues of attack.

And what exactly is the "it" that you "feed to graphviz"?

Creating a graphical rendering of data is not what I was referring to when I spoke of drawing a picture. What I meant was actually drawing, i.e. using MacDraw or PowerPoint or a pencil and paper and drawing. Because that is what people mostly do when they use UML.

Electrical circuits were mentioned and yes they are usually designed by drawing AFAIK, even with over 1000 nodes. What's the argument here?

> they are usually designed by drawing AFAIK

I work at Intel, so I can tell you with some authority that you are mistaken.

This is not a pure defense of UML, but text is not perfectly adequate. Visualizations do wonders for understanding that text can’t touch.

This is why PlantUML is great. It is both text and a visualization.

https://plantuml.com/

The problem with text is that it takes a lot of writing to describe complex interactions and the reader checks out somewhere in the first quarter of your prose.

Diagrams are more efficient to drive the point home.

Readers check out with those, too. I've found that's largely because everyone has a slightly different perspective on what something means, ergo everyone's always talking slightly past everyone else and the discussion doesn't amount to anything. It takes a very skilled learner to say "I'm shelving my idea so I can understand yours." And it takes a very skilled teacher to simulate a learner's brain with their own. Diagrams don't solve this problem, in fact, no tool does.

Text is okay, but describing a graph is difficult and not as intuitive as a diagram. This doesn't mean UML is needed for the diagram, however the alternative is a semantically weak ad hoc diagram, and I'm not a fan of UML even though have plenty of experience, I agree that UML basically had good intentions for a real problem, poorly executed.

and yet grafviz does it just fine.

netlists do a perfectly fine job of describing graphs

Reply on news.ycombinator.com