What's wrong with describing some classes first with a UML diagram?

Nothing wrong, but code is already formal enough that you don't need a formal visual language (UML is not just a bunch of diagrams, it's a formal language). So yeah, a bit of drawing might help to understand, a few ideas from UML might help, but it's not like it is super necessary.

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 is already formal enough that you don't need a formal visual language

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.

The fact that it doesn’t provide any benefit or make things particularly simpler than describing them in code and projecting them to UML if you need a visual diagram. Also, the fact that it is particularly counterproductive if I’m not coding in a pure class-based OOP language, since it presupposes that the solution is centered on class-based OOP.

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.

> Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag.

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?

I think you are making the mistake of assuming that because something is an important motivation for a class of things, it must also be a good use for every instance of that class.

Sometimes motivations are misguided, and sometimes instances aren’t well fit for major motivations of their broader class.

> (...) it must also be a good use for every instance of that 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.

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

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.

> What do you think is the whole point of a modeling language?

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.

> Not building an entire system down to class level (...)

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.