3 ms·

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

by lisper 4y ago

> 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.

another2another 4y ago
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 :-)
- lisper 4y ago
  > 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.)
  - zmgsabst 4y ago
    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.
    - lisper 4y ago
      "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.)
      - rini17 4y ago
        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.)
        lisper 4y ago
        > 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.
        rini17 4y ago
        Why not? Feeding it to graphviz is one of the viable avenues of attack.
        lisper 4y ago
        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.
        rini17 4y ago
        Electrical circuits were mentioned and yes they are usually designed by drawing AFAIK, even with over 1000 nodes. What's the argument here?
        lisper 4y ago
        > they are usually designed by drawing AFAIK I work at Intel, so I can tell you with some authority that you are mistaken.
mechanical_bear 4y ago
This is not a pure defense of UML, but text is not perfectly adequate. Visualizations do wonders for understanding that text can’t touch.
- counttheforks 4y ago
  This is why PlantUML is great. It is both text and a visualization. https://plantuml.com/ https://plantuml.com/
captaincaveman 4y ago
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.
- somat 4y ago
  and yet grafviz does it just fine. netlists do a perfectly fine job of describing graphs
jimbobimbo 4y ago
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.
- Rayhem 4y ago
  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.

by lisper 4y ago

another2another 4y ago

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 :-)

lisper 4y ago
> 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.)
- zmgsabst 4y ago
  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.
  - lisper 4y ago
    "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.)
    - rini17 4y ago
      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.)
      - lisper 4y ago
        > 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.
        rini17 4y ago
        Why not? Feeding it to graphviz is one of the viable avenues of attack.
        lisper 4y ago
        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.
        rini17 4y ago
        Electrical circuits were mentioned and yes they are usually designed by drawing AFAIK, even with over 1000 nodes. What's the argument here?
        lisper 4y ago
        > they are usually designed by drawing AFAIK I work at Intel, so I can tell you with some authority that you are mistaken.

mechanical_bear 4y ago

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

counttheforks 4y ago
This is why PlantUML is great. It is both text and a visualization. https://plantuml.com/ https://plantuml.com/

captaincaveman 4y ago

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.

somat 4y ago
and yet grafviz does it just fine. netlists do a perfectly fine job of describing graphs

jimbobimbo 4y ago

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.

Rayhem 4y ago
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.