It’s not really ironic since the goal of the system is to reduce variance. Or I guess ironic in the same way as it is that the Buckingham Palace guards just stand there when they could leave at any time.
Making these kinds of AI projects with fancy READMEs give you a veneer of authority, but the lack of earned wisdom tends to stick out once a few people glance at it.
Yeah maybe not the best wording. It’s more meant that ideally toast can be fully used with a cursor for interactions. I don’t think you can exit vim or emacs just by clicking on a button?
You absolutely can exit Emacs by clicking a button! Even when it is running in terminal. You just need menu-bar-mode (which is enabled by default) and enabling xterm-mouse-mode (which also should be enabled by default) - https://asciinema.org/a/rprH0gLSkrUz2cqr
You can: emacs has a menu bar and you can quit emacs that way. If you write code in your .emacs.d to turn off the menu bar, then I think you can be trusted to use the keyboard to quit emacs.
You can exit Emacs by clicking a button, by making a mouse gesture, by telling it via voice command, by key-press, by modal key-chord sequence, by writing into a file, by selecting a menu item, by directly evaling (kill-emacs) command, by cookie in a file you merely visit, by a keyboard macro replayed from a register, by an abbrev whose expansion hook quits, by evaling an Org-mode source block, via a timer, via built-in solar and lunar calendars, by a shell command run inside Emacs that kills its own parent, by SIGTERM or SIGHUP from outside, by closing the last frame under the WM, by an LLM agent with an eval tool, and by pulling the power cord.
"I don't think" is never a good argument for making wide claims about anything.
> Of course, to be completely fair about my toolkit, standard Scheme can sometimes lack the heavyweight, “batteries-included” ecosystem required for massive enterprise production compared to the JVM.
I was thinking the whole time, "this person would _love_ Clojure".
kawa is unfortunately a somewhat shoddy project. Alot of halfbaked features / abstraction ideas (eg trying to support CL for whatever reason), dubious tooling for a java project (autotools), unclean and inconsistent code formatting. It's missing some features that are expected in a real scheme like multishot continuations; someone wrote research about it as a MSc thesis, but due to mentioned shoddiness its integration to upstream stalled and hadn't been merged.
At some point I thought of forking it to then cut out and polish the core, but then my attention got caught by graal's truffle framework as a plausibly better path for implementing scheme in java
Its funny, I can definitely sympathize with wanting multishot continuations, but I can't think of many times where I have wanted them to solve a problem.
I just used to use dillo because it was faster, cleaner, and left more RAM free for other uses. If there was a sufficiently broken site that I still wanted to bother loading, I'd fire up whatever the big browser was called back then.
Dillo started as a fork of the Armadillo browser which was based on GTK+. It was the next version - Dillo 2 - which was ported to FLTK. The GTK+ version did not support CSS and initially did not support frames/iframes either. I submitted a patch which added support for the latter somewhere around 2003 which was never merged before the port to FLTK but which I have used for quite a while until these features became less important due to the uptake of CSS.
I just started it up and it turned out to be Dillo 3.0 from 2011. I do not know if it was using FLTK back then, but a quick search says that FLTK has been ported to DOS so that might not be an obstacle for the current developers to keep FreeDOS support if they wanted to.
I've also worked with CSV (barely) and SVN (more extensively) and I was blown away by Git.
You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on.
There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?
One thing JJ has that git doesn't is the concept of first class conflicts. In JJ, rebasing or merging never fails, but it might record a conflict to resolve later. Git, on the otherhand, forces you to drop we everything to resolve conflicts immediately. It sounds like a small thing - but in my experience, being able to resolve conflicts later when I feel like it is absolutely amazing and really helps reduce context switching.
You don't need to switch from git to jj. You just try out jj on your git project and see if it clicks. If you don't like it, you just don't continue using it.
