mistercow

Just to tack onto this, the one thing you could do is just deny real rewards. If someone wants you to take part in their pool in order to load a webpage, you could just refuse to submit any block that will actually pay out. This wouldn’t benefit you, but it would punish them for trying to make you spend resources on their behalf.

I wonder if there’s a way to prevent that.

Is there a good source that tracks the performance of these forecasts? I’d be particularly interested in seeing what things looked like in, say, 2005, looking ahead ten years, and then maybe 2008. That would be right before and right after the smartphone boom started, which might be our best recent basis for comparison.

> Still, while it is basically impossible to predict with any confidence what AI will do in 20 or 30 years, one can say something about the next decade, because most of these near-term economic effects must involve existing technologies and improvements to them.

I think you would be hard pressed to find someone who was making adequate predictions about where we would be now back in 2020, much less 2015, and if you did, I doubt many people would have taken them seriously.

I’d argue that we can currently speak with some level of confidence about what things will be like in three years. After that, who knows?

Just to make sure I understand this (and maybe clarify for others too), because my understanding of proof-of-work systems is very high level:

When you mine a block, you’re basically bundling up a bunch of meaningful data, and then trying to append some padding data that will e.g. result in a hash that has N leading 0 bits. One of the pieces of meaningful data in the block is “who gets the reward?”

If you’re mining alone, you would put data on that block that says “me” as who gets the reward. But if you’re mining for a pool, you get a block that already says “the pool” for who gets the reward.

So then I’m guessing the pool gives you a lesser work factor to hit, so some value smaller than N? You’ll be basically saying “Well, here’s a block that doesn’t have N leading zeroes, but does have M, leading zeroes”, and that proves how much you’re working for the pool, and entitles you to a proportion of the winnings.

If you changed the “who gets the reward?” from “the pool” to “me”, that would change the hash. So you can’t come in after the fact, say “Look at that! N leading zeroes! Let me just swap myself in to get the reward…” because that would result in an invalid block. And if you put yourself as the reward line in advance, the pool just won’t give you credit for your “partial” answers.

Is that about right?

What they seem to be claiming is that because the wood itself contains more carbon that is used to produce the turbine, they have net negative carbon emissions before accounting for actual energy production.

That seems pretty dubious to me. After the turbine’s thirty year life, what happens to that carbon?

At any rate, if it’s true that it takes 90% less carbon to produce in the first place, setting aside the whole “wood contains carbon” thing, that’s pretty cool.

I think we need to find a way to teach without grades. That is, we do know how to teach without grades at younger levels, and many schools do it successfully.

The problem is that eventually you need to measure for placement, and Goodhart’s Law kicks in and destroys the enjoyment of learning. It’s very hard to be intrinsically motivated when the external pressure dominates.

The fact that “study for the test” is basically synonymous with “study” for most people is indicative that we’re doing something extremely wrong in education.

> No one to day learns that anymore. The vast, vast majority have no idea and I don’t think people are dumber because of it.

Arguably, the kind of person who was helped by learning to do that by hand still learns to do it by hand, but because of curiosity rather than because a teacher told them to.

I remember being thirteen and trying to brute force methods for computing the square root. I didn’t have the tools yet to figure out how to do it in any systematic way, and the internet wasn’t at a point yet where it would have even occurred to me to just search online. Wikipedia wouldn’t exist for another two years.

I probably finally looked it up at some point in high school. I’m not sure exactly when, but I remember spending a lot of time practicing doing a few iterations in my head as a parlor trick (not that I ever had the opportunity to show it off).

If I were thirteen and curious about that now, I’d probably just ask ChatGPT. Then I’d have a whole follow up conversation about how it was derived. It would spit a lot of intimidating LaTeX at me, but unlike with Wikipedia, I’d be able to ask it to explain what those things meant.

This is the thing I don’t get when people talk about LLMs’ impact on education. Everybody focuses on cheating, like learning is inherently a chore that all students hate and must be carefully herded into doing despite themselves.

But that’s a problem with school, not learning. If your actual, self-motivated goal is to learn something, LLM’s are an incredible tool, not a hindrance.

I mean it’s an explicit violation of that philosophy as noted in the proposal:

> For this reason, the W3C TAG Design Principles recommend against creating APIs that expose garbage collection. It's best if WeakRef objects and FinalizationRegistry objects are used as a way to avoid excess memory usage, or as a backstop against certain bugs, rather than as a normal way to clean up external resources or observe what's allocated.

