wlib

That’s very elegant, thanks!

I’ve been working on a very similar sync problem and hit this too. I think the way forward is to use a broadcast channel to elect an individual worker that communicates with all other contexts using the broadcast channel.

The filler tokens actually do make them think more. Even just allowing the models to output "." until they are confident enough to output something increases their performance. Of course, training the model to do this (use pause tokens) on purpose works too: https://arxiv.org/pdf/2310.02226

You can still have a framework-specific render tree that maps to the DOM that tracks changes with signals instead of diffing. We’re just saying that there’s no requirement for diffing algorithms anymore to performantly and correctly reconcile state to the DOM. Keyed children was the last place it was needed.

The biggest benefit to this is that it makes one of the slowest parts of virtual DOM diffing (longest common subsequence) no longer required. After this becomes supported in the mainstream, not even signal-based frameworks will have to include VDOM algorithms. I know this because I remember pushing for this to be supported a few years ago — a nice reminder that the standards are evolving and that nothing stops you from being a small part of the effort.

Next up — DOM parts and standardized signals, unified.

With ~2/3 (and growing) of Earth’s land area being arid, you’d expect there to be a lot more interest in reverse-desertification. It’s pretty well established by now that it’s almost entirely a labor allocation issue given that there’s success stories all over the world [1] (including in the US [2]) to just create earthworks that slow and divert water. Water seems to be the biggest single issue and so many deserts actually get enough of it during flash floods. With how much Elon is interested in terraforming Mars why not just start here?

[1] https://youtu.be/UAmai36XJDk?list=PLoU8oWWwU-06BGLH5y7AMbybv... [2] https://youtu.be/3JyEHdJS94s?list=PLoU8oWWwU-06BGLH5y7AMbybv...

The key is topological sorting of a dependency graph. This can be done implicitly by storing a reactive variable node’s depth once it is created, and just making sure that updates are enqueued in separate queues per depth.

I have a somewhat small implementation that transparently batches updates with queueMicrotask in this library (bruh): https://github.com/Technical-Source/bruh/blob/a829af9df9405b...

My memory says that there’s a “Chinchilla” paper showing how to make the best model with a given training budget. There’s a trade-off between the amount of training data and the size of the model itself. Chinchilla under-training would mean that the model is too big for the amount of training data used. Llama is Chinchilla over-trained in that there is a ton of data relative to the small size of the model.

Note that this is still desirable for inference because you want the most possible training on whatever model you can actually fit in your memory.

Exactly - the twitter thread would be really improved if everyone read an introduction to information theory. There are 1024 bits of information in a kilobit, and that's enough information for 2^1024 unique messages. The interpreter of the messages judges what the message information means, but the Kolmogorov complexity of a message is inescapable - you would need to modify the interpreter to squeeze out more messages (which is nothing more than pre-transferring information to the receiver)

I made a library in which state management started the same way. A simple approach is great for performance-sensitive parts and it's easy to write, but there is very little helpful structure to it. Reactivity fails very easily, consider a dependency graph like this: a -> b a -> c b,c -> d In this case, updating `a` would cause d to be calculated (and reactions run) twice. Also, update batching is absolutely necessary for anything non-trivial.

At least for what I made, I don't think it's too complex for what it provides. It transparently integrates with the event loop and only runs what it needs to, at the cost of (min-brotli) 432 bytes at the moment. Compare the "naive" SimpleReactive with the complete FunctionalReactive version here: https://github.com/Technical-Source/bruh/blob/main/packages/...

I just wanted to use a concrete example of a featural writing system. It would of course not be Hangul if it had to accommodate all phonemes. The other direction to take would be to create a sophisticated (probably ML) model that could enable certain features to be optimized, like speed of syllable recognition. If we are constructing a modern writing system then that would definitely be a good approach.

What about a Hangul inspired version of IPA? https://en.wikipedia.org/wiki/Hangul

I initially thought that “if” should be the obvious choice, ignoring sass entirely. However, it’s clear that “when” makes more sense than “if” given CSS’s interpretation anyways. “if” sort of implies a more “one-time” use like in a template/macro or preprocesser. “when” really captures the temporal invariance of CSS’s conditionals.

