mistercow

Come on, now.

> maybe in the future JS runtimes might be able to strip away types for you without a build-step.

You can't backpedal from that to "speaking about the specification". It's not future JS runtimes. It's a thing you can take advantage of right now.

I think the difference is just that (IME at least) those other features seem a lot more rarely used than enums. Enums are a feature that maps onto a common language concept, and which new TS devs reach for because they give first class support to a very common need. And the fact that you can usually do what they do more elegantly with other features is not as obvious, particularly because you can't do it the same way in a lot of other popular typed languages.

Parameter properties and namespaces, on the other hand, are kind of wonky TS specific features that nobody expects to be there unless they specifically find them in the docs. Parameter properties offer a little bit of conciseness but don't fill a pressing need. Namespaces solve a problem that just doesn't actually come up that often, and few devs are going to go actively looking for them. Even the example code on typescriptlang.org doesn't show a very compelling case; they show "Validation" used as a namespace for classes that are already namespaced the low tech way by having "Validator" in their names. (Which isn't to say that the feature isn't ever useful; it's just that cases where someone would actually seek it out are niche.)

All of that is to say that sure, enums are just one of a handful of features that will break in runtimes that simply strip out types, but they're also the main feature that's likely to trip people up.

I’ve also seen them behave very weirdly and inconsistently. There have been cases when I’ve had to explicitly declare that a value has an enum type, even though its type is already one of the enum’s values (and not a literal of the same value, but literally straight from the enum itself).

From what I can tell, they were an early addition from back before TS had unions, and it feels like they live in their own world within the type system. I would go further than saying you should disallow them with a linter, and say that they should be deprecated in the language. Right now they’re just a foot gun for new TS devs.

> Partial seeding of labels, e.g. selecting portions of the incomplete model and artificially limiting the available labels in that area, without collapsing it.

It seems like you if you had this, you could do some really interesting things with multi-scale collapse. For example, you could first use collapse to lay out biomes (e.g. beach needs to border sea, desert needs to border mountains, etc.) and then use those as constraints for the next scale level, which decides the details within those biomes, and the next level for cities and towns within those environments, etc.

I wonder how viable it would be to find a public key your target owns and use it to encrypt the data you send back. Then you could prove to them that you exfiltrated real data without exposing it to anyone outside the company.

Alternatively, you could hash it and say “Look, it’s a sha of your database password hyphen “yougotpwnd””

I don’t think you read my comment correctly.

I’m not sure what kind of response you’re looking for, or if this is a rhetorical question or not. But “how could a language model infer…?” can be asked about a whole lot of things that language models have no problem reliably inferring.

The thing is, it’s only possible to “completely prove something to be true” in math contingent on your accurate interpretation of the steps of the proof and of its outcome.

The proof as a platonic ideal is infallible, but in reality, it gets fed into a fallible meat computer, and in practice, even very smart and careful people do make mistakes, often at the individual level, but sometimes as an entire community.

Two famous examples were apparent proofs of the four color theorem in the late 19th century, each of which were widely accepted for over a decade before being shown incorrect.

We have better tools nowadays, obviously, but these still only increase confidence, which is exactly what running simulations does.

The only way for it to last would be for browsers to compile into some kind of compatibility layer for newer GPU features on older hardware, but that’s probably going to be extremely tough to do in some cases without killing performance on the older platforms, particularly if those features relate to things like synchronization.

I think there is a compelling reason to have WGSL as a separate language (but maybe not sufficiently compelling): WebGPU is a lowest common denominator which can only have features which are in the intersection of its target platforms, and so WGSL has no “dead syntax” to memorize. If the language spec says it’s there, you can use it, and you won’t find examples online of code that just won’t work in WebGPU because of missing features.

Of course, the f16 extension immediately weakens that, and demonstrates that this situation probably won’t last.

The point of running numerical simulations is that when they come out wrong, you learn something. If you simulate this, for example, and get a different answer, you’ve learned that you’ve misunderstood the claim.

In other cases, a numerical simulation giving a wrong answer can quickly tell you that your apparently valid reasoning contains a mistake. That’s really useful, because subtle reasoning errors are really easy to make, and math is full of fun false proofs.