Fair, I wasn’t aware of that. But even so, there’s a big difference between a wonky feature intended for niche cases and documented almost entirely in terms of caveats, and “this is the new way to dispose of resources”.

And the point that this kind of thing is against the JS philosophy is pretty explicit:

https://w3ctag.github.io/design-principles/#js-gc

Another point there is that JS has always gone to great lengths not to expose the GC in any way. For example, you can’t enumerate a WeakSet, because that would cause behavior to be GC dependent. Calling dispose when an object is collected would very explicitly cause the GC to have semantic effects, and I think that goes strongly against the JS philosophy.

> I don't buy it, no brand can be accurate on energy expenditure because it depends on a lot more things than what the watch can monitor.

You could say the same about virtually every modeling problem, yet the world runs on models that work adequately in practice. You measure what you can, infer what you can, and fill in the gaps with priors.

It’s interesting to me how often papers do this, where even after reading the abstract, it’s hard to tell in what context they’re using key words, and by extension, what the paper is actually about.

My loosely held feeling is that this is also a pretty strong indicator of what you’re going to be in for in trying to digest the rest of the paper.

Or a separate effect where people whose doctors tell them they’re a diabetes risk tend to make a token switch to artificial sweeteners, but don’t take other, more effective steps.

Assuming you’ve framed it fairly, that’s a pretty atrocious point of view for someone calling themselves a privacy expert to hold. A privacy expert should know that backdoors are dangerous to privacy even if you trust the people who are supposed to have the keys.

I wonder if this is a case where you want an encoder-decoder model. It seems very much like a translation task, only one where training data is embarrassingly easy to synthesize by just grabbing sentences from a corpus and occasionally swapping, inserting, and deleting characters.

In terms of attention masking, it seems like you want the input to be unmasked, since the input is fixed for a given “translation”, and then for the output tokens to use causally masked self attention plus cross attention with the input.

I wonder if you could get away with a much smaller network this way because you’re not pointlessly masking input attention for a performance benefit that doesn’t matter.

> We used to get kids to smoke pipes to stave off chest infections because it made “intuitive sense” and it’s only because of observational studies that we now believe smoking causes lung cancer.

This is an interesting example, because I don’t know of any studies (although there probably are some, if only old ones) specifically about whether smoking pipes staves off lung infections, but the “intuitive sense” answer has changed because of adjacent evidence. And in this case, it’s not the lung cancer evidence that makes it intuitively unlikely that pipe smoking would be helpful, but a broader understanding of what causes lung infections, and what tobacco smoke contains and doesn’t contain.

I think it's because the media coverage is all focused on how this means the big AI players have lost their competitive advantage, rather than the other side of the equation.

But that's also dumb, because "huge leap forward in training efficiency" is not exactly bad news for the major players in even the medium term. Short term, it means their models are less competitive, but I don't see any reason that they can't leverage e.g. these new mixed precision training techniques on their giant GPU farms and train something even bigger and smarter.

There seems to be this weird baked in assumption that AI is at a permanent (or at least semi-permanent) plateau, and that open source models catching up is the end of the game. But this is an arms race, and we're nowhere near the finish line.

Has anyone done a benchmark on these reasoning models compared to simply prompting "non-reasoning" LLMs with massive chain of thought?

For example, a go to test I've used (but will have to stop using soon) is: "Write some JS code to find the smallest four digit prime number whose digits are in strictly descending order"

That prompt, on its own, usually leads to an incorrect response with non-reasoning models. They almost always forget the "smallest" part, and give the largest four digit prime with descending digits instead. If I prompt o1, it takes longer, but gives the correct answer. If I prompt DeepSeek R1 with that, it takes a long time (like three minutes) of really unhinged looking reasoning, but then produces a correct answer.

