I feel like this post is hawking for commercial reasons more than it’s based in reality, especially a reality that takes into account the extremely varied experiences engineers seem to have with agents. Not to mention it ignores capabilities that, for example, Claude’s VS Code addin have had for ages (specifically select and annotate in plan mode, as I mentioned in another comment).

As such I’m not inclined to take it very seriously. More than that, the “X is dead” trope was overdone 10 years ago and I don’t think it’s been long enough to warrant a resurgence.

I mean, it is, and if that were the workflow I’d be very fed up of it by now, but the plan mode in Claude’s VS Code extension has supported select and annotate directly since at the very least early 2026.

Your use of “when” is interesting - suggests it’s not that occasional. Wonder what people are doing with these nowadays.

I’m not saying there are no companies that keep non-live job ads up purely for fishing purposes but, in my experience, it’s not the norm. It would really piss jobseekers off and that’s the kind of word that tends to get around and make it harder to hire in future. Maybe not if you’re a FAANG, because so many people want to work for you anyway, but it’s going to cause problems for “normal” companies.

For example, I've personally witnessed situations where the funding for a role gets postponed to next quarter, but my manager just kept it open anyway, either out of fear of missing out on the perfect candidate if they stopped accepting apps, or because it's simply easier than going through the HR process to re-post it in a month.

2024.

Yeah and, sadly, those framework implementations are all mired in some amount of bollocks due to lack of care, attention, or interest from their creators. And by bollocks I mean they either behave differently or do less.

But I very much miss the days of consistent UX across Windows applications, or indeed applications on any other OS.

I don’t mind if you want a custom look and feel for your application: I very much do mind if your widgets don’t behave like other widgets of the same type or, at least, where any variance is at least a superset of OS level functionality rather than a crippled subset.

I was always frustrated by how hard Microsoft made this as time wore on and they moved through more and more UI frameworks, and then offerings like CEF and Electron entered the mix as well. The UI story on Windows started getting particularly messy around 2007 or so and has been in an awful state of confusion for at least 15 years now.

I literally have no idea what I’d use to develop a Windows desktop app nowadays and, honestly, none of the options fill me with enthusiasm. With more recent desktop experiments, partly because whilst I might want them to run on Windows I don’t primarily work on Windows, I’ve gone the Rust + Qt route simply because it offers native performance and it doesn’t feel like I’m getting rug pulled by either set of creators any time soon.

I would go further and say that I don’t want a custom look and feel for each app unless the app is a game, especially if your app is a regular line of business app. The default Win32 widgets are good enough. The default Cocoa widgets are also good enough.

Beyond the now-denied choice of UI color scheme I do not expect (or even desire) deriving any joy or pleasure from the look and feel of software I use. Most of my computing is for "work"-- be that my job, or paying bills, shopping, etc. I want the UI to get out of my way and, most of all, not to insult my 30+ years of muscle memory and visual intuition. I derive joy and pleasure from software that allows me to quickly accomplish my tasks with minimal thought or friction on my part.

I experience massive frustration with software using UI widgets that don't work like the native OS. Not having the standard keyboard shortcuts, for example, is a great way to make me hate your software. It's an immediate "tell" that I'm going to be disappointed if a program has bad tab order on its UI elements, for example.

Moreover, eschewing the time-tested and battle-hardened native UI widgets speaks to arrogance. It feels like an ego trip and it's almost certainly unearned. Random developers probably can't pull off a widget replacement that replicates all the nuance of the native. Good luck pulling off accessibility and internationalization, too. Even if they can how is reinventing that wheel a good use of their time?

My rage is amplified when I find bugs in software with non-native widgets. They had time to dick around with the widgets-- something already done for them in a vastly more competent and comprehensive manner for free-- but not to ship bug-free code for the software's actual purpose?

The same goes for animations, fades, gradients, etc. The vast majority of software I use is not special or dear to me. It's a tool. I don't want to, in a manner of speaking, look at pictures of the developers kids or vacations as a "toll" for using the software. Making software "pretty" is only self-serving and egotistical.

I'd agree personally, but when you look at the huge success of things like WinAmp's themes back in the day, there clearly is (was?) a large market for it.

The problem we face right now is that this has been flipped and applications are now forcing developer customizations onto users and removing any and all choice or customization. Up to and including ignoring and overriding OS level customization.

If a framework cannot provide you with the right looks, you have to to override it. Hence the mess.

Also agree with you on both Win32 and Cocoa widgets.

