Ok, and what about the overwhelming majority of reasons to be outside the house, which are not social reasons?

It's a bit silly to abandon all contact with the world just because you have to wait for the doctor, go grocery shopping, sit in the train, etc.

The world got by just fine when answering machines and paper maps were the norm.

What is silly about going to do an errand without distractions? It's more efficient in my experience. I wont look up stuff in the store or answer texts that in reality can totally wait. I've yet to have something happen where not having my phone lead to me missing some big emergency or event.

Going out into the world is in fact the opposite of abandoning all contact, it's directly interfacing. According to your comment, you equated your world with access to your phone.

The world got along fine (better, probably) without the internet, yet here we all are.

> What is silly about going to do an errand without distractions? It's more efficient in my experience. I wont look up stuff in the store or answer texts that in reality can totally wait. I've yet to have something happen where not having my phone lead to me missing some big emergency or event. > Going out into the world is in fact the opposite of abandoning all contact, it's directly interfacing. According to your comment, you equated your world with access to your phone.

I have a hard time believing this isn't a disingenuous take just for the sake of arguing. "Hey honey, while you're at the grocery store, could you pick up some milk?" "Hey, I'm finishing up at the doctor, any chance you want to meet for lunch?"

Are we really saying we can't understand the difference between a computer and a cellphone? Are we really unable to imagine any reason why communicating outside the home can be a useful ability? That the ability to do something doesn't mean it is the only way to do something, nor does it mean it has to be done that way at all times in all situations?

> It's a bit silly to abandon all contact with the world just because you have to wait for the doctor, go grocery shopping, sit in the train, etc.

On the contrary, I find it liberating, and I hate the idea of people trying to compel me to maintain contact through those situations.

It's not really about the editor. The editor (the LSP client) just provides support for telling the server what the user wants a definition for, and how to display that back to the user.

As a simple example, I'm learning japanese so I built a 50-line LSP server that just looks up definitions of a word under cursor in a dictionary. This is an almost-trivial server. Its only capability is to offer definitions when hovering a position in a text document. It works perfectly well in neovim with lspconfig with 2 lines of configuration. I'm sure it would be similarly trivial to integrate in VSCode, Emacs, etc.

Other non-coding uses of LSP that I'm aware of are spell-checking and grammar suggestions (LSP clients can display diagnostics), semantic syntax highlighting (e.g. for highlighting a markdown document), and projects like the one discussed here which just integrate more general-purpose AI.

Like anything else, gradually.

You really don't have to understand any deep wizardry to get started (or, for the most part, even to finish). For the most part, you just look at a specification, and implement what it says. It requires some code architecting skill to not make a mess, but there are common patterns and it becomes a lot easier once you've built one or two emulators.

And you almost never need to understand electronics. You're only emulating behavior. When someone discovered bugs in the behavior of the original hardware, you usually just need to special-case it in your emulator. It might help to know some electronics to understand how those behaviors came to be, but that's more so of historical interest than actually practical.

There are certain unique challenges, but it's nothing too difficult. When there's an issue, you're usually debugging three things at once: Your understanding of the hardware, your implementation of the emulator, and the game you're emulating. It can be hard to pin down the exact problem. But here, I encourage you to just hack something together. It's not clean, but all emulators are full of special cases that try to somehow get popular games working. If a couple unclean hacks mean you can get a game working, just do so. You don't really need to exactly implement the original hardware's behavior. Just get the game working.

libc doesn't really have a concept of containers or iterators. The only container it knows is an array.

The one well-known "generic" algorithm in libc is qsort. But qsort only works with pointers, and so can only sort continuous containers. You can't sort a linked list with qsort. In contrast, the STL has a more general concept of iterators that know how to fetch their next element (and some iterators can do more than just that). This allows the STL to have a std::sort algorithm that works on arrays, linked lists, trees, and whatever other data structure you want to come up with.

So the crucial idea is that the STL provides a large set of algorithms that work on all containers. No matter what kind of weird container you have, as long as you can provide an iterator for it, you can use most of the ~100 different standard algorithms on it. You can sort, find specific elements, partition, find the max element, filter elements, etc.

