Hacker News Reader

Comment by captainmuon | Hacker News Reader

My issues with UML:

It's too bound up with OOP, specifically C++ and Java. It is hard to represent entities that are not simple classes.

Things that are idiomatic (in 90s C++, cough) look very verbose. If you have a base class, a derived class, and an interface you have a lot of duplication. It makes things like polymorphism look needlessly complicated.

And finally, it is ugly and unintuitive. The inheritance arrow goes the wrong way. I know it is supposed to say "derived IS SUBCLASS OF base" and thus goes upwards, but in my mental model it is "you start with base, and then go to derived (get more specific)" so it should point down.

View on HN

Not being intuitive isn’t the strongest argument against specialized notation. Programming languages aren’t intuitive either, yet we learned them. The rationale is that the arrow goes into the direction the #include or import would go. So it shows logical dependencies — both caller and implementer depend on the interface — and you can quickly see if there’s a dependency in the wrong direction somewhere.

I fully agree with UML being stuck in OO land, though, and I think that’s the actual problem. Lambdas don’t exist, or have to be verbosely represented as interfaces. Type-level programming doesn’t exist. Anything higher order is unrepresentable to begin with. You don’t have to use Haskell to run into those limits, modern C++ is enough, or Kotlin, or TypeScript. UML is basically useless if you’re doing anything more interesting than cranking out Java 1.4 era EJB boilerplate.

I think we need a slightly more specialised word than 'intuitive' and we don't have it. Something that has the flavour of ">80% of experts use one of [set] mental models, and this thing doesn't capture the essence of any of them".

That is a high bar, I'm not sure if UML meets it (wouldn't know, don't use UML, not intuitive enough for me). But I think something like SQL's syntax meets it - nobody would design a language with that syntax in this day and age, experts have settled on not using garbled pseudo-English. The experts who think "VERB GLYPH ADPOSITION symbol" (ie, SELECT * FROM table) is the simplest way to represent relational algebra just don't exist. Anyone competent would use some other grammar.

> I think we need a slightly more specialised word than 'intuitive' and we don't have it.

Idiomatic is close.

Doesn't UML have metaclasses, that could be used for type-level stuff? First-class functions should probably be represented via the Command pattern, which is ultimately a kind of defunctionalization (i.e. it's what high-level functions get compiled down to in actual code).

> i.e. it's what high-level functions get compiled down to in actual code

Yes, the Command pattern is what I vaguely alluded to in my message. The thing is, using a lower-level representation in something that’s meant to be an abstraction of the actual code makes zero sense to me.

I wonder, if you spend so much time writing fine-grained UML, aren't you already sort of programming? If so, wouldn't that time be better spent with an actual programming language with all the ergonomics and features you need?

It seems to me UML shouldn't be dealing with this fine-grained level of detail. It seems like a wasteful effort. Either design high-level, or get down to actual programming.

Even with Java 1.4 the obvious mapping of class diagrams to data structures made for terrible data structures. You end up with an interconnected maze of objects that is totally inefficient for the algorithms. The mess typically included redundant, bidirectional and cyclic links between objects and where an object's only purpose is to be a list of another type of object, someone ends up writing a more limited wrapper around std::list/Collection/whatever.

Managers were overly fond of the class diagrams because they could understand them. And dividing work between programmers by class rather than by logical feature somehow made sense to them. I recall one manager spending way too much time arranging to print a huge UML diagram across multiple sheets of A4, taping it to the wall and then annotating it constantly by hand.

But knowing it can still be useful for simple sketches. Similarly dynamic dispatch is a really useful tool for particular cases when programming – used alongside other non-OO techniques. Our industry follows fads and fashions to an amazing extent but when things fall out of favour the baby goes out with the bathwater.

>Programming languages aren’t intuitive either, yet we learned them.

While saying "it isn't intuitive" is a bit of a simplification, I think there is something to the argument.

I wonder if that is the case. Many programming languages do seem intuitive in light of other programming languages and other formal notation like math. The ones that don't are the ones I struggle with more. If I'm reading a new language and I see an '=' I can assume either a comparison or assignment. If I see a '<', I can normally interpret it as less than. The more a language violates this, the less intuitive I consider it and the harder it is to read through it without familiarity. This even applies among non-intuitive paradigms. OOP isn't what I would consider intuitive out the box (but then is anything), but once you know two languages implementation of OOP you can measure a third language's implementation as being intuitive to the exist pattern or not.

My experience with UML is that it was wholly new. It was as intuitive as the first programming language a person would learn if they didn't know math notation, which given the rate new students to programming know math notation, is a level of unintuitive that even most programming languages wouldn't have even as a first time language. Add in that many are introduced it alongside OOP in general (at least that was my experience in college) and it is even less intuitive than that.

So to that extent, I think I can criticize it as being non-intuitive even with the comparison to programming languages.

> OOP isn't what I would consider intuitive out the box

Paradigms aren't supposed to be intuitive.

Anyway, "intuitive once you grasp the fundamental ideas" is normally called "idiomatic" in informatics. I will second the other comment on this thread pushing that term.

Absolutely nothing about computers is intuitive. The entire area of knowledge is composed of fundamental paradigms and their extensions. Those can be "simple" or "idiomatic", but intuition doesn't go anywhere near them.

> I fully agree with UML being stuck in OO land, though, and I think that’s the actual problem. Lambdas don’t exist, or have to be verbosely represented as interfaces

