I worked for nine years as a senior product manager, including a radical UX overhaul. I can speak to this.
There is a saying among PMs: when you're not sure what to do, you do a UX refresh.
(It's a bit like the same one for CEOs: if you're not sure what to do, drive an acquisition.)
UX rework needs to be done with real care -- not primarily care for looks, but care for function.
I _love_ Snow Leopard's UI. It was clear. Watching the videos on Liquid Glass, I was really hopeful we'd see a return to a similar design. Old OS X gave me joy, and I am sure I heard the word 'joy' used in the Liquid Glass video... and I was so happy! But what I see when I installed last night, and from this article, is glass and shadows in the background of windows, very low contrast ratios, and confusion between window areas.
Backgrounds are the wrong place for fancy effects. You need to be able to see foreground content clearly.
Foregound elements, like buttons, are great for fancy effects. They are small and isolated.
That's why pinstripes were awful (difficult background) and Aqua as a whole was great (blue gel buttons were clear.) Look at the comparison screenshots in this article: a list view in Finder, which is sorted, has a blue header on the sorted column. That is a fancy gel effect, but it is isolated and readable. If liquid glass were used the same way in Tahoe, we'd really be on to something. It's what I hoped for, and what I don't see.
However: one good thing in Tahoe is how fast UI elements interact. There is no animation on mouseover transition. It snaps in and out. This is excellent.
Last night, I started a small test project in Xcode to try to change how Tahoe controls render, swizzling. The idea is: use glass for foreground elements. Basically, use glass tech to drive a Snow Leopard-like UI.
Changing something like a checkbox is ok. Changing something like the side panel, or a set of toolbar buttons to resolve the background/floatiness/shadow issues in the article, is going to be hard (for me, with my level of AppKit and SwiftUI knowledge.) If I get far enough, I'll share with HN.
> Update to o4-mini (June 6, 2025)
> We are rolling back an o4-mini snapshot, that we deployed less than a week ago and intended to improve the length of model responses, because our automated monitoring tools detected an increase in content flags.
Does anyone know what it did or returned? I had not seen anything, nor have I read anything, about issues here.
Interesting idea. Your landing page goes straight to signup to try it, and I expect that's why no upvotes. It wasn't until I navigated to the main page I saw samples.
The two licenses are confusing, both have the same set of checkmarks. One seems to be for use, but that is not an absent/checkmark pair.
I saw varying quality in the generated shapes, but overall much better than I expected. I suggest you write some blogs about how it works, what fine-tuning you did, etc and submit those. Maybe you'll get more upvotes and visibility!
While I completely agree with you -- that's what I would want too, I want Win98 without the pain, click or type and it's there, it's a very 2025 expectation -- I laughed because of the huge disparity between this and what installing DOS and Windows were really like. Part of the experience is selecting drivers and configuration :D (Even better in DOS with the IRQs and config.sys and whatnot.)
PCem does it relatively pain free; also emulates voodoo 2 so you can play GPU accelerated games on it. The network is pig-slow and i haven't figured out why, though. All in all PCem is the exact amount of jank and awesome to use for retro-emulation.
it emulates ~8086 through Pentium II or so. maybe a bit further on both sides; my machine struggled to maintain 100% emulation speed with the highest end CPU selected.
oh, i've used that too, but i didn't know that - it's been a while.
This gives me the opportunity to test out my wiki install for note-taking in real time; set up 86box and do the same things i've been doing with pcem (clone the drives (copy/paste)), screenshots, the works. +1
Different boot disks and later different menu items in configsys and autoexecbat to control which drivers were loaded and where (himem etc) to launch different games
I don’t recall how it was all figured out int he days before modems. I remember dos came with a nice chunky set of manuals, I guess games might have had information in there too, but I for one don’t really understand the different between high and low in the first megabyte, or between extended and expanded memory, or what an Irq really was, I just knew you had to live the jumpers on the sound card - which I assume I got from the manual.
What was not immediately obvious to me (but should have been) is that these are dev-time type checkers -- I think. (I think, both from from the github descriptions which focus heavily on editing, and from the article.) That's really useful because type inference is lacking, to me, in-editor. I tend to ask Copilot: 'add type annotations'.
So in complement to this can I share my favorite _run-time_ type checker? Beartype: this reads your type annotations (ie I see this is where Pyrefly and Ty come in), and enforces the types at runtime. It is blazingly fast, as in, incredibly fast. I use it for all my deployed code.
beartype is great, but I only find it useful at the edges. Runtime checks aren't needed if you have strict typing throughout the project. On a gradually-typed codebase, you can use beartype (e.g. is_bearable) to ensure the data you're ingesting has the proper type. I usually use it when I'm dealing with JSON types.
Why isn’t it necessary? Do you mean that with edit-time type checking, you can catch all errors, so no need for runtime verification the edit-time type decls match?
If you have strict static type checking, type errors can't creep in, so you don't need runtime checking. pyright (type checker) will tell you when a runtime check is redundant. For example, if you already have `var` annotated (or inferred) as `str`, then `if isinstance(var, str)` is statically guaranteed to be true.
Of course, that's only if you trust all the types in your code. You still have escape hatches, such as Any and cast, that can break this guarantee. There are lints (from ruff) and pyright options to help with this. Concerning external libraries, I either use libraries that are 100% typed (which is common these days), or write my own type-safe wrappers around the others.
The IDE process at Motorola asked every employee to answer “yes” or “no” to six questions;
1. Do you have a substantive, meaningful, job that contributes to the success of Motorola?
2. Do you know the job behaviours and have the knowledge base to be successful?
3. Has training been identified and made available to continuously upgrade your skills?
4. Do you have a career plan, is it exciting, achievable and being acted on?
5. Have you received candid, positive or negative feedback within the last 30 days, which has helped in improving your performance or achieving your career plan?
6. Is adequate sensitivity shown by the company towards your personal circumstances, gender and culture?
This was done online every quarter and followed by a one-to-one with your boss to discuss how you could improve things together. Every manager in your reporting line could see your results and your own boss would expect to see your action plan to improve your team’s scores over time.
What do you think of this? A draconian measure or a positive statement of a minimum standard of expectation for all employees?
At the time of IDE being implemented, I was struck by the choice of language;
• INDIVIDUAL
• DIGNITY
• ENTITLEMENT
It’s a declaration of what we are choosing to become as an organisation; what we want the experience of being a Motorolan (and yes, that is a thing) to be. It’s universal and unbounded by grade, function or language and culture. It’s a clear message to every manager of the minimum expectation of them in relation to the people they lead. It humbles the role of “manager” to be in service of their employees’ entitlement to dignity at work.
Then there is the “yes/no” answer. No score of 1-10 or five point Likert scale or shades-of-grey adequacy. You either do or you don’t; clear and uncompromising.
The implementation of IDE was often painful. Employees worried about the consequences of saying “no”. Managers worried what consequences would arise from negative scores. Everyone was anxious about the one to one conversations.
>Then there is the “yes/no” answer. No score of 1-10 or five point Likert scale or shades-of-grey adequacy. You either do or you don’t; clear and uncompromising.
A classic bit of corporate bullshittery: Insist on giving employees questionnaires that supposedly enhance their "dignity" and help them feel more comfortable about working for you, but design it all in such a tone deaf way that it only, and very fucking obviously, will create more stress about how they should respond to please your bottom line.
I'm trying to imagine the entirety of my thoughts, dreams and feelings being reduced to binary choices on questions predefined by some corporate wanker - and it being called a dignity initiative.
Even if implementation was painful, did it work well? It sounds good, in making managers accountable and encouraging servant leadership, but I lack the understanding of psychology and unfortunate management to know /how/ it could go wrong, yet have the experience to say as gut instinct, this could go wrong.
Or was it positive but just tone-deaf that they introduced random drug testing at the same time?
I believe that at one point there was a term in a licence agreement from one of the companies involved that basically prohibited it ever being ported to anything else... but that's long ago. I wrote about the Moonshot effort recently:
It would be more accurately described as a blend of Delphi and Java, the latter via J++. The overall object model is from Java, tweaked to merge the primitive types with their boxed wrappers (i.e. `int` vs `Integer`). C# strings and arrays were also almost a carbon copy of Java rather than anything Delphi-like, although it did add multidimensional arrays. From J++ it got delegates and events. From Delphi it got things like properties and explicit `virtual` on methods, but notably not e.g. overridable class (static) methods or named constructors. Also, Delphi had manual memory management, not GC.
> C# strings and arrays were also almost a carbon copy of Java
You'd be surprised but .NET and Java strings have a lot of differences. In Java, String is a class which wraps byte[], in .NET - string is a "FieldSeq" object with characters stored inline. One indirection less but with no special fields and cached state like in Java.
Arrays have significant differences too, where Java arrays do not implement any actual collection interfaces - they are just contiguous chunks of elements with an indexer and length field and need to be asList'ed, so it's common to consider in Java to rely on arrays an anti-pattern, which is the opposite to C# arrays, which implement the full set of System.Collections.Generic interfaces.
We're talking about the original .NET 1.x here, not the current state of affairs.
In any case, what I'm talking about is not so much implementation details as user-observable semantics. .NET strings are pretty much exactly like Java strings in that regard - it's an immutable reference type that is a sequence of UTF-16 codepoints. In contrast, strings in Delphi are mutable value types (implemented using copy-on-write with refcounting).
Similarly for arrays, while Delphi has Pascal-style fixed-size arrays that are value types, both C# and Java have arrays as a reference type with null as a distinct value from empty array. The other point of similarity is that both C# and Java treat arrays of objects as covariant, even though it's not actually typesafe (and triggers runtime exceptions if you try to put the wrong type into the array).
> Thanks to our past experience with switches, combined with the figure-ground principle, a skeuomorphic design for a toggle switch will make it obvious to a user how to instantly turn on a feature.
(Figure-ground is how we perceive three-dimensionality in a 2D space.)
This is one of the best arguments for skeuomorphism I've read. It doesn't address the _look_ (ie, brushed metal) but it absolutely addresses the _style_ (looks like a real toggle switch, a real button, etc.)
There is a saying among PMs: when you're not sure what to do, you do a UX refresh.
(It's a bit like the same one for CEOs: if you're not sure what to do, drive an acquisition.)
UX rework needs to be done with real care -- not primarily care for looks, but care for function.
I _love_ Snow Leopard's UI. It was clear. Watching the videos on Liquid Glass, I was really hopeful we'd see a return to a similar design. Old OS X gave me joy, and I am sure I heard the word 'joy' used in the Liquid Glass video... and I was so happy! But what I see when I installed last night, and from this article, is glass and shadows in the background of windows, very low contrast ratios, and confusion between window areas.
Backgrounds are the wrong place for fancy effects. You need to be able to see foreground content clearly.
Foregound elements, like buttons, are great for fancy effects. They are small and isolated.
That's why pinstripes were awful (difficult background) and Aqua as a whole was great (blue gel buttons were clear.) Look at the comparison screenshots in this article: a list view in Finder, which is sorted, has a blue header on the sorted column. That is a fancy gel effect, but it is isolated and readable. If liquid glass were used the same way in Tahoe, we'd really be on to something. It's what I hoped for, and what I don't see.
However: one good thing in Tahoe is how fast UI elements interact. There is no animation on mouseover transition. It snaps in and out. This is excellent.
reply