I’m on my phone so I can’t really give this the response that it’s owed, but most of what I want to say is that I don’t think we disagree as much as you think. My mention of languages being the wrong approach to general programming is a key aspect of my position. You’re right that DSL’s are usually not a great idea, but that seems like more of an issue with the “syntax-chasing”. The affordances that a syntax forces upon everyone are why it takes a decade to add generics to Go and why macros are even used to begin with. As we see from the various notations used for equivalent math, we probably we be better off encoding the structure as a flexible semantics graph and then “projecting the syntax” however the programmer wants. Keep in mind that what I write is about possibilities more than what you would be forced to do every project. You wouldn’t expect everyone to import random type systems more than you would expect everyone of write and import their own random crypto system libraries. Some of the most popular languages out there have absolutely zero static checks. Would it be so bad to write a Turing complete static check function? Why do we care so much about decidability that we can’t even consider it in useful exceptions? Also, do you think macros a la lisp would be so bad if they had more powerful type systems backing them up and more flexible editors to understand them?

I’m aware of math being entirely useful outside of programming - my little rant is more about how little programming is inspired by math

Very nice; you get to the practical lesson of it in a fairly straightforward manner while keeping interesting tangents where they aren’t distracting.

Somewhat unrelated to this link, but I really think that it’s interesting how much effort we put into the theory side of languages/types - with almost no one in industry applying these lessons. The essence of this is just something along the lines of “What if we unified values with types, so we could have more useful type checking?” We have billions of dollars being spent and thousands of smart people working for decades, who don’t even get to use a proper type system - forget about statically-checked polymorphism or dependent typing. It’s not even as if we lost the ball, we’re running in the wrong direction. It’s almost trivial to bolt on gradual typing to a language. It’s also not too hard to retrofit dependent types (just don’t bother with Turing-incompleteness). The whole point of these type systems is to better model systems, so why not go the extensible route of letting anyone hook into the “type checking” phase? Import affine types (that decades old thing that got rust popular); write your own domain-specific checker, even. It’s so frustrating to see how beautiful ideas just die because we feel comfortable the way things are now. Maybe language was the wrong abstraction to begin with. Sorry to derail, but this feels like the only path to truly popularize the lambda cube as a concept.

Just in case you or anyone doesn’t know, pinch to zoom on touchpads is exposed as just scrolling with the control key held down. You can listen for it with the wheel event and look at the ctrlKey and deltaY properties.

Why do we impose hierarchy so much in file systems? We already allow hard and soft links, so it’s not even a tree anyways. Why not just allow any reference types you want; no name with extensions, but a set of tags. Why not identify files the same way a graph database query identifies nodes?

It is, nix is more declarative than a dockerfile and can even optimize the layers based on the dependency graph. See https://grahamc.com/blog/nix-and-layered-docker-images for a good explanation and https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTool... for all of nix’s container related documentation.

This shows a funny way that the word invent has shifted in meaning. Invent means “found” (almost literally “came upon” in Latin) - yet for some reason it shifted to mean “created” in a sort of “this is mine don’t steal it from me” sense. Then here we are clarifying that we literally mean the actual meaning of the word. It’s interesting that math is considered impossible to have as intellectual property, yet we think somehow that IP law is justifiable for everything else.

Keeping a tiny bounded lookahead is essential for the extremely fast and memory-efficient parsing that browsers want for CSS. Sass, less, &c. don't really have to care about that, and they have the benefit of also being able to completely trust that the user won't give pathological inputs - unlike browsers on the web. Also, I think the standards bodies want to minimize their changes in general, to keep the door open for unexpected changes later.

I made this because I always found modern DOM API's much more flexible, simple, and performant than other UI libraries like React. This really just attempts to cleanly abstract document.createElement() while also allowing for super simple server-side rendering.

You may like this if you are trying to make either a simple static blog or a complicated dynamic web app - and it's super easy and memorable to get started with

  npm install bruh

Yup, at that point it's within the scope of bash's debugger. It shows the command that is actually being run, so it expands globs, shows the command within if predicates, and so on. If bash shows a command that isn't actually about to run, that is a bash bug.

I updated to fix that, thanks for pointing it out. It had to do with echo printing the command with your backspace characters escaped. See if you can break it now, it's interesting how many weird cases exist in tty's.

Not without some modifications, which I did not make because the complexity would get crazy with shell scripting

Dependently typed Golang when??

In all seriousness, it feels like go's reputation of simplicity is at odds with its design. Instead of making a simple and highly generalized core from which anything can be composed, it has a specialized, familiar core that engineers are comfortable with.

When I take this question further, I begin to wonder why we even use text syntax for programming. What if we just had a graph structured programming "language" that is edited indirectly through different projected syntaxes that aren't necessarily monospaced text. Almost like lisp, but translated into different frontend languages, potentially graphical. (Maybe off topic but whatever)

Glad to see this, a great related TED talk by Allan Savory that introduces why this is true can be found here https://youtu.be/vpTHi7O66pI

Say you have a simple expression within your code: 4+3*2. Rather than computing the result at run time, you can reduce (fold) that expression into 10, because it's a simple constant that only needs to be computed once.

That's what I meant