Ignoring the orientation constraint, one easy way to tell is that one has a flat line on the bottom and the other doesn't.

LLMs are determistic. Just like everything else computers are capable of doing.

Commercial front-ends just hide the random seed parameters.

Distributed float math is not deterministic without introducing total operations ordering and destroying performance

It's not usefully deterministic in the way computers usually are. Sensitively identical input can still lead to wildly different outputs even if all randomness is crushed out.

Vim mode in vscode is not even close to emulating a real neovim setup.

OP specifically mentioned "using keyboard to navigate". If that's all you need, then VSCodeVim can get you pretty far.

CodeCompanion.nvim is a pretty nice plugin. I use that for quick stuff and opencode in the embedded terminal for larger tasks.

I think the best answer you're really going to get here is that it's cool and fun to learn and use old languages.

I'd agree with all of those reasons! I do so myself as well, was just specifically curious about the "The world is better with a Fortran-based social network client in it" part. Don't get me wrong, I've spent too many nights learning "dead" languages too, but never with the idea that the world would be better if I published more code in these dead languages, it's just for my own gratification and learnings.

This is unfortunately loading very, very slowly for me.

I'm not OP but I've worked on JUCE plugins with React UIs for JUCE8 web view.

The UI load is pretty instantaneous.

Everything uses the native web view. This means that on macOS you get WebKit and on Windows you get Chrome (or sometimes IE).

So it's generally faster than Electron. In the project I worked on it was not noticeably slower than native UI.

Memory usage is really close to what you might expect from any other app running native web view.

Thanks!

I wasn't aware JUCE included a web view now.

Wren is super neat. I've written a few small games for TIC-80 using it. It's a really fun language to write.

I think Google has proven with their recent actions concerning android that they really can't be trusted with big, critical open source projects.

> trusted with big, critical open source projects.

You talk as if the community has appointed Google to take care of these projects. Google is spending $$$ writing code and open sourcing it. Not the other way around.

And as with anything open source, if you dont like the direction of open source code - fork it.

If I have an open source project, you dont say 'bitpush cant be trusted with the project'.

Where is the source code for AOSP 16 QPR1?

Where are the security patches of the past couple of months?

What is QPR?

I tried this. It sounds good on paper but the LLM will just "forget" to use it's tools. Either it will decline to query the database and just make stuff up, or it will decline to update the database when it should. The further along the game play gets the more out of sync the game word gets from the external state. I'm sure there is a clever solution but I never found it.

you're making the mistake to assume that leaving the structure of the communication and game play to the LLM is the only option. the LLM just is a tool serving a specific purpose in the game play. the LLM cannot forget to query if the query/state-management task is simply an imperative step in a loop. it's not left to the LLM to remember it.