Which is cool, but... If I just add "Take an extensive amount of time to think about how to approach this problem before hand, analyzing the problem from all angles. You should write at least three paragraphs of analysis before you write code", then Sonnet consistently produces correct code (although 4o doesn't).

This really makes me wonder to what extent the "reasoning" strategies even matter, and to what extent these models are just "dot-dot-dotting"[1] their way into throwing more computation at the problem.

Note that an important point in the "dot by dot" paper was that models that weren't retrained to understand filler tokens didn't benefit from them. But I think that's pretty unsurprising, since we already know that models behave erratically when fed extremely out-of-distribution outputs (cf. glitch tokens). So a plausible explanation here is that what these models are learning to do is not output valid reasoning steps, but to output good in-distribution token sequences which give them more time to find the right answer. The fact that DeepSeek's "thinking" looks like what I'd call "vaguely relevant garbage" makes me especially suspicious that this is what's happening.

[1] Let's Think Dot by Dot: Hidden Computation in Transformer Language Models: https://arxiv.org/abs/2404.15758

TypeScript enums were added in large part because union types didn't exist at the time. Those don't require you to write out anything like the above. The only case where you would need to write out number literals like that would be if you specifically wanted the values to be numbers for some reason, rather than interned strings.

In the vast majority of cases, there's no good reason to do that.

Edit: But no, the reason enums in TypeScript suck is not that JS doesn't have them. That wouldn't fix anything other than the type stripping problem. The main reason that they suck is that they use a completely different type model from the rest of the language.

No, this is what I suggest for someone who wants to do something non-idiomatic because they're used to C. What I suggest in most cases is just a string union type.

Edit: But for what it's worth, yes, the above is still more elegant than enums. The syntax may feel less elegant, but among other things, the above does not depart from the structural type paradigm that the rest of the language uses, all for something as simple as an enum.

> Not to mention that you can add documentation to each of the entries.

You can do that with either other solution.

Being able to set up a node project like a web server without configuring or maintaining any build steps is pretty nice.

That doesn't give you a type that you can use for the actual enum values. If you wanted a function argument to take in one of your enum values, you'd still have to use keyof in the signature like:

   function doSomethingWithMyEnum(val: MyEnum[keyof MyEnum])

You could do `val: number`, but now you're allowing any number at all.

Ultimately, the type syntax in TypeScript is a key part of the language, and I don't think it's unreasonable to expect developers to learn the basic typeof and keyof operators. If we were talking about something wonkier like mapped types or conditional types, sure, it might make sense to avoid those for something as basic as enums.

I think that's part of the underlying issue in every case, but then there sometimes seems to be some kind of bug where TS won't agree that the value actually has that nominal type, despite it originating from the enum itself. I usually then can't reproduce these issues with more minimal examples.

Well, that's basically how you would have done it in vanilla JS before typescript came around. The main awkwardness is the type definition. I often prefer to use a library like type-fest for this kind of thing so you can just say:

    export type MyEnum = ValueOf<MyEnumMapping>;

TypeScript not having enough sugar in its built-in utility types is definitely a fair criticism.

But more to the point, the above is not usually how you do enums in TS unless you have some very specific reason to want your values to be numbers at all times. There are some cases like that, but usually you would just let the values be strings, and map them to numbers on demand if that's actually required (e.g. for a specific serialization format).

But why? The feature offers almost no benefit in TS at this point over other existing features, has no function in JS other than TS compatibility, and is increasingly flaky in TS itself. Adding more complexity to JS rather than simplifying TS by deprecating this old, janky foot gun and educating devs on better alternatives seems like moving in the wrong direction.

> Changing values (after a change in an external interface), tracking use and renaming is harder in the first case.

You can rename the elements of a string union with the typescript language server. In VS Code at least, it's just like renaming a variable, and it updates the usages which use the type.

> In the second case, the code can change the value at runtime.

You can always freeze the object if you're worried about that.

I think they also haven't gotten very much attention in the last few years as new features have been added. Nine times out of ten, if I hit a weird case where TS doesn't understand some type that it really seems like it should understand, it involves an enum. And if I rewrite the enum as a union type and update the other code that uses it, my issue goes away.

I agree they should just formally deprecate it.

What in your view is the downside to doing this?

    export const MyEnumMapping = {
      active: 0,
      inactive: 1
    } as const

    export type MyEnum = typeof MyEnumMapping[keyof typeof MyEnumMapping];

So you have the names exposed, but the underlying type is the number.

> Often, I find myself in need to find all references of "Active" from your example, which doesn't work with union values.

I'm able to do that just fine in VS Code / Cursor.

I set up a union like this:

    export type TestUnion = 'foo' | 'bar' | 'baz';

Then use it in another file like this:

    const bar: TestUnion = 'bar';
    const barString: string = 'bar';

If I select 'bar' from the type and choose "Go to references", it shows me the `const bar` line, but not the `const barString` line, which is what I would expect.