From a code generation standpoint (e.g. cracking out EJB boilerplate), the concept of model-driven architecture is generally a flawed idea. Lack of lambda expressions isn't that significant in the face of ignoring the complexities of real systems.

I'm curious about the issues you've hit representing higher order types though - was this in a class-style diagram?

IMO the arrows point to the right direction, in a sense that in my mental model arrows are typically owned by the pointer, not the pointee. The pointees are typically unaware of what points to them. A base class "doesn't know" what its derived classes are. Likewise a git commit doesn't know it's descendants either.

So in my mental model a derived class actively "points to" its base class. Likewise a child commit points to its parent/parents.

> A base class "doesn't know" what its derived classes are.

There's a high variability in that, especially when metaclasses get involved and inheritance is itself a protocol (and thus can be hooked into every which way).

I do agree with the rest of your comment though, to me it also makes a lot more sense for a derived class to point to its parent than the reverse.

"derived class actively "points to" its base class"

That make sense - pretty much every language I've used that supports inheritance class definitions refer to the class (or classes) they extend rather than the other way about.

I like it ...

class Vehicle extendedBy Car, Truck

class Car

class Truck extendedBy Semi

class Semi

This would be almost as awesome as "comefrom"[1]

[1] https://en.wikipedia.org/wiki/COMEFROM

Looks like sealed classes in Java https://www.baeldung.com/java-sealed-classes-interfaces

You could use a generic Vehicle<T: VehicleType>, with Vehicle<Car>, Vehicle<Truck>, Vehicle<Semi> implementing specialized interfaces.

A "this is not intuitive" argument can be made about every formalised system and is not interesting: It will always be true for someone, no matter what you do. Get used to it being otherwise, then it will not bother you anymore.

When it is a visual notation and the main purpose is that it is supposed to aid you in thinking, then I think being "intuitive" is one of the most important features.

I want to see a graphical representation of my "business" entities, not a more verbose 2D representation of my source code.

Similarly "readability". "Everything is hard to read until you learn to read it." -- Rich Hickey

Yes I agree. My two cents: try CRC Cards, which are a simpler abstraction and give most of what is needed.

I hadn't heard of CRC Cards before, but after a google search, I'm realizing that I've definitely written something similar while whiteboarding an idea. Thanks for the tip.

Yeah, but then don't use UML. It's a Philips screwdriver in a world that doesn't only have Philips screws.

If it helps, use the term "superclass" instead of "base". Then it makes a little more sense to have it at the top.

I tend to use parent and child classes. UML follows the family tree notation in that case.

So you have an issue with class diagrams, not UML.

Why is making the distinction important here?

Not GP but probably because of all the other UML diagram types, which are not bound to OOP at all.

Because class diagrams are not even 10% of UML, and they are the most useless part of UML.

They, however, a) were pretty much the only actual UML's innovation: other things like sequence diagram have existed long before; b) had most emphasis put on them.

I'd say it's getting a wide audience agree on a common method of notation. I have a Java book from 1999-2000 which uses OMT (all right, OMT's object diagrams) as its main representation. Not too far off from UML class diagrams, as it is also considered a historical predecessor, but still enough to make me consult the legend time to time.

Sequence diagrams are not particularly helpful with JavaScript and alike and agree with parent OP that its too strictly tied to C++/Java. They are just not intuitive with async/await and function composition. Yes, one can always do "mental translation" to translate those into the diagram and vice versa, but just not helpful. Now one would argue that you model "more abstract processes" with them, but there are better modelling languages for business and network processes.

If I were reviewing a system design, yes, with js, I'd still like a sequence diagram. I'd just indicate that ordering may not be exact between certain bands of requests. I model concurrent systems all the time in sequence (ish) diagrams.

I want to know that action X will trigger N calls and those calls call service foo and bar, and that foo then calls out to its data store and eventually returns something and service bar calls services raz and quux and those each fist call a caching service before going to their data stores. All requests eventually return (in the happy path). Now, as a reviewer, I can quickly see what talks to what and why that call happens and I can ask more intelligent questions like what happens if a cache hit happens when the data store has been updated.

What do you prefer?

Sequence diagrams are particularly useful for protocols, and not so for code in any language.

The fact that UML formalized them as a way to describe code tells you a lot about the standard's quality.

Well, I take issue with most formalized diagrams that represent code elements, rather than "business" entities. It leads to a kind of thinking that is wrong IMO, where you mechanically represent every business object by a class, say Customer and Employee.

I tend to think of OOP as a way to rewrite 'if's now. When you have the same huge 'if' or 'switch' in a couple of places, you can usually rewrite it to use polymorphism, and it becomes clearer. But it is totally fine to use procedural or functional idioms most of the time.

I don't know the whole breadth of the actual standard UML, and I don't know anybody who does. When I say UML, I mean as practiced and not as written, and that means: Boxes for classes, methods below, various kinds of arrows that I have to look up. For sure there are good parts in the standard, but that is not really relevant here.

As the sibling comment says, sequence diagrams are usually more useful. Or state machine diagrams. Or a diagram showing data dependencies.

Then you are not complaining about UML, but about the old school bad OO designs that UML is meant to support (along with old school good OO designs).

Without UML, such designs would be worse because they would be less documented: if you have a relatively concise class diagram in front of you it's easier to ponder about what each of the arrows and boxes means.

Excellent summary.

Reply on news.ycombinator.com