[Geminidog]

The way I took it is that you said your original statement in a broader context along the lines of "in computer science form and function should never be separated." And you used that statement to apply it to UI/UX and architecture.

This statement is patently false, especially for UI/UX. Even at the lowest level there are platform agnostic API's (opengl) that are divorced from CPU/computer architecture. At even higher levels, javascript/css/html is a graphics API that is divorced from even the operating system. Separation of form and function is the foundation of software. It cannot be a "fools errand" when all of UI/UX is designed with the separation of form and function in mind.

It is therefore fundamentally impossible for you to stand by a notion that is completely false. More than likely your statement is just a mistake and you didn't think it through. Such is one of the downfalls of "Architects"... they are so concerned with high level truthisms that they fail to even build the correct high level picture of the computing world.

For software systems, the devil is, unfortunately, in the details.

[taeric]

You still seem to be taking a very non charitable read. I aluded to the browser, specifically because of the hard split between content markup and stylistic markup that is of very arguable benefits.

It is alluring. And when it works, it feels magical. Yet I still prefer TeX over many of the document systems I have been subjected to use. Markdown being a strong modern contender that embraced the ascii art nature of plain text files. Throw in the modern resurgence of jsx and the hard won separation of scripting from content is not even fought anymore.

To the ui/ux point, directly, I'm not even sure what you are arguing. The APIs that you list are all notorious for being bad leaking abstractions. And is why people make products over them, introducing new forms and functions for a different set of users. Just look at how you shoe horn shaders into those low level APIs.

But again, in the context of this story, I meant that you can't separate out the ui/ux concerns of a product completely from who owns that product. So, for AWS, they own both service and console. If one is bad, it is almost certainly from lack of prioritization in the team that owns the whole product. Often behind the guise of "this is not the architecture's concerns, but the front end."

Jumping to another metaphor to try and say it differently. In a bike, you can separate the drive train from the steering, but it will be a largely perspective based separation. Such that the entire bike is ultimately part of the steering and the power distribution. Yes, this is a simplistic look at it, but no more so than thinking you can fully isolate one from the other.

(Now, I do have to confess that Tufte is finally really resonating with me. And I fully agree that much of this is as useful as so many platitudes. Ask me about front end versus back end, someday. :) )

[Geminidog]

> To the ui/ux point, directly, I'm not even sure what you are arguing.

Yeah I can see that given how off the point you are in your posts. Your initial response is that the separation of form and function is a mistake.

I’m saying it’s not a mistake, separating form and function via abstraction is intrinsic to the industry and I use UI/UX as an example. Your retort is that UI/UX abstractions are notoriously leaky.

How does a leaky abstraction move the conversation in any direction? Most abstractions are leaky, everyone know this, but despite this we still need to program our computers via a high level language designed to separate form from function. Otherwise everyone would use assembly language. The leaky ness is known but to manage complexity we have to separate form and function.

So your statement is completely and utterly wrong. Your responses fail to prove your point and go off topic into unrelated metaphors, tufte and Tex. Stay on topic.