As with most creative pursuits, the best things happen when there's a clear point of view.

Unfortunately, the best things aren't always the most commercially successful, because products are only a small part of what makes a company successful. I think we're seeing this play out in the software market.

JIRA might be objectively awful, but it still manages to print money!

An example of a company that does exactly what I pay them to do and respects me as a customer.

In a traditional floating setup I would have multiple smaller overlapping windows wherever I want them.

Whereas with a tiled/scrolling layout, windows can end up way too big to be useful. It's fine on a laptop though.

I initially used Niri on a laptop and thought it seemed great. Then plugged in my large monitor and realised it was awful there!

There's something to this thinking. Large workstation monitors are very much their own thing.

A real example l I've found: Niri (scrolling window manager) is really nice on a laptop but awful on my 6K display. The windows are way too tall, and the induced motion of large windows on a big screen is too much.

Whereas tagging doesn't align as naturally with the human brain in the same way.

Exactly!

And to be clear, you can learn a ton from LLMs. An expert teacher with infinite patience -- what an amazing thing. But there's a different kind of learning that only happens with practice, and that's what you don't get when a computer does the thinking.

Your brain is hardwired to find shortcuts. Once you have an LLM at your disposal, it'll be real hard to abstain from using it to do the hard bit.

Generative AI takes away the grind, which takes away the learning. How do I master a new language if I'm expected to code via an LLM from day 1?

It's also well understood that the act of writing is when thinking actually happens. You have new ideas, opinions form, and so on. I think it's the same with writing code. But when you're not writing code any more, you don't go through this process.

I wonder if an LLM-authored project would even end up solving the same problems that a human-authored project would? If a human didn't write the code, then a human didn't have the chance to think in the same way. They didn't spend time trying to think of a good variable name, which made them realise the whole premise was wrong...

Truer words have never been spoken.

I don't think it's that Finder is brilliant -- it just encourages a unique set of power user workflows that aren't replicated elsewhere.

For example, Open/Save panels that act as drop targets, and navigate to the dropped file's parent folder. I use this all the time, and it drives me nuts when I can't do this on Linux (Nautilus) and Windows. Enter to rename, too. These habits are very hard to break!

Currently, the permissions APIs and user experience are designed horribly, and there's a disincentive for Apple to fix it.

Random example: if you write into the photo library, you don't have permission to read back what you wrote. You can't even deep link to that media in the photos app*

*Unless you are Apple.

Apple's own apps are still blessed with permissions that other apps have to ask for. This needs to be addressed too.

If it had any real value, anyway.

Small, truly private communities could be an interesting thing though.

The implementation is just as important as the idea. In the real queue, details matter.

I think Facebook in particular often undervalues quality of implementation, and it negatively contributes to their brand.

So, so far ahead of it's time.

The stand-outs to me are the use of blue folder icons and the Dock.

https://www.retro-kit.co.uk/user/custom/Acorn/3rdParty/Retro...

But what you can do with it on non-JVM platforms is a bit lacking. There are few libraries and the stdlib is rather minimal.

If you're just making some http calls and instantiating models it's pretty good though!

Shame it's part of the Grade hellscape though ;)

However, in my opinion, "Go Mobile" is a bit of a red herring if you just want a cross-platform shared library. I wouldn't recommend starting there.

It's optimised for writing and packaging an entire app in Go. Incremental builds don't work well (or at all), and cobbled-together "build system" is more to debug. It's also oriented around iOS and Android, which isn't great if you eventually want a native desktop app too. The generated bindings are okay, but the author's approach of using Protobuf (or some kind of wire format + simple API) means you don't really need them.

I found that it's more straightforward to just compile Go code into a library that can be called from C -- and thus can be called from anywhere. Call into it natively from Swift, and via JNI on Android and desktop JVM. With the right toolchain, you can cross-compile pretty easily too.

The biggest issue is that on Android you often want to talk to the OS, but the OS only speaks JVM. https://github.com/timob/jnigi "solves" this, although you will hate your life manually constructing JVM calls that you can't easily test.

The UI code needs to be structured with animation in mind, with hooks in the right places. And to do that, you need to know what is likely to be animated together.

But what ends up happening is you encapsulated a few of the moving pieces in abstractions (e.g. "toolbar", "sidebar"), but you want to animate stuff within. You end up copy+pasting animation logic inside each (now leaky) abstraction and duct taping it all together. UI abstractions are hard!

(Yes, on apple platforms there are transition blocks which will capture changes to the entire view hierarchy, but then the battle becomes preventing animations on stuff that shouldn't change!)