For a brief, a very brief moment, between beige Windows 98 and glass-like Windows Vista, we had a "fun" Windows XP. Thinking back it's a bit ironic. For most of history the OS'es didn't look fun, but it was that colorful one I'm most fond of.
And yet XP was widely mocked and hated at the time. Usually as the "Fisher-Price" OS. Personally I never cared too much, it might have been garish in places but the interface under the skin was solid enough: it got out of the way and let me do what I needed to. Likewise for the successor Aero Glass: blingy maybe, but ultimately pretty darn functional (at least by Win7, I somehow managed to skip Vista nearly entirely).
Where I drew the line was Win8: it started to get really hard to actually accomplish tasks in the OS. Win10 walked that back a bit, enough to be tolerable, then Win11 went the other way. I set up a Win11 desktop last week for the first time: what an exercise in unnecessary pain. (And Windows Spotlight backgrounds, one of the few recent MS shove-down-your-throat features that I actually like, doesn't even work reliably and there's no way to find out why. Absolutely no way. Despite an OS with a comprehensive logging system!)
So it's really not correlated with the skin: it's about the functional bones of the UI. A gaming machine needs a functional UI. (Just like everything else!) But the skin on top of that can, and probably should, have some visual distinctiveness and flair. A spinning cube, though... perhaps that is just a little bit too twee?
Every time I open Google it shuffles the images/videos/shopping/maps tabs randomly. There is no UI research on the universe that would say this is a good thing. It has been happening for years.
Does anyone seriously want me to believe a company that thinks that that is a good idea can make AI work?
Google trends now has less features than it used to have. Search Console changes routinely, somehow never gets any actual new features. I think the funniest past was introducing an AI chatbot in Search Console that isn't able to answer most users' number 1 query: "how can I make my website get more clicks?"
I actually believe if you make an AI chatbot just to tell users how to use your app, you're admitting you have no idea how to make the app usable. If the app was intuitive, by definition, nobody would need a chatbot. If the documentation was easy to read, nobody would need a chatbot. If the search results actually worked, nobody would need AI overview (which, by the day, I feel has been becoming slower and slower to load every day)
On Whatsapp, I remember struggling to search for my contacts because where I expected a search box was replaced with Meta's AI text box. The funniest thing is that I remember someone who isn't good with computers telling me they asked the Whatsapp AI how to delete files in their smartphone that was full. Now this "AI" has probably become IT support for countless of its less tech savvy users, probably giving them completely wrong information sometimes.
All of this AI integration feels so offensive because every software you'll ever use always has a huge list of features that users would want and have wanted for years, and what is getting added first is some shoddy AI nobody asked for. People are seeing AI integration get top priority in spite of zero demand while their own issues with the software remain ignored. It's going to make people lose trust in software.
BigCo rushing to tack on some AI features to products without really thinking about it mostly just reflects their poor business and technical culture, not AI.
There's plenty of legitimate usecases for LLM integrations in business and consumer software. It's just not "take existing app and add generic AI button with vague usecases".
Completely absurd. If it's not safe for children just slap an age rating on it.
I don't like this trend of every technology assuming I'm a child that needs to be protected from the world while simultaneously assuming I'm an adult with infinite disposable income that must be shown ads to all the time. This is insincere. Children need to be "protected" only when it's convenient and allows the platform to exercise unchecked control. Nobody is protecting children from ads because that would be inconvenient.
To be clear, I'm not advocating for the behavior here, just explaining that, for most tech companies, the risk of liability is a huge motivator. Liability for poor use of ad targeting would induce similar behavior (and I think that'd be a win for everyone involved)
The worst thing is being corrected about minutiae. It's not a "property" it's an attribute/field/member/key/column/variable/getter/function/procedure. Deep down it's all variables. Even the constants are variables from the viewpoint of the CPU that has to load it in its registers.
Sometimes I see people saying "in LANG, obj.foo is just 'syntax sugar' for foo(obj)" and I think that technically it has always been "syntax sugar" and there have always been ways to call any "method" with any "object" of any "type."
Sometime along the way we decided that "syntax sugar" means "it means the same thing as" but except for (<cast OtherType>obj).foo(), which means that the semantics of "syntax sugar" don't mean it's simpler than the phrase it was supposed to replace.
> It's not a "property" it's an attribute/field/member/key/column/variable/getter/function/procedure.
For what it's worth, to a researcher in the field of programming languages (like the author of the post), these all have distinct unambiguous meanings. At least as far as PL goes, almost every term has a well-defined meaning, but as those terms were adopted into less-than-academic contexts, the meanings have diluted.
"Property" is such a term in the context of programming languages research, and, in particular, it is a very specifically defined term in the realm of property-based testing (no surprise).
> Even the constants are variables from the viewpoint of the CPU that has to load it in its registers.
No; this is not what "variable" means. Registers are properties of the processor, i.e., they are implementation details; variables are an abstract concept from the domain of the formal language specification.
> Sometime along the way we decided that "syntax sugar" means "it means the same thing as" but except for (<cast OtherType>obj).foo(), which means that the semantics of "syntax sugar" don't mean it's simpler than the phrase it was supposed to replace.
No; this is not what "syntax sugar" means. If a language defines some syntax f and it "expands to" some other syntax g, then f is syntax sugar for g. This is well defined in Felleisen's "On the Expressive Power of Programming Languages" [0]. For example, Python's addition operator `+` is implemented in terms of a method `__add__`; therefore, `a + b` is syntax sugar for `a.__add__(b)`, because the former syntax is built on top of the latter.
Notably, syntax sugar has nothing to do with casts; casts are semantic, not syntactic. There are also no promises about whether syntax sugar makes something "easier"; it's simply the ability to syntactically express something in multiple ways.
I'd also like to add that, since immediate-operand instructions exist, constants are absolutely not the same as variables at the machine level, since immediates will never be stored in a register (typically, e.g. "move immediate" will obviously store it in one, and I'm sure there are architectures that use an internal/hidden register that's populated during instruction decode).
Also, in Harvard-architecture systems, the constants, being part of the instruction itself, might not even be in the same memory or even address space as variables ([EEP]ROM/Flash vs RAM).
The problem is that the same word is used for different things.
The comment you are responding to was correct in what "property" means in some settings.
The article itself says:
> A property is a universally quantified computation that must hold for all possible inputs.
But, as you say,
> but as those terms were adopted into less-than-academic contexts, the meanings have diluted.
And, in fact, this meaning has been diluted. And is simply wrong from the perspective of what it originally meant in math.
You are right that a CPU register is a property of the CPU. But the mathematical term for what the article is discussing is invariant, not property.
Feel free to call invariants properties; idgaf. But don't shit all over somebody by claiming to have the intellectual high ground, because there's always a higher ground. And... you're not standing on it.
My point was not that there exists some supreme truth about what words mean and that either you use words "correctly" or you're an idiot.
Yes, words have different meanings in different settings, but that's not the dilution I was referring to. It's absolutely fine that a word can be used differently in different places.
The "problem", such as it is, is that there are people who use terms from programming languages research to discuss programming languages and they use these terms inaccurately for their context, leading to a dilution in common understanding. For example, there is a definitive difference between a "function" and a "method", and so it is inaccurate to refer to functions generally as "methods". However, I see people gripe about interactions where these things are treated separately, and that is what I am addressing.
The parent comment to mine tried to offer some examples of such terms within the context of programming languages, so my corrections were constrained to that context. But your correction of my point is, I think, incorrect, because the meaning you are trying to use against me is one from a different context than the one we're all talking about.
There's no intellectual high ground here; my point was not to elevate myself above the parent comment. My point was to explain to them that they were, from the point of view of people like the author of the post (I assume), simply incorrect. There's nothing wrong with being wrong from time to time.
I feel this article is more about all the tools they built with AI than about moving to Jekyll. None of these tools required the move in first place, since they could have literally just dumped the DB.
reply