Speaking of performance of media apps, I stopped using the official Spotify client after I found out about Spotifast [1]. Yes, it's vibecoded, but it feels so fast and light compared to the real client that I wonder why Spotify itself doesn't fix their official app.

[1] https://spotifast.rocks/

The problem starts when you want to ship to every device known to man but you only have the dev power to maybe ship it to the web—enter, Electron (and all that other similar crap).

Don’t blame it on the designers or the developers. This comes from above the worker bees.

There's a document I've seen floating on the Interwebz, a copy of HIG for ancient Windows version, I think one of the 3.x ones. I distinctly remember it for having a note somewhere basically recognizing that giving some of the theming/customization options in the API is a bad idea, but customers want to brand their apps, so what can one do.

This is one of the problems that I can't see being solved, because it's purely social - we'd have to have someone go and tell every entrepreneur out there that branding is a fucking stupid idea and you should not do it, and actually be taken seriously.

I can't even imagine a world in which that is possible.

Yeah, you lose some people with a shifting target, but it's easier to make them swallow 1% different every month than 50% different (to a competitor) all at once.

...and even if the app is a game, it can still make great use of Win32 controls creatively. Minesweeper is one example that comes with Windows, and I remember plenty of other casual (non-3d) games in the 90s/early 2000s making use of buttons, both ownerdrawn and stock, likely to avoid having to write their own hit-testing code.

C#/.NET and WinForms is still a viable choice. Though for a new project I might try WPF, for a slightly more modern appearance.

Reasons? OK, this is going back about 20 years but, and without going on a massive ranty screed [EDIT: oops, failed], compare something like Swing's JTable to WinForms' DataGrid. One is a really nicely designed and abstracted component with a fully pluggable architecture and an out of the box capability to deal with an arbitrarily large data model (perhaps within the limits of 32-bit integers) and the other... isn't. I tried with DataGrid, I really did. I thought other developers at my employer were "doing it wrong" by reaching for third party controls from the likes of DevExpress and Actipro but... they weren't: I was wrong. If you wanted a proper table/grid control that was easy to customise and extend and wouldn't chunder on millions and millions of rows of data you forked over the money to DevExpress for their control and then you got on with your day solving your real problems that you could charge customers actual money for.

We leaned hard on third party control libraries from DevExpress (particularly grid and tree), Actipro (wizard), and Syncfusion (again, grid). To me, with WinForms, and bearing in mind I'd come from Java Swing (which is by no means perfect) it was really weird working with a UI toolkit where what came in the box wasn't sufficient to build any arbitrarily complex UI I might desire. Weird. And frustrating. Same for the lack of abstraction/separation of concerns. In my Java days, when I wanted a wizard I ripped the one out of NetBeans: I did that in at least two prior jobs using it as the basis for multiple wizards across the relevant applications.

And WPF... although architecturally a lot better, IIRC it didn't even have a proper table/grid control: you had to build your own, and when you start thinking about how rich a proper table/grid is, taking into account accessibility, keyboard shortcuts, picking up OS level settings (palette, scaling, etc.), making it behave like a table in any other application on Windows, I just couldn't be bothered building all that... so then it's back to third parties again.

I don't know what third party support for these frameworks is like nowadays but, fundamentally, for the sort of independent experiments I'm working on I don't want to either (i) fork over hundreds or thousands of dollars to third parties for (I think) basic functionality that (I think) should be available as part of the framework and should have been there since day one, or (ii) spend time wrangling the framework to implement this basic functionality because it isn't a core part of the problem I'm trying to solve or the value I'm trying to deliver.

I'd rather just use Qt or something, which at least has what I need.

Do you actually mean the DataGrid? Because the WinForms "DataGrid" was deprecated in 2002 with .NET 2.0 which added the DataGridView. The software I work on is Windows Forms and I can't say I've had any issues like you describe with the DataGridView. I was able to create a control derived from it that does all the heavy lifting for customizations(Visual, interaction, cell spanning, etc.), of which we had a lot. Enough that we were exploring third party controls, but found we would have to customize those ourselves anyway, so I just wrote my own control based on DataGridView to save us the licensing.

WPF had it's own DataGrid control from the start, though I can't comment from experience on it's versatility, I'd assume given WPF's nested-content approach it is surely at least more flexible than the DataGridView.

In any case that didn't really matter. In mid-2004, when I started, the company was still targeting .NET 1.0 for all apps because it meant we could guarantee customers would have that runtime installed on their machines without the need for another dependency. The business model was download -> try -> buy so we wanted as little friction as possible and having a newer version of .NET that might require another download and install wasn't worth the dropout rate we'd experience.

