4 ms·

Not being intuitive isn’t the strongest argument against specialized notation. Programming languages aren’t intuitive either, yet we learned them. The rationale

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.

roenxi 4y ago
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.
- criddell 4y ago
  > I think we need a slightly more specialised word than 'intuitive' and we don't have it. Idiomatic is close.
zozbot234 4y ago
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).
- codeflo 4y ago
  > 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.
- the_af 4y ago
  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.
opk 4y ago
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.
SkyBelow 4y ago
>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.
- marcosdumay 4y ago
  > 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.
dwaite 4y ago
> 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?

roenxi 4y ago

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.

criddell 4y ago
> I think we need a slightly more specialised word than 'intuitive' and we don't have it. Idiomatic is close.

zozbot234 4y ago

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

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

opk 4y ago

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.

SkyBelow 4y ago

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

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

dwaite 4y ago

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