UML: The Positive Spin (1997) | Hacker News Reader

UML: The Positive Spin (1997)

archive.eiffel.com

32 pointsTomte15 comments

> How could I criticize the method for not helping software developers or managers, when it does not care about software development at all, but only about developing a market for consultants and trainers?

That summarizes much of UML. Sequence diagrams are useful, though.

UML helps me think clearly. Specifically sequence diagrams, ERDs and flow charts

When it comes to ERDs I find UML notation unhelpful. I find the IE (information Engineering) notation that uses clear symbols for both cardinality (simple line or crow foot) and optionality (O or I) a lot more usable.

For anyone that missed the disclaimer at the top:

This is satire and not a genuine letter from the past by some disgruntled college student (to be honest, I wasn't sure until I saw the notice)

Do you write this kind of satire if you’re gruntled?

I can see high-school me writing something like this, to be honest. If I had a bone to pick, I would go over the top to make a point

UML and OO is waste of time and money.

OOP looked really neat at the times when computers had one CPU, very little RAM, and no easy in-process concurrency.

OOP made a few genuinely good things popular in the common software practice: modules, public vs private interface separation, the idea of interfaces. Other features, like inheritance, or encapsulated mutable state, proved to be more problematic, both in general, and in the modern computing environment in particular.

There is some connection to object-oriented programming and desktop GUI paradigms, that I remember were written about in computer magazines at the time, but is never mentioned now. Like, if you want to delete this document, you drag it to the trashcan! Object oriented! Am I right or do I remember it wrong?

Not clear to me how that's object-oriented. You're not sending a "put yourself in the trashcan" message to the document, or sending a "pull the document to yourself" message to the trashcan. If anything, you're invoking the environment's "drag" function with two arguments, "document" and "trashcan"; that's object-oriented only insofar as the environment contains every function and can be sent messages to invoke them.

To continue the over-analysis in good faith: I think the trashcan example points out the inheritance of draggability. Any file object in a directory gets it by default, without having to think too much about it.

Then the trashcan inherits from a directory, making it able to have things dropped on it. But it overwrites the action taken from movement to deletion. That maps "nicely" onto the human mind.

> If anything, you're invoking the environment's "drag" function with two arguments, "document" and "trashcan";

A perfectly valid alternative description. But having a do-it-all environment with every function doesn't sound OOP to me.

I remember that OS/2 user interface was said to be object-oriented and Wikipedia says the same

https://en.wikipedia.org/wiki/Workplace_Shell

That would be skeuomorphism, not object-orientation. One is about UIs, the other is about programming paradigms.

The OS/2 Workplace Shell is described as object-oriented

https://en.wikipedia.org/wiki/Workplace_Shell

UML, at the time, was exceedingly useful if you just used the whiteboard version of it. Being able to clearly communicate with another developer by drawing a class diagram and having each line, box, and cardinality mean something precise was very helpful.

UML as a programming language was awful. UML as a specification language was often even worse.

Reply on news.ycombinator.com