And the idea also goes the other way around. The STL also provides common containers that you'll need, such as linked lists, growable arrays, associative containers, strings. Of course, all the STL algorithms work with the STL containers.

Then, if you want to write your own algorithm, you only need to write it once in terms of iterators and then you can use it with all the different containers. No need to write the same routine twice.

The last big accomplishment is that all this can be done with almost no runtime overhead. All the types are resolved at compile-time, and generic algorithms can be specialized if you have a more efficient implementation for a specific container. This means that if you wrote a manual implementation of an algorithm that specifically matches one container, it would not be much faster or consume fewer resources than just using the generic STL algorithm. At the time the STL was originally incorporated, I think this was unique and no other language was actually capable of doing this.

Serenity still has Ladybird as it is right now. So I assume that will become the baseline for "Browser" in SerenityOS going forward, and be developed independently. Whatever the browser in SerenityOS will end up looking like though, I doubt it will see much development. The kinds of people interested in working on browsers will just work on Ladybird.

Someone will probably once again port Ladybird to SerenityOS in the future. It won't be part of the main system, but users would be free to install it.

Yes, "our" does not necessarily include you. There is no separate word for an "us" that includes all people.

It's useful to consider the next answer a model will give as being driven largely by three factors: its training data, the fine-tuning and human feedback it got during training (RLHF), and the context (all the previous tokens in the conversation).

The three paragraphs roughly do this:

- The first paragrath tells the model that it's good at answering. Basically telling it to roleplay as someone competent. Such prompts seem to increase the quality of the answers. It's the same idea why others say "act as if youre <some specific domain expert>". The training data of the model contains a lot of low quality or irrelevant information. This is "reminding" the model that it was trained by human feedback to prefer drawing from high quality data.

- The second paragraph tries to influence the structure of the output. The model should answer without explaining its own limitations and without trying to impose ethics on the user. Stick to the facts, basically. Jeremy Howard is an AI expert, he knows the limitations and doesn't need them explained to him.

- The third paragrah is a bit more technical. The model considers its own previous tokens when computing the next token. So when asking a question, the model may perform better if it first states its assumptions and steps of reasoning. Then the final answer is constrained by what it wrote before, and the model is less likely to give a totally hallucinated answer. And the model "does computation" when generating each token. So a longer answer gives the model more chances to compute. So a longer answer has more energy put into it, basically. I don't think there's any formal reason why this would lead to better answers rather than just more specialized answers, but anecdotally it seems to improve quality.

All these decisions add up to people just not replying to interesting questions.

More often than not, nobody will reply, so all threads are just one or two levels deep. Or in the rare case someone actually replies to an interesting point, it's usually not the original poster. Probably because they had no idea that anyone had even followed up on their post.

Requests for elaboration mostly go unanswered, and comments are made expecting no replies. So people just shoot ideas into the void, with interesting interactions only happening when someone famous comments.

I'm not sure either. I definitely remember occasionally feeling a distinct "flow" feeling the first few years I was studying and working. But now I still have periods of similar and superior concentration, but it's not accompanied by any extraordinary feeling.

I'm not even sure nowadays if I really experienced this, or if the feeling is just nostalgia.

I agree that most recipes are terrible. And a lot of them aren't even sensible. As in, if you'd follow them, you'd not really get a usable product out of it. Maybe an overcooked mush, a runny sauce, or just slightly flavored water instead of a broth.

But other than that, I think recipes, especially online, tend to be way too simplistic. The biggest crime is that they use way too few spices. Not the amount, but the diversity. Especially for sauces and marinades. I get that creators have to appeal to a broad audience without specialized ingredients available, but please at least mention them if they would optionally enhance the flavor.

And recipes tend to not mention optional cooking techniques that would make the finished product better if employed. Things like deglazing a pan, blanching vegetables in preparation, specific ways to cut vegetables into appropriate chunks, etc. Recipes aren't really meant to teach you those techniques of course, but sometimes it really makes sense to employ them at the right time. It would be nice if the recipe would at least mention what you can do to improve the quality.