A wrong simulation is strong evidence that you’ve misunderstood something, and so by necessity, a correct simulation is (weaker) evidence that you’ve understood correctly.

I have, on many occasions, thought that I had an analytical solution to a problem pinned down, then checked it numerically and found that I'd made a mistake. It seems weird that there's any hostility towards a perfectly useful tool for checking your work.

Isn’t that, again, specifically a benefit of being purely functional?

I can see some advantages of this kind of editor for specific contexts, like if you’re building a shader, this UI forces you to be purely functional without explicitly teaching purely functional concepts.

But it seems like there’s also a general feeling that this is easier than learning how to code, and I guess my question is… is it? Is this really a better idea than a simple to use API with a DSL (or just a simple language like Go or Lua). Is it just less intimidating to beginners?

You still have to learn the concepts and rules of the system, in addition to figuring out cable management. It seems to make documenting your “code” a lot harder. And now with AI assistants, you’re giving up even more by not working with text.

I haven’t been super impressed with it, and haven’t encountered any practical tasks I wanted to solve with an LLM where o1 worked any better than prompting 4o or Sonnet to use more extensive CoT.

There might be some narrow band of practical problems in between what other LLMs can do and what o1 can’t, but I don’t think that really matters for most use cases, especially given how much slower it is.

Day to day, you just don’t really want to prompt a model near the limits of its capabilities, because success quickly becomes a coin flip. So if a model needs five times as long to work, it needs to dramatically expand the range of problems that can be solved reliably.

It’s weird to me that people look at a technology and then assume from their reckoning that they know all the uses for that technology immediately. Most technological progress happens because someone notices a creative use for something that already exists which nobody else has noticed.

You can have a separation of spaces within your home. I have a home office. The only time I go in there when I'm not working is if I left something there (and it's really nice that "swinging by the office to grab my earbuds" doesn't involve a commute).

As a result, I just don't think of that room as part of my home. I'm never tempted to go in there and use that room for something else. For the most part, it's as if that room only exists during the workday.

This feels like a severe motte and bailey. The motte is “neuron count is not perfectly linearly correlated with sentience” and the bailey is “neuron count has no reliable correlation with sentience”.

The priors referenced in the “technical details” doc (and good lord, why does everything about this require me to dereference three or four layers of pointers to get to basic answers to methodological questions?) appear to be based entirely on proxies like:

> Responses such as moving away, escaping, and avoidance, that seem to account for noxious stimuli intensity and direction.

This is a proxy that applies to slime molds and Roombas, yet I notice that neither of those made the table. Why not?

I suspect that the answer is that at least when it comes to having zero neurons, the correlation suddenly becomes pretty obviously reliable after all.

> You've experienced this mystical thing, and so you know it's true?

Suffering is experience, and my own internal experiences are the things that I can be most certain of. So in this case, yes. I don’t know why you’re calling it “mystical” though.

> They'll convert you to their religion by hook or crook.

I have a lot more confidence in my ability to evaluate arguments than you seem to.

Denying the existence of something that you and everyone else has experienced is certainly an approach.

Look, I’m not going to defend the author here. The linked report reads to me like the output of a group of people who have become so insulated in their thinking on this subject that they’ve totally lost perspective. They give an 11% prior probability of earthworm sentience based on proxies like “avoiding noxious stimuli”, which is… really something.

But I’m not so confused by a bad set of arguments that I think suffering doesn’t exist.

The problem is that the reasoning they give is so vague that there isn’t really anything to argue against. At best, they convincingly argue, in an extremely non-information-dense way, that neuron count isn’t everything, which is obviously true. They do not manage to argue convincingly that a 100k neuron system is something that we can even apply the word “suffering” to meaningfully.

I totally agree that you can’t just do a 1:1 comparison. My point is not to say that a shrimp suffers .05% as much as a chicken, but to use a chicken as a point of reference to illustrate just how simple the nervous system of a shrimp is.

We’re talking about a scale here where we have to question whether the notion of suffering is applicable at all before we try to put it on any kind of spectrum.

Which I referenced and called arbitrary.

