I agree, the only reason LSP exists as it does is for a world running on electron based applications. Plug-ins and application extensions are not new technology and they are nearly universally more efficient in the forms designed and used prior to 2005-ish. I understand why VSCode exists and why it is used so often by developers, but it is certainly a downgrade from more language specific options that could exist.

There are some arguments that do carry water in favor of using a client/server protocol transmitting JSON, in particular, the ability for a nearly complete decoupling of analysis of code and the displaying and editing of that code. Also, LSP was (to my knowledge) the first language/platform/usecase agnostic protocol intended for use in code editors.

I get why this is where a big chunk of developers have ended up, but I do bemoan the lost potential for a language to grab mindshare and popularity on the usability and performance of its tooling and developer experience via-a-vis a custom designed and hyper specific code editor. I mean, Rust and Elm received endless praise for their error messages as a massive boon to developer experience, so it is a facet of language design and implementation that can act as great advertisement. I just hate that the prevalence of LSP at this point precludes custom editors as a first choice in the current zeitgeist.

LSP helps with not having to develop the same tooling in each editor for each language.

This isn’t for Electron app only, but is also helpful for Emacs, vim or helix (especially when they lack said language plugins).

Now, some IDEs provide capabilities for a language far exceeding what can even be implemented in a LSP.

This comment makes no sense. You realize how much lsp is used in other editors like vim/neovim? The existence of lsp is exactly what lets custom editors to flourish. Any language/lsp client can add their own extensions too. Any new editor can come up with it's own way of doing things and implement it on top of lsp, as long as the lsp client supports those extra features then there's no problem. I don't know how you can get it so wrong.

They are not custom editors, they are all the same editor because they have to implement the same LSP protocol.

You don't know what an editor or LSP is, if you genuinely believe that.

Thank you for the link to Watts’ talk. It is a great watch and is certainly a great jumping off point for anyone writing fiction in the field.

It also could be one of the most terrifying talks I’ve ever heard, but since it is eight years old, I am going to just pretend all of the research he mentions fell through and I have nothing worry about.

This being primarily generated leads me to wonder: is there a good source, written by academics or professionals, for this information?

Although I am not interested in using LLMs for much of anything, the theory and implementation (where the implementation is not just use some prepackaged library code) in a comprehensive presentation is not something I’ve seen before.

