It most certainly is not.
This is clearly better than UML. UML is full of shorthands that nobody remembers. That's worse than people making labelled custom diagrams.
Here's an example:
https://buck2.build/docs/concepts/concept_map/
Imagine how much worse that would be with UML arrows.
I agree on the "shorthands", like empty/filled arrows, that people may not know. But there isn't much alternative to such shorthands other than leaving them out completely, which wouldn't be an advantage. In diagrams some information is either conveyed succinctly or not at all. The "alternative" is a block of text instead of a diagram.
> People who say "UML is useless" basically say "diagrams are useless".
Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag.
As said, the sequence diagram is a real plus because sequence information is not very well expressed by code, so that diagram has much added value.
I personnaly find UML hard to use becaues if you want to communicate your ideas precisely, you have to know much of its formalism and most often, people who read your drawings don't master its intricacies, so communication quality is no good...
Code can be formal enough but in reality it is almost never formal enough. Many constraints can be expressed imperatively (eg. someone validates the number of related objects in the create view) and in unexpected places (across repositories and libraries and maybe not even in code but in some stored procedure). And then it is all in flux and can go away the moment you change your stack.
I don't know if UML is perfectly flexible (maybe?) but its sure benefit is a source of truth that does not depend on your implementation.
There a diagrams that are useful before coding, but most of them aren’t part of UML, which is a product of the simultaneous highwater of class-based-OOP-is-everything and pre-Agile industrial software development methodologies, and (except for some isolated bits) poorly fit to anything else.
I don't think this is right or a well founded opinion. The whole point of any diagram language, including UML, is to provide the means to describe software projects in different views, including class diagrams but also component and system diagrams.
What do you think is the whole point of a modeling language?
Sometimes motivations are misguided, and sometimes instances aren’t well fit for major motivations of their broader class.
You, and OP, failed to present a single argument supporting the thesis that modeling languages in general, and UML in particular, are "lunacy and a massive red flag."
> Sometimes motivations are misguided (...)
Not only did you failed to support anything in the original anti-diagram rant, now you also tried to support generalizations with hypothetical corner cases involving misuses, which is an absurd argument to make.
So not only do you have zero substance for show with regards to the original anti-UML rant, you also resort to using vague, unsubstantiated strawmen.
This is to be expected. Like many discussions involving technical aspects, generally detractors come from positions of opinionated ignorance.
I failed to support that thesis because I never endorsed it. Pointing out a flaw in a counterargument is not endorsing the argument it is deployed against.
Not building an entire system down to class level which is what it is all too often used for (in my experience exclusively by people who have never and cannot code).
It's inefficient, doesn't play well with Software Engineering (diff, version control etc..) and is a relic of the past.
Keep the classes in code, project that into a diagram for the few occasions that is actually needed, and stick to a simplified tool like C4 (https://c4model.com) for your architectural views. Sprinkle some sequence diagrams in too to help describe the key data flows (they're handy next to C4).
Why use C4 over UML? Because the vast majority of the audience don't even know what UML is. So keep it extremely simple and include a key / guide to any of the (few) shapes or colors you use so that it's completely self contained.
The vast majority of UML belongs to be put into the Indiana Jones storage facility along with other archaic ideas such as Function Points / Function Point Analysis.
That was never the point of modeling languages.
Your baseless assumption is even more absurd when you factor in the fact that modeling languages even express runtime behavior, componente, and packaging.
The main problem with these mindless attacks on modeling languages in general and UML in particular is that the bulk of their retractors clearly knows nothing nor has any direct contact with them, or how they are used in the real world. Their arguments are nothing more than poorly thought through strawmen. Your comment fits well.
> Why use C4 over UML?
See, this is a telltale sign you know nothing about what you're commenting on. Not only is C4 a modelling language like UML but it also covers the exact same responsibilities and features of UML. C4's main selling point is advocating for the representation multiple points of view, and UML is a standard specification to express all the points of view you see fit in a coherent and rational way. There is no C4 vs UML. They have both the exact same design goals and usecases.
Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the latter actions. And class diagrams let you learn the connection between class structures of OOP languages and database structures.
UML lets you visually learn the abstract higher level concepts without having to rely on irrelevant specifics of practical implementations, or just on dry theoretical text.