m0zzie

I find this very amusing, given we humans are also highly susceptible to this.

That site happily flags writing older than the modern AI era. It's a worthless grift, which has unfortunately suckered many.

Use tldraw. Steve rolled the perfect freehand library into tldraw and the tldraw implementation has been improved since then IIRC. So you can get the same experience and easily grab an SVG.

Your follow up post and edits help with clarifying the tone, hopefully readers see that.

Apologies if you already know this, but I noticed you’re getting flagged so thought I’d add some context: the author is the CEO of Obsidian and has a few successful projects, so bragging about your 500 stars and saying things like “when I was just starting out, I didn't tell people to feel free to help. I put the effort in” is probably rubbing people the wrong way.

> Flutter apps feel completely _wrong_ on any platform except Android [...] Flutter explicitly eschews standard web technologies in favour of either one big canvas or lots of little canvases.

I think you're confused about how Flutter works on Android. It's not native to Android, it uses canvas with custom drawn implementations of most components there too – same as it does for iOS/macOS/web.

The value in the conversion of existing code in this particular case isn't 100% clear to me either, but I think calling Kotlin a weaker choice than Java at this time is naive, particularly when preceding that with "there are a mountain of tools" that you can bolt on to Java to give it features that are built in to Kotlin.

What makes Kotlin such a strong choice for many orgs today is its batteries-included multiplatform capability. We are able to write data models, validation logic, business logic, etc just once and compile to JVM, WASM, and native targets. For orgs with very large codebases and frontend applications (web + iOS + Android) this is an attractive capability because we can have a single codebase for a ton of core functionality, and have each frontend import a library which is native to its own platform.

Of course many technologies with this promise have come and gone over the years, but this is the first one with a strong backing that has allowed us to _natively_ interoperate with each target platform.

I believe these are all driving factors that have been pushing well known companies, that were previously Java shops, toward Kotlin. If you speak to a broad range of people in the industry you'll find many more orgs moving from Java to Kotlin than from Kotlin back to Java. We can simply get more work done with less code and ship to all our frontend platforms, and unless Java can do the same, I don't see the industry moving in that direction.

> the Zenfone 10 is also 5.8” and is adored for it

Adoration alone does not pay salaries. At the end of the day the manufacturers are businesses looking to generate as large a profit as possible (some even want to build the best tech possible while doing so), so as much as any of us may adore one feature or another, the only thing that really matters is sales volume and the resulting profits.

To clarify, I think it's extremely powerful and useful too. It's just that I get more misses than hits when using it as a rubber duck and coding assistant.

Can anyone comment on its coding ability?

Considering cancelling my subscription with OpenAI as I was previously using GPT-4 quite heavily as a multiplier for myself, guiding it and editing outputs as required, but GPT-4o feels significantly worse for this use case. It is certainly better in many other areas, but its coding ability is not great.

I tried to revert back to standard GPT-4 but it is now so slow to respond (higher load?) that it breaks my mental flow, so I'm exploring other options.

You are correct, that part of my comment was more a feature Kotlin multiplatform which Compose is built on top of. When building with Compose it has been a really nice experience to just call out to Foundation APIs on iOS in the same way I can from Swift, which has been the most impressive part to me. In Compose for Desktop apps you use JNA for native access IIRC. Kotlin multiplatform itself can compile natively to macOS, Windows and Linux without JVM, but you'd be running in a separate process to your Compose app which is JVM based on desktop.

Apologies my original comment was unclear on that.

Compose multiplatform is the future. I've used Flutter extensively but I created my first Compose Desktop app about 2 years ago and haven't looked back. Everything was alpha back then, and the tooling was only okay, but it is quite an impressive dev experience now, and there are two huge advantages over Flutter:

- it is truly native, in the sense I can directly talk to native APIs on each platform without going through bridging code and there's no special runtime

- Kotlin exists outside of Compose Multiplatform. I love Dart as a language, but the reality is it is irrelevant outside of Flutter. Due to Kotlin gaining some popularity across various platforms and domains, it has an advantage that people who already know the language will decide they want to try Compose Multiplatform, because it's low risk and low effort to try it out

Wow, TIL `git diff --staged` exists and is an alias to `git diff --cached`, which I have used for many years. "staged" certainly feels more intuitive, but will I ever be able to undo this muscle memory?!

> Delta Force Land Warrior

There's a name I've not heard in a long time. I loved that game so much, the engine and gameplay was ahead of its time (or felt that way). It was sad to see NovaLogic fall behind in the years that followed.