That's programmer incompetence. Unfortunately pervasive, especially with devices like parking meters, EV chargers, and similar, where the feedback loop (angry customer) is long (angry customers resulting in revenue decrease) or non-existent.

It could be a management problem instead also, while developers are just following instructions sent by management

And nobody with options would settle for the low pay and terrible working conditions, so the quality of the output also reflects that.

I disagree — developers are not sheep.

I agree ! But they could be stuck because of management

They also prefer you to use the mobile app so they can gather more data so they do not want the devices to work well in the first place.

It's a nice theory, but many of those terrible parking ticket machines predate smartphones, so it might be the case for machines built now, but it's really hard to imagine that that was the original intention

I work in an adjacent industry, and trust me when I say that a lot of older equipment companies just did not care much about the experience of using the equipment. It's much more important to tick all of the boxes in the back end accounting system than to have a high quality experience on the kiosk.

It's organizational incompetence driven by companies that see software development as a cost centre rather than a key asset.

It's usually clear when this has happened. Buggy bargain basement output.

After Apple suddenly discontinued Aperture, which left users like me with huge complex photo archives hanging, I will never trust any professional software tool from Apple again. It is a disaster that I still haven't fully recovered from.

I've learned my lesson — all my archives will now be maintained by me, in file structures, with metadata in text files.

Me too, with Aperture. Huge misstep and insult to the user base.

This is a useful tool: https://github.com/cormiertyshawn895/Retroactive

However, you still need to run an older OS. I've still got on my todo list the process of fixing all of this.

It's been a decade and it still hurts that it was discontinued.

Learned that lesson too. Then got into Lightroom. Now getting out of that by exporting stuff slowly. Moving to files on disk and edits in Darktable now. No "library".

Not only Aperture. The FCP7-FCPX transition was a disaster as well.

Please don’t take this as me saying you were wrong to ever trust Apple, however the best way to organise any data is usually just files on a disk.

That’s becoming a recurring theme for me and even some of my corporate clients now. Confluence, for example, is out the window for secure documentation around sensitive environments and Word Docs in One Drive are back in. It’s surprisingly refreshing and gets the job done way better.

From what I recall, aperture did use files-on-a-disk, maintaining original photos read-only and letting everything else be operations on those originals.

(am I recalling correctly?)

It's all true, but if you think organizing photo archives is easy, boy have I got news for you.

Metadata, versions, version groupings, projects, albums, there is lots of structure that most people don't realize exists.

Think every picture has an EXIF date and that's the date when it was taken? Think again. Scanning date is not the same as picture date.

Actually, even if you think of a date, you probably imagine the usual ISO8601 2026-01-14T17:37:46Z date — how about when we only know a year? This is something Aperture didn't do either, but when dealing with photo archives what you want is arbitrary precision date intervals. E.g. 1900-1902 for example.

Anyway. Just pointing out that even though "just files on disk" is the right approach, managing those files and their metadata is far from obvious.

Agree with all of this, apart from possibly OneDrive but that's for another post.

Not Apple-specific really that point for sure anyway. Personally I don't think we should ever ever trust any vendor to control our data or act as a proxy for access to it. If it's not on a physical disk in your hands, in a format which is documented and can be opened by more than one application, then you're one step away from being screwed. There are so many tangible risks we love to sweep under the rug from geopolitics, commercial stability, security, bugs to unexpected side effects. And I've seen some real horror stories on all of those fronts.

At the same time I managed to embed myself thoroughly in it and I'm 3 months in to undoing the mess. It's VERY hard to get back to files on disk. No moving away from that is probably the best option I suspect a lot of us never took.

Hardest stuff to get out of is iCloud/Apple and Adobe.

Power tip: replace the Word docs with Markdown.

Thinking that Markdown is comparable to a Word doc for even most purposes is delusional.

Markdown should work reasonably well for the use case of Confluence pages that have been moved into Word docs.

The Aperture discontinuation still pains me as well. Especially since I can't even run it anymore.

I also bought Final Cut Express. Not sure I'll buy Apple software again either.

Logic users on Windows also weren't too happy when Apple bought Emagic and dropped Windows support shortly after.

FWIW, I've been testing MCP tools exposed from Autodesk Fusion (https://github.com/AuraFriday/Fusion-360-MCP-Server) and the results are quite promising. It's especially good as a quick starting point.

I program mostly in Clojure and I expected it to be near the top, as it tends to be very concise and expressive (qualities I really admire). I am getting excellent results from Claude Code (Opus 4.5), and I think this might be one of the reasons. I'm using Claude with a large code base and the token-efficiency of Clojure might help with fitting more into the context window.

I also program a lot in Clojure/Script. Do you also consider thinking token and the number of iterations in the token efficiency?

I don't think thinking tokens are affected, as LLMs "think" mostly in plain language, with occasional code snippets.

I would assume for certain problems LLMs have a solution readily available for JavaScript/ TypeScript or similarly popular languages but not for Clojure/Script. Therefore my thinking was that the process of getting to a workable solution would be longer and more expensive in terms of tokens. I however don't have any relevant data on this so I may just be wrong.

The M1 hurt their future hardware sales, as now, 5 years later, it remains a viable machine. The M1 MacBook Air has become a bit of a meme.

similar here, i bought refurb m3 mbp last nov just to get pre-tahoe

Thanks! This should come in useful as I intend to soon dust off the task of migrating my (rather large and complex) app to FoundationDB.

I was also surprised to read this. I have terrible problems with all Google UIs. I can never find anything and it's an exercise in frustration to get anywhere.

This makes perfect sense and is so much better than getting a flood of half-baked "issues" and then closing them automatically with a bot for "inactivity".

It's a nice intro! One thing I would respectfully suggest is using more precise terminology than "ACID". Jepsen has a great resource for looking at various consistency models (https://jepsen.io/consistency/models) and while every database these days says it is "ACID", very few can guarantee Strict Serializability in a distributed setting, like FoundationDB does.

Good suggestion. I take serializability for granted.

I used to work at a company developing an independent H.264 decoder implementation. We would have killed for this kind of source content, especially if the license allowed showing it at trade shows.