While it seems like OLPC didn't really achieve the full vision of the project, I have some anecdata of success - my coworker got an OLPC when young (otherwise without access to computers), learned to code on it, and is now an awesome programmer.

Options to disable crash reports and anonymous usage info are presented prominently when Zed is first opened, and can of course be configured in settings too.

Also, if it is only trained on code, it's likely to miss out on all the world knowledge that comes from the rest of the data.

The question is not whether it can work, but whether it works better than an edit tool using textual search/replace blocks. I'm curious what you see as the advantage of this approach? One thing that comes to mind is that having a cursor provides some natural integration with LSP signature help

Yes agentic loop with diagnostic feedback is quite powerful. I'd love to have more controllable structured decode from the big llm providers to skip some sources of needing to loop - something like https://github.com/microsoft/aici

* Way way way more code in the training set.

* Code is almost always a more concise representation.

There has been work in the past training graph neural networks or transformers that get AST edge information. It seems like some sort of breakthrough (and tons of $) would be needed for those approaches to have any chance of surpassing leading LLMs.

Experimentally having agents use ast-grep seems to work pretty well. So, still representing a everything as code, but using a syntax aware search replace tool.

> Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

Beyond the sentimental attachment to the pizza oven, I'd be bothered by the sheer inefficiency of it.

- https://news.ycombinator.com/item?id=28118381 - Supine Computing (2019)

- https://news.ycombinator.com/item?id=21842663 - Outdoor Computing with a Deck Desk

Would be very nice to have durable / repairable noise cancelling headphones. These headphones from fairbuds look great overall, but I'm skeptical of the durability of the hinges.

No fanciness needed, just plain old sum types. It is certainly possible to express those invariants directly in languages with a dependent type systems or refinement types like in liquid haskell - see https://ucsd-progsys.github.io/liquidhaskell-tutorial/Tutori.... It's typically much easier to reason about and use sum types, though.

Of course these examples are trivial and silly, but I see instances of these patterns all the time in big co software, and of course usually the invariants are far more complex but many could be expressed via sum types. I've seen loads of bugs from constructing data that invalidates assumptions made elsewhere that could have been prevented by sum types, as well as lots of confusion among engineers about which states some data can have.

> Field X is only set if field Y is true

Original gnarly C style pattern:

    struct TurboEncabulatorConfig {
        // When true, the turbo-encabulator must reticulate splines, and 'splines'
        // must be non-null. When false, 'splines' must be null.
        bool reticulate_splines;
        struct Splines *splines;
    };

    enum TurboEncabulatorConfig {
        NonReticulatingConfig,
        ReticulatingConfig { splines: Splines },
    }

Original gnarly C style pattern:

    struct TurboEncabulatorConfig {
        // When non-null, lunar_waneshaft must be null. 
        struct Fan *pentametric_fan;
        // When non-null, pentametric_fan must be null.
        struct Shaft *lunar_waneshaft;
    };

    enum TurboEncabulatorConfig {
        PentametricTurboEncabulator { pentametric_fan: Fan },
        LunarTurboEncabulator { lunar_waneshaft: Shaft },
    }

Relatedly, storing booleans is a smell, imho typically an enum or sum type is always better in languages that have concise syntax for these. True and False are meaningless without context, and so can easily lead to errors where they are provided to a different context or generally misused due to a misunderstanding about the meaning.

ref-log doesn't save you in so many situations. As you point out, you have to commit all the time for it to save you. Even then, git repo corruption is possible and then you are hosed.

For example:

* a hard reset clears your working copy changes

* you pop a stash you didn't mean to, atop your working copy changes. Now your working copy changes are intermixed with the stash and you have to manually decouple them.

* you accidentally stage hunks to your index and its tricky to unstage them because they are adjacent to other hunks

Such a tool also saves you from accidentally saving over your work in the text editor. It generally makes it so that you don't need to be as careful.

So, generally, git commands that affect your working copy are not undo-able and can be very time consuming to undo if you have no proper time machine underneath your repo. I happily have experienced the bliss of having this reassurance, but it is only within a proprietary env.

One idea I really like for avoiding VCS operation anxiety for beginners and experts alike is a filesystem layer that allows revert to any historical state. You just have your bash prompt output the current snapshot number, and then can use that as the revert target if there's a botched rebase or so. Unfortunately I do not know of a nicely packaged way to do this, or how to do it at all with OSS tools (but I bet it is feasible!).

There are also some fully wireless split keyboards like the southpaw centromere. I found the thumb keys to be too inward / too few for my taste.

If you want to see more wildness, a couple of my other posts are more unusual:

* https://mgsloan.com/posts/polarizer-glasses/ * https://mgsloan.com/posts/tree-based-computing/

One solution to sun is to use shade strategically - https://mgsloan.com/posts/tree-based-computing/#handling-the...