iamcalledrob

Networking, as we all know, is a rats nest of complexity and edge cases. I think software started getting worse when a high speed internet connection became a given.

90s software ran mostly offline. It was simpler and more deterministic. I think that's why it felt more reliable. Your UI couldn't depend on laggy server round-trips. Things either worked or they didn't.

The young'uns all cut their teeth on the web, where every project tends to reinvent the wheel (poorly).

It's funny (depressing) to me that there is now "web app" design language and a "native app" design language, and most new desktop apps are following the web because they are built in html and CSS.

I wholeheartedly agree with this perspective.

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!

Same -- fastmail is excellent and great value.

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

Remember: it's not your machine, it's Apple's. You just get the privilege of using it.

That's actually the opposite of my problem. Even in landscape, windows end up way too tall to be useful.

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!

> "what would happen if we only designed for large monitors?" What would it unlock if there were desktop designs that ignored laptops and only focused on widescreen monitors?

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.

Something I learnt from doing research in this space is that spatial memory is quite powerful, and a hierarchical filesystem taps into that.

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

> I bet people generated solutions end up significantly different from AI generated solutions. People learn more about the problem as they work it through and they don’t always end up with the thing they were imagining when they started.

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.

Personally, I think a lot of the enjoyment comes from learning to overcome challenges. Jumping in to an unfamiliar problem space, sucking at it, then grinding until it all clicks.

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...

> Leaving things alone is an underrated engineering skill.

Truer words have never been spoken.

It's funny, as a 20+ year macOS user, I've really struggled with file managers that are not Finder.

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!

WhatsApp is still based on XMPP unless things have changed a lot recently.

Requiring Apple's own apps to use the same permission prompts as 3rd party apps does something very important: it incentivises Apple to improve the permissions experience for all developers.

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.

A good step.

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

I think you'd struggle to keep LLM bots off the network unfortunately.

If it had any real value, anyway.

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

Counterargument: many good ideas are written off as bad ideas because they are hamstrung by shoddy implementation.

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.

Look at that subpixel antialiased text in 3.7.

So, so far ahead of it's time.

I've always been curious whether choices in Mac OS X might have been (unintentionally) influenced by RISC OS. I believe there were a disproportionate number of Brits on the HI team at Apple.

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...

KMP is brilliant and arguably the best way to write a cross platform app that has Android as a target.

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 ;)

I've built and shipped some native-UI cross-platform apps to millions of devices, powered by a Go shared library. It works. It's fantastic to use the same language on client and server, and the end-to-end testing story is really strong.

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 root cause of this stuff, from experience, is that animations are hard to retro-fit after the fact. It's a lack of planning.

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!)

Another issue: Paper was tied to your Dropbox account.

From Dropbox's perspective, this sounds great. Accounts become more useful and valuable. The addressable market of a Dropbox account grows! Plus, everyone has a Dropbox account already, right?

Unfortunately, it turns out that business customers generally don't deploy Dropbox wall-to-wall. It's expensive. Not all employees need file sync.

A Dropbox account ends up being an obstacle to adoption.

And a distraction: a common account creates an irresistible urge to spend a lot of time finding ways to tie this new product into the old one.

I would also bet that 90% of Swift training data is UI code.

And UI code quality tends to be technically pretty crummy/low-discipline. Your UI code doesn't need much consideration around data races, for example.

The micro-interactions and hotkeys in GIMP are just so poor though.

For example, basic stuff like zoom in and zoom out are bound differently to literally any other app on any platform. This catches me out every single time I try to use it, and I'll never learn the GIMP way.

Spoiler for anyone unfamiliar: it's not Ctrl+/Ctrl-.

...although the logic in the article is slightly odd:

  1. Discover complex native text rendering is hard
  2. Render text in a low-level way, complain about having to (re)implement native interactions
  3. Try WebKit and it works great!
  4. Throw WebKit away??
  5. Have to re-implement native interactions??

Personally, I would have stopped at (3).

Fun fact: This is how Apple used to do it too.

Old versions of macOS / AppKit used to use WebKit to render rich text inside their native NSTextFields. Turns out text is hard :)

And besides, the native WebView is super fast and lightweight, and its not unreasonable to use it as a text layout engine. You could use separate webviews for every row in a table and you'd still get fantastic performance.

iMessage for mac used to use a webview too. Adium as well. HTML is absolutely the right tool for the job if you're rendering rich/marked-up text.

It baffles me a bit that people are working so hard to replace themselves with AI. It's such a high bar for the AI to hit, and takes the creativity away from the human.

I have a pet theory that perhaps the optimal way to use AI will be more like an "exoskeleton" that turns you into a super-human programmer. Something that plugs the deficiencies of the human programmer, rather than replacing you entirely.

Nitpick, but it bothers me: The human factors of their demo video don't stack up.

Horizontal dragging with a mouse is actually really hard. Nobody's going to use it like that.

Your arm can easily move your hand and cursor up/down by pivoting your shoulder, but there's no mechanism for left/right movement. It's always an arc.

Or put another way: selection will be a lot slower and more tedious than the demo.

Using the "system WebView" is not a positive on Linux.

For some reason that always means WebKitGTK, which is crummy.

Someone, anyone, please get CEF working with GTK4.