-13 karma · joined March 28, 2024
And now assholes are intentionally taking alcohol through the self-checkout, deliberately taking up that one employee's time making him or her perform the workaround to check the items out.
And the 20+ years of "unexpected item in the bagging area" bullshit... just get rid of it.
What's sad is putting cashiers out of work, and even worse is replacing them with outrageously piss-poor alternatives. Self-checkout is a clinic on incompetent system design, and has been for DECADES now. It's mind-bogglingly bad, all to take jobs away from people. Fuck that.
Reminds me that one of the single biggest regressions in GUIs over the last couple of decades is: The knowledge of how to make a proper tabbed dialog has been lost to many.
I also can't find any similar strings in any of the samples in the drop-down list.
They actually did have a way to invert the whole UI... but it also inverted photo images on the screen. poundAppleAttentionToDetail
"back when you could configure stuff and have it not break early the following week"
Exactly, but this was true on every GUI EXCEPT the vaunted Mac. For what, two decades, you could set up your own system-wide color scheme under Windows, which would be inherited by all competent apps. I set up a nice, non-inverse (today's trendy "dark") scheme in 1991 and used it into the 2000s. Then, just before everyone finally realized that staring at black text on a glaring white screen all day sucks... Microsoft removed the scheme editor from Windows entirely.
The Windows shitshow has only gotten more rank from there. Not knowledgable enough to weigh in on Linux and Unix GUIs.
Does TypeSpec have description fields? I don't think I've seen any in the examples.
Example: If you define a structure called Rectangle and use it all over the place, you can't say what this rectangle means or that rectangle means when the structure is used in your API. How was that ever deemed acceptable? Widespread use of common structures (which one would certainly expect in a well-designed API) resulted in an API that couldn't be documented in OAS.
The OpenAPI code-generation landscape is truly abysmal. Not only do almost none of the tools support version 3.1 (which has been current for years), but the generators themselves are of widely varying (but mostly shitty) quality and scattered across a couple of apparent major repos. The documentation is likewise a confusing morass of conflicting and incomplete information from several sources. I flailed away trying to fix one generator for weeks, or write a new one. But I couldn't even find a concise list of the data structures offered to the template engine after an OpenAPI doc is ingested by OpenAPIGenerator. Isn't that a fundamental part of creating a new generator?
So it raises the question of whether OpenAPI is salvageable, or whether this new DSL is better... from design to code generation. Given the trashy state of OpenAPI code generators, why bother generating OAS at all? Just move on and write some competent generators using this new language.