JaggerJo

Only a matter of time now until we can run models with Opus like capabilities on our own hardware.

This will probably when the bubble bursts..

IMO we are reaching the point where AI models are simply a commodity. Opus (since ~4.6) is sufficient for everything I tried coding wise. I use it to write features (but I review and understand every line it spits out) and to review code.

For code review I also still review everything myself, but use Opus to catch stuff I missed and to judge if a PR is even ready for me to review.

After just updating Claude Code to the latest version I thought about picking Fable (the bigger model) instead of Opus.

But I have no reason to. Opus does everything I want it to do. It could do it faster - that would be an improvement. But for the normal stuff we reached the point where better models are not worth it IMO.

There still might be cases where you want to throw Fable at it.

Yup - IMO it’s just the wrong tool for the job.

[flagged]

finally!

Hope we’ll do the same in germany.

Let’s hope macOS 27 fixes liquid glass. For now I’m not updating.

+1 exact same situation.

having Tahoe on my MacBook made me appreciate Sequoia on my mac Studio. A real downgrade..

Yeah - It feels similar to me.

Why share something that anyone can just “prompt into existence”?

Architecture wise and also just from a code quality perspective I have yet to encounter AI generated code that passes my quality bar.

Vibe coding is great for a PoC but we usually do a full rewrite until it’s production ready.

————

Might be a hot take, but I don’t think people who can’t code should ship or publish code. They should learn to do it and AI can be a resource on the way.. but you should understand the code you “produce”. In the end it’s yours, not the AIs code.

Most solutions already exist as open source software.

.NET 10 + Avalonia is rock solid for cross platform UI

It’s in progress. Most of Europe slept on that - thats true.

But pretty sure we’ll figure it out over the next decade.

It’s good if you’re rich I assume

I hope with change in leadership correction of these things will be possible again. Not just Alan Dye, but Tim Cook is rumored to leave in the next year too.

..Jobs would've crucified a few people

And rightfully so. Tahoe is not just a step back, but it throws away so many good design elements that have been there for ages - and for no good reason.

I really hope they revert most of the design changes in macOS 27. I don't mind the Liquid Glass - the other changes they made to expose/highlight Liquid Glass are the real issue.

IMO we reached peak design in 2013 with Mavericks.

Hah, really? If you enter recovery mode and install an OS via network it installs the OS the device originally shipped with, right?

On an Intel-based Mac:

- If you used Option-Command-R to start up from Internet Recovery, you might get the latest macOS that is compatible with your Mac.

- If you used Shift-Option-Command-R to start up from Internet Recovery, you might get the macOS that came with your Mac, or the closest version still available.

https://support.apple.com/en-us/102655

Good that Alan Dye is no longer at apple. Liquid Glass on macOS is a mass. The icons, the floating side menus, the inconsistent corners, the new tabs in Safari..

On iOS it's totally fine, but on macOS it's a disaster. I've only updated one machine so far and will keep all others on Sequoia until this mess is resolved.

+1 I only updated my MacBook Air and really don’t like it. Will keep all other macs on Sequoia until macOS 27 hopefully fixes most of the issues.

Should be the default!

Thats madness. Just remove deprecated functions after a reasonable time period.

because liters works at the lowest level (virtual file system) all other things should just work.

You can still do this!

The only difference is that a lot of apps prioritize cross platform UIs over good, fast native UIs.

WinForms and WPF are still well supported.

Nice! A screenshot in the readme would be a great addition. I was looking for a native macOS Teams client a while ago - but to my knowledge this is the first 3rd party Teams client.

The Microsoft Teams client frustrates me daily.

The code snippet is in F#. And F# has so called "computation expressions".

To me it's crazy how many people work on these seemingly simple applications.

How many people do you need to build JUST the native Android and iOS app for snapchat?

Is the "single" codebase really worth all the added complexity and additional risk?

I'd always go the native route if the user experience is business critical.

Excellent Points, this is where the answer is "it depends".

What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?

If it's really functionality that cannot reasonable be shared don't share it.

It's probably more work to maintain bindings to a single API client in the core and fiddle with all the details of not using the native HTTP client implementations that it is to implement the API client twice.

Writing the API client twice is boring, but that's a good thing.

Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?

The shared core is optional. You might have the need for it, then it's a good solution.

For an app like snapchat you'd probably share the video effects and have that in your core library.

Agreed.

One extra clarification: If the quality of your app is business critical you should really use the native UI toolkit to offer the best platform integration and user experience.

If your app is not business critical (you just have to offer it - example: dishwasher app, ..) you might get away with using a cross platform toolkit like flutter or react native. But even then this adds a 3rd party dependency as you mentioned which adds risk.

Writing an App in Swift on iOS is boring. The same thing is true for writing an Android app using Kotlin/Java. This is a good thing. Now your developers can concentrate on shipping great features.

Just write 2 native UIs in the 2 platform native languages and share a common core written in any language that offers a C like FFI.

How hard could it be?

How does it render pixel data to the terminal?

I've stumbled over sixels [1], but movy seems to use something else that also enables color output and a higher resolution?

[1] https://en.wikipedia.org/wiki/Sixel

EDIT:

It renders frames as ANSI half block characters..

Seems like the resolution looks better than it actually is in the screenshots. It effectively seems to be 2 vertical Pixels per character.

great writing style