I don’t really doubt that it’s in principle possible to assign percentage values to suffering intensity, but the 3% value (which the source admits is a “placeholder”) seems completely unhinged for an animal with 0.05% as many neurons as a chicken, and the source’s justification for largely discounting neuron counts seems pretty arbitrary, at least as presented in their FAQ.

I think this is also a property of relationships rather than just individuals, and for that reason, it's not something that will scale. It's especially fraught when you add someone new to a team that's already very high trust about feedback, particularly if that person is especially insecure and/or has had bad experiences where they felt humiliated by public feedback in the past.

That exact same person might have done fine with public feedback had they been there from the beginning, but you can't just toss someone into an established dynamic and expect them to have the same level of trust as the founding members.

Also -- and this is a thing that a lot of companies/teams who strive for ultra high emotional trust seem to neglect -- some people do act in bad faith. When you lean too hard into the "bring your authentic self" school of thought, you strip your team of crucial emotional protections that corporate environments are designed to provide, and all it takes is one high-functioning person with deep seated personality issues (and that describes a large portion of the general population) to cause serious emotional damage in that kind of environment. Even if you have leadership with the abnormally high emotional intelligence and agility to navigate and repair that damage when it happens, it's going to be an enormous drain on them.

I think first and foremost, using dither patterns is just a lot more authentic to the old black and white visual style Obra Dinn is emulating. Go on YouTube and watch some clips of Shufflepuck Café or The Manhole and you'll see that it's all hand drawn art specifically designed to be viewed in 1-bit, and it's all based on dither patterns, not error diffusion.

Error diffusion may yield better results for converting photos to lower bit depths, but it also makes very noisy looking images where edges are muddied and shades bleed into each other. Bitmap art of that era used patterns because it gave the artist a lot more control over the look.

The goal here is not to minimize PSNR or anything like that, but to give a clear and aesthetically pleasing image. And the goal of Obra Dinn is to do that while also matching a historical style. And if you look at individual screen caps of the game, you can see just how successful that effort was.

Secondly, error diffusion is nonlocal, which makes it hard to implement efficiently on a GPU. With a dither pattern, you can calculate each pixel individually, which is ideal for a shader. With error diffusion, you might be able to do some kind of wacky exclusive scan approach with multiple passes to squeeze some parallelism out, but its almost certainly going to perform worse than a dither pattern.

Finally, locking error diffusion to the camera like he did with the dither patterns sounds even harder than the already difficult work he did to get to a decent level of temporal coherence. I honestly have no idea how you'd do it, because the idea is just antithetical to the entire concept. If you don't solve that problem, I think the result would not only fail to capture the intended aesthetic, but would also be pretty nauseating to look at.

> It can't model the generative process of the humans who created those training set samples because that generative process has different inputs - sensory ones (in addition to auto-regressive ones).

I think that’s too strong a statement. I would say that it’s very constrained in its ability to model that, but not having access to the same inputs doesn’t mean you can’t model a process.

For example, we model hurricanes based on measurements taken from satellites. Those aren’t the actual inputs to the hurricane itself, but abstracted correlates of those inputs. An LLM does have access to correlates of the inputs to human writing, i.e. textual descriptions of sensory inputs.

I also argue that failing to syntax highlight this correctly is a security issue. You can terminate block comments with Unicode escapes, so if you wanted to hide some malicious code in a Java source file, you just need an excuse for there to be a block of Unicode escapes in a comment. A dev who doesn’t know about this quirk is likely to just skip over it, assuming it’s commented out.

I slightly misspoke. The issue was that you wanted shadowing, but because of the lack of declarations, some random inner variable could suddenly reference a variable with broader scope.

For example, you might have an “x” in some inner loop within a function. Then later on, you’d add an “x” earlier in the function, not realizing that that name was used down below. Suddenly the inner loop is referencing that new variable, and there was no way to tell other than the surprising ways your code would suddenly malfunction.

Yeah those examples are compelling.

What might work well is a lint rule to error if a loop expression ends an actual function declaration (i.e. not an inline callback), and the function doesn’t explicitly define a return type. I think that catches almost every bad case, aside from the odd memory leak in really unusual edge cases.