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.

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.

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.

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.

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.

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 ". 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.

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 even sure nowadays if I really experienced this, or if the feeling is just nostalgia.

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.

But I think for the vast majority of people, simply having a pet or a partner or a kid does not really tie them to their current situation. It's just about what you value more. Of course all of these ties change the tradeoffs of your choices. But every circumstance in life is a constraint on your choices. And large scale changes are possible even with all those things, should you desire it. There are plenty of people that take impulse vacations, change careers, countries, friends, partners, while having all of the dependents you list.

And if you consider all those tradeoffs and decide change isn't worth it, that's perfectly fine. But I see people use this to state that they had no choice in the matter. No, you had a choice and you chose from a constrained but still massive set of potential life situations. This is simply the one you prefer.

To bring this back to the article:

Take this and keep asking the same question. You’ll get to the root of it soon enough. In this instance, your feeling of being stuck is less about the external circumstances and more about internal barriers—fears, beliefs, and assumptions that keep you tethered to the familiar, however unsatisfying it may be.

If you keep asking the question, but your underlying answer is "It is actually more about the external circumstances than internal barriers", then that's your answer. You're not really stuck, you just made your choices and are where you wanted to be.

Don't get me wrong, I'm fully on board with isolating IO. But why not go the slight extra step and just make it completely pure? You've already done the hard part of purity. The rest is easy.

Then you get all those nice benefits of being generic over async and sync, but can also memoize and parallelize freely, and all the other benefits of purity.

Practically, striking out texts at first mistake also seems like such a fundamentally unworkable solution to me. The first glaring problem is that he says you can easily spot the kind of mistakes that non-native English speakers are likely to commit. But to me that's obviously ridiculous unless you have a more than passing familiarity with the structure of all common languages of the world. I'm aware that this was written in 2005, but nowadays the chance that a given piece of writing is written by a native English speaker is certainly less than 50%. And the ones who are skilled at writing English will have reached some plateau where they can easily communicate with anyone. But that will be below a native speaker's level, and going beyond that is a massive time investment that has no practical benefit for them. Other than being able to talk to John Walker I suppose.

Other than that, I'm also not sure how you would even define proper English beyond "what I grew up learning". And given he would "strike" frivolous things like "xp" (The windows operating system) instead of "XP", it stood out to me that he used the term "on-line", a spelling we would "strike" nowadays.

And finally, given the brain's ability to seamlessly decipher even extremely scrambled words, I feel like the ability to even spot slight misspellings in text is something you specifically have to train yourself to be able to do. That seems like the most profound waste of time, to train yourself to spot mistakes in text you'd otherwise not even have noticed and that would've never impacted you.

Then you compile this with GCC flags that tell GCC to not include a standard library (e.g. compile for bare metal).

Then you link with a very simple linker script that tells ld to put the multiboot header before your actual program.

Then, if you want to run on your own hardware, you change the GRUB config file to load your binary and reboot. Or if you want to run in QEMU, you just load the binary with QEMU. Using QEMU is probably simpler, since you're less likely to run into hardware weirdness at the beginning.

Then, you'd start with just writing to a text buffer, which has a hardcoded address on old architectures (it makes sense to start with an architecture where that's the case). That way, you can print stuff to the screen. That's enough to do a lot of very cool stuff already. After that, you configure interrupts, which you do by hard-coding some function pointers in a table using assembly. Then you use some special instructions to load these interrupt handler tables on startup. Now you can do all kinds of interactive things.

You're right, there's no magic here. It's just lots and lots of work. And there are important decisions to be made about how you design and abstract everything. None of them are hard, but making so many decisions is the very thing that's hard about most programming.

The answer of course is to have lots of programming experience. Which is why building an actual OS to the level of SerenityOS is not something a reasonably skilled graduate would be able to do.

And these aren't advanced concepts, it's just the fundamental programming model for GPUs. It's on the level of "Access memory in predictable patterns, ideally sequentially" for CPUs. Everyone knows now that CPUs like arrays and sequential access. And GPUs like interleaved acccess, ideally in sizes no larger than your shared memory.

I will note though that development on the Jakt language has slowed down significantly. After extremely fast initial development, most Serenity developers no longer contribute to the language. Because everything is done exclusively when the contributors feel like it, development happens in bursts. And right now, Andreas is not actively working on Jakt, so very little improvement is happening there. The main developer working on the language is Ali Mohammadpur, but I don't think he is currently being paid to work on the project. So his contributions are also inconsistent.

And it's not like there' some gigantic combinatorial explosion of apps you have to install. The vast majority of messaging around the world is about 5 apps. Facebook's Messager, Wechat, Instagram, Whatsapp, Discord. Between these, you'll reach the vast majority of the world's population somehow. And then you'll need one or two more locally-used ones like LINE or KakaoTalk depending who you're talking to.

Would you also consider the following Haskell function to not be strongly typed?

    add a b = a + b

It's just that in Haskell's case, this checking is done at compile-time and in python's case at runtime.

But a lot of the QtQuick components and the language itself have weird edgecases that are never documented and probably just simply bugs.

Building reusable components in QML isn't easy. A lot of available properties depend on how you instantiate the component, and it's not always possible to specify exactly what properties you expect to be bound (this is where a lot of the edge-cases that I noticed come in). Components seem to be a somewhat leaky abstraction, especially when used as delegates in views.

And the actual IDE integration of QML into QtCreator is just bad. It's frustratingly slow, loses type information of components very easily, doesn't even highlight properly a lot of the times and has no other advanced integration. It's weird. You'd think such a tightly integrated language could have amazing IDE support, but it just doesn't.