Lambda the Ultimate

What is your experience - do you think of UML in terms of algebras (and when defining operations, probably coalgebras?)? Or do you ignore it? It's really interesting cognitive problem for me, as I came from the opposite direction, thinking of categories in terms of UML classes :-)

It cannot be the case that processing graphs is easier than processing trees since every tree is a graph but not vice versa, so there are more possibilities to cover.

do you think of UML in terms of algebras (and when defining operations, probably coalgebras?)?

I try not to think of UML.

It's really interesting cognitive problem for me

Uh oh... :)

do you think of UML in terms of algebras (and when defining operations, probably coalgebras?)?

I try not to think of UML.

Moi aussi.

It cannot be the case that processing graphs is easier than processing trees since every tree is a graph but not vice versa, so there are more possibilities to cover.

If you define the same goals, then true.
But the very fact that you have a more specific structure 
with more invariants opens new possibilities for processing,
so not covering them will be a shame...
And covering them requires additional effort - that was my point.


For example, if XPath pretended you cannot universally access 
a parent (ancestor, siblings, following etc.),
it would be much simpler.

I try not to think of UML.

Moi aussi.

Excuse moi :-)
I hope it was not tabu to mention it...


Is UML hopelessly worthless?
Is it going the wrong way?
Or is it being pushed/dragged the wrong way?


IMHO, it's not UML as notation that is evil
(I use class diagrams frequently),
but over-estimating "silver-bulletness" of monstrous shemes.
I'm affraid it takes some efforts for people with imperative
background to dispel MDA PR of uber methodology -
I witness people falling prey to that daily...

"More methodology will save us, we just need to be more UML-compliant, and use design patterns everywhere" :-)

Do you think this is a coincidence?

(And no, UML is not taboo. My personal likes and dislikes are just that: personal).

The UML spec is huge now, and I have no idea what most of it contains, and so I cannot comment on it. But I can comment on the original idea for UML, which was to standardize an informal notation for inheritance diagrams.

Do I think that inheritance diagrams are worthless? No. Do I think that standardizing an informal notation is pointless? Yes. Do I think there are more useful ways of describing an OO system than with inheritance diagrams, use-case diagrams, interaction diagrams and whatnot? Yes.

I might as well add that I am largely opposed to standardization anyway. I support standardization of some ubiquitous low-level concepts (TCP/IP, floating point operations and Unicode are examples) but not high-level concepts unless they can be effectively formalized, as is the case with programming languages.

One reason for this is that I think the point of a standard is to fix arbitrary choices, and not to limit the design space. There are orders of magnitude more design choices with high-level concepts than with low-level ones, and consequently far fewer (and often zero) people who are qualified and knowledgeable enough to distinguish between design choices that merely fix some arbitrary representational issue, and design choices that really fix some aspect of the specification.

In cases where there is really not enough knowledge available to make that sort of distinction, I favor encoding a solution as a program (or white-box library) in some standardized (portable) programming language.

For example, I think things like CSS are lame: we just don't know enough about 2D drawing to characterize it effectively, so there are lots of limitations to CSS which you don't realize are there until you're halfway through a project. (For example, the order of displayed elements must match the order in the input document, and there is no fine control over relationships between font sizes, indentation and so on.) It's better, then, to encode CSS as a library in some portable language, since there you at least have an escape hatch if you need to overcome some limitation.

This is the reason I favor standardizing programming languages: they provide a provably complete solution to the problem they claim to solve, namely how to do computation. The same cannot be said for most high-level standards.

For example, the order of displayed elements must match the order in the input document...

div.firstpara {
   position: absolute;
   top: 0px;
   left: 0px;
}


div.secondpara {
   position: absolute;
   top: 300px;
   left: 0px;
}


[...]


<div class="secondpara">This is the first paragraph in the document</div>
<div class="firstpara">This is the second paragraph in the document</div>

Not that the above particularly detracts from the lameness of CSS. I don't know that XSL-FO is much better.

Hmmm, I wonder what a decent little declarative language for describing formatting, layout and presentation might look like...

I think a good idea is to use a constraint solver, like CSVG does.

there is no fine control over relationships between font sizes,

Maybe you like Constraint CSS.

Oops, I shouldn't have gone so far over-generalizing, is it a UML habit :-)