That being said, .NET 1.0 also meant we were using Visual Studio.NET 2002 which was... incredibly painful to work with. I'd come from the world of IntelliJ IDEA which had all manner of code navigation, inspection, refactoring, and testing functionality built in. Not to mention Java already had generics and a much better and more comprehensive framework class library and more mature OSS scene covering whatever was missing from that. .NET 1.0 and VS2002 had none of it and, I forget, was it that VS2002 had no extension model or was it just that ReSharper didn't support it? Either way it felt like stepping back into the mid 1990s and I wasn't happy.

Eventually, sometime in summer or autumn of 2005, I managed to persuade leadership that at least allowing us to use .NET 1.1 and Visual Studio.NET 2003 would be a good idea, and would enable us to use ReSharper, which at least brought us on par with IntelliJ IDEA circa 2003 or so. I can't remember but it might have been that .NET 1.1 had been rolled out over Windows Update or enough service packs for Windows 2000 or Windows XP that we deemed the likely loss of purchases to be negligible.

Our first products developed with .NET 2.0 we didn't start working on until the back half of 2006 and this was really only because we were developing products that plugged in to SQL Server Management Studio which, again IIRC (long time ago), was based on the Visual Studio 2005 shell and required .NET 2.0.

We were always lagging on .NET versions because we wanted to make sure someone could just download, install, and run our products without needing to do anything else.

Pure Win32 still works, and is the most efficient and consistent.

FWIW I think your Rust + Qt route is fantastic. I've been using Rust + EGUI myself, but have Qt in mind for future projects.

This is why I love GNOME. The community is doing a great job with creating GTK4 native applications. I'll often pick a GTK app over a more featured app, because they usually do enough. It's very satisfying to be able to use the same shortcuts in most applications.

This is the "man with two clocks" problem. Win32 is still there, it still works and it still produces scroll bars that work like they did before, but now you have so many other options you're permanently indecisive.

This is why I like Delphi / C++Builder's theming. It's standard UI controls -- so you get stuff like the scrollbar menu Raymond mentions -- but you can make it look custom if you want. Same behaviour, different rendering.

Interesting that you picked 2007 as the start of Windows' decline in this regard when WPF (from the same year) makes it so much easier to change the look without changing the behavior. I my eyes that toolkit does a lot of things right with controls that only define their behavior and not their visuals, which can easily be completely replaced (well, easier than writing a new Scrollbars from scratch).

People often aren’t hitting up GitHub directly to get or install open source projects: they’re going via homebrew, npm, or whatever, so the registry becomes the source. Of course you can install directly from GitHub even with package managers but most times you don’t and it’s increasingly seen as a security issue.

On your second point, ugh, yes, you’re absolutely right. I don’t think it would work exactly the way you describe but, if there’s some automated revenue sharing/distribution, you can bet that people will find ways to exploit it via some form of spamming.

Package managers tend to only need a small portion of what's in any given repo; some metadata to figure out what's going on and a single binary package is generally enough. The obvious answer is to separate those out and serve them differently from developers, who are actually monkeying around with the source code.

Mayne you know, are the internal components already designed with corrosion in mind?

> When a cycle is started, a wax motor is actuated pushing a pin outward and locking the door. This design has cost, reliability and safety advantages. In moist conditions a wax motor costs less for equivalent reliability than an electromagnetic solenoid or motor latch. It has a predictable passive release delay. If power is lost the door remains briefly locked, designed to be longer than the high speed spin cycle coast-down time, then reliably unlocks as the wax cools.

Not all hours are created equal when it comes to downtime and my intuition is that most of these 12 landed within my working hours.

In terms of impact that then might mean they were down for 7.5% of the time I needed them, or had business hours uptime of 92.5% which is… both not very good and very disruptive.

On the other hand, downtime at 4AM would be much less impactful even if it happened every day and added up to more overall downtime.

You can obviously compute this for a particular customer, but being a global service, it's pretty much guaranteed that someone somewhere experienced the worse of those numbers

This is important because it's quite possible that the downtime is biased toward the times they have the most active users.

https://cloud.google.com/blog/products/gcp/available-or-not-...

Two separate categories: Meme games[*] don't have to be vibecoded, not all vibecoded things become meme games.

[*] A "meme game" being a game which is tries to be ridiculous and is predominantly popular because of social media exposure. I would include games like Goat Simulator, Horse Magnifier, Squirrel with a Gun, QWOP, Untitled Goose Game, Trollface Quest...

I can only imagine: clearly I need to check that out.