This book (and the book author's blog) is the best source for learning LLM internals for someone just getting started. It's clear and well-written (by a human!) and goes into much more explanatory detail than this does: https://sebastianraschka.com/llms-from-scratch/

Your comment seems to imply that async/await should be or is in some setting not just sugar for promises. But, I am under the impression the async/await is (and always has been) sugar over explicit promises. Not just in JavaScript but in C#, where the sugar originates, as well.

Is there somewhere that async/await is implemented as a different concurrency mechanism?

They are coroutine state machines in rust and kotlin, and perhaps others.

If you are asking in the context of Idris 2.0 (the current version), ST is not really related.

However, if you mean ST in Idris 1.0, there is a definite correlation. The mechanism that ST used for enabling local mutations was very similar to the mechanism that the typestate pattern in Rust is using. ST was a framework for formalizing State Machines in dependent types which is the mechanism TFA is analyzing.

From a language design perspective I go back and forth on named params. I think the only conclusion I’ve reached is that I am not in favor of them being optional, but I think that is more a concern for implementation of the language and less about how it effects users.

How do you find the feature useful in this instance, I can’t quite picture how that works for typestate pattern functions.

It's mainly naming conventions so functions read more like a sentence, so `send_action(to_cell: X)`.

I feel so seen right now. My partner complains about me closing apps on my phone consistently. I also have to hold myself back from defragging and continually cleaning up my storage drives.

I too am nearly certain that the positive benefits are approaching nil, but I still feel it should be helpful.

> My partner complains about me closing apps on my phone consistently.

I'd be curious to know the reqson why she would care on her own phone and why it would be an issue on someone else's phone?

At least on iPhone, it basically doesn't do anything. Apple aggressively kills all background apps automatically. the "open" apps in the switcher are almost always just screenshots of previously-open-but-now-closed apps. if it was recent, the latest app or two in the switcher might actually be open, but rarely more than that.

Despite this, many of my relatives have somehow learned this habit of opening the switcher and closing all apps when they are done with them.

Android has always been quite vigilant and is prompt to kill off any app at the MFA login screen while I am consulting the Oracle of Authenticator in another task. Thanks Android!

That being said, I dislike having 3 dozen apps open because I simply can’t quickly find and switch to the ones I’m using. So when I enter a new situation, I swipe all the way left, and Clear All apps, to start over with a tabula rasa.

The app I use is gone from the app store, but like Spotlight or the Windows Start Menu > type-to-search (before it got utterly shittified with web search/does it have AI now?), I have an Android app called App Search+ on the bottom left of my Android home screen.

Open it, and it opens a list of recently searched for apps. The focus is on the top search bar (and the keyboard has also popped up), and I can type to find any app I have installed.

i’m convinced the real reason people do this is because they don’t want anyone to see what apps they were using.

If you just have every app in the switcher, it becomes useless too.

This is literally always how iOS has worked. You can refer to the application lifecycle documentation: https://developer.apple.com/documentation/uikit/managing-you...

What point are you trying to make. The documentation doesn't say the OS only keeps a single app process running at a time.

The document is clear that the expectation from the developer is that you need to be ready for your app to be snapshotted and frozen/killed at any moment when it is not on the foreground.

The page you linked to doesn't say that anywhere.

Well, it closes the apps somewhat arbitrarily, but they definitely arent all open. If the most recent app is a resource-intensive game or something it will more aggressively close things. but you can have more open if they are all lightweight apps.

But the switcher shows every app ever opened and tries to pretend these apps aren't being closed. Right now for instance, i just checked and as best i can tell, the last 3 were open. going back any further and i could tell the app had to reload. but i can scroll to the left back forever. the one on the furthest left i easily haven't opened for months

I do this also - but wonder because I'll have some app open, phone gets warm. Close the app and it cools down.

When you die, you will leave behind nice orderly contiguous files. It's thoughtful. hehe

After digging through a recently passed relative’s hard drive (the computer barely functioned so I pulled it) and having to search through years of garbage that where never deleted to find the photos, Word documents, and WordPerfect documents my aunt ‘knew’ where stored there somewhere, this is not an insignificant gift to leave my family with.

I think this is a good argument for the Ticket, however, for the case where these three functions are generically useful, not just used in this specified order, I would write a specific function, just copy-paste of the bodies capturing the required ordering as an implementation detail.

Obviously if you are operating in a wide, concurrent async system then the Ticket and separate function calls is the better mechanism for the ordering.

I know this wasn’t the crux of your post, but do you find that you primarily look at types as puzzles in a majority of your code? I have a fundamentally different view and find other perspectives interesting when thinking about language design.

As a separate point, I think this is an excellent example of making invalid states unrepresentable.

I view types as "the thing that prevents programmers and agents alike from writing bad and incorrect code in the future". They're a way of encoding invariants that doesn't require the programmer to worry about accidentally breaking them (because breaking the invariant will cause a compiler error).

Types are not the only way to encode such invariants. tests (and to a smaller extend lints and agent hooks) are other such mechanisms.

On this beat, I think people really under-appreciate the value of tests that check the structure of code to verify some general property, instead of checking the behavior of particular code paths.

At work, we have an internal system where we use a specific type to pass certain information around. It is extremely easy to construct an (empty) instance of that type wherever it is needed, but that is almost always wrong, you actually have to do the work and figure out how to get a real instance from somewhere. To make matters worse, whether the instance is empty or not doesn't matter in development, but matters a lot in production.

Because agents are lazy, they tend to construct empty instances whenever they feel like it, and there was no immediate feedback mechanism that could tell them it was wrong. It's not something you can easily encode in a type for example. I therefore build one (imperfectly, based on ruff lints), but it solved the problem entirely.

Types are puzzles in a good way.

If you were to design Ikea furniture, you'd make pieces that only fit in to the total configuration the correct way.

Types provide that same phenomenon in programming imo. At the end of the day we are shoveling and playing with bytes so we need to provide handles to these processes which make sure that we can't fit a "square peg into a round hole"

Casey Muratori talk from the Better Software Conference 2026.