scratcheee

“Newfound”? People have been fighting this debate for decades. I remember having this exact debate at school 20 years ago, except the price arguments back then were bullshit, but people didn’t care enough about the environment so there wasn’t any pressure to change.

Nowadays the price arguments are… complex. But for the first time people actually care enough about the environment that nuclear is no longer competing poorly with coal (except for in Germany).

The exact maths on comparing pricing is complicated, given that energy storage costs vary so much depending on the inputs (try looking up storage costs for a 100% solar/wind grid during a once in a decade lull, it’d make nuclear look great, but obviously for a slightly mixed grid and more typical conditions, storage might be reasonably priced vs nuclear).

Anyway, I’m mildly disinterested in nuclear now that it’s only a side show to renewables, but I think it’s far from being a slam dunk either way. If some country or politian is more interested in nuclear, fair play to them, I say go for it. We’re not in a comfortable position right now so any movement away from fossils is a win regardless of where we end up (within reason of course)

No doubt the debate will only be resolved once and for all once fusion turns up and actually makes fission genuinely irrelevant (even then, fission might be cheaper for quite a while).

Only everyone who goes bankrupt, and their creditors.

Rather the opposite for their customers.

I’m sure there’s a few cases where this would excessively hurt a company’s prospects (perhaps where a company has an innovative software product with a thin hardware component), but in the majority of cases losing access to the software of a hardware product as an asset is a relatively small loss, and the benefit to consumers is pretty huge. I’d support the trade off.

I’ve met humans who do that too

That argument works pretty well for any bad api design (assuming sufficient documentation somewhere).

Yet I assume we can agree that regardless of how you can work around bad apis, good api design that prevents misuse is always better.

The safety measures have to stop somewhere of course (short of an api that is a single function which does exactly the thing you want without inputs or outputs, which seems unlikely), but extending type safety to interfaces does not seem like a step too far.

I agree with most of this, but I’m not sure about tracking the size metadata becoming a required task for the caller.

The cost of storing the size of every allocation is relatively high, at least some of the time, where it isn’t implied by the usage. Meanwhile the caching system for allocations can store it very efficiently, a block of 4KB of 8-byte allocations will contain over 500 allocations that can all share their metadata. Once they’re handed out by the allocator their shared origin is obscured, so they’d need individual tracking.

I do acknowledge that when size is inherent to the context (new or allocating for a specific struct) then maybe an allocator that doesn’t track size could allow for some clever optimisations, though I’m doubtful it could overcome the loss of shared metadata, which is so much more efficient.

One potential value of CC today is as a final and most flexible solution. Even with the limited and experimental technology of today, which is obviously economically insane, we have a way (with enough money) to make anything carbon neutral. The value is not that we actually do that (humanity cannot afford it, in general), but instead to give us the number to beat, the correct carbon tax, the absolute cost of failing to decarbonise.

It’s easier to justify improved efficiency when the cost of spilling carbon is a big number of dollars rather than a tiny slither of a global problem.

That said, I do agree investment should be limited, it’s obviously only going to be the “best” solution in the rare circumstance that there is no good solution.

I actually disagree, if it can be shown to be safer overall then I don’t think it should be required to be a strict superset of human abilities.

AI will always behave differently to human cognition, we should expect them to have different illusions and different failure cases. That doesn’t mean worse, if they perform better than a legal human driven car on average then I don’t think there’s a justification to exclude them.

That said, they will probably have to be _significantly_ better than human drivers in order to survive the media and public perception, so this might be irrelevant in the end.

I think the value in art like this is that it isn’t a matter of skill but of dedication. Should art be something that only the 1% most skilled and well trained artists can ever hope to be celebrated for?

giant tortoise was meant to be delicious, not considered ethical or practical these days

Whilst I won’t deny that incompetent leadership and planning are involved, I think there are structural reasons for the game industry being uniquely problematic.

Games have massive cost efficiencies from scaling. Studios are incentivised to always make the biggest games they can with their budget. Games team sizes vary strongly with the project period. They can’t handle more than a small team early and can absorb almost any number of people at any skill level before release.

End result is that game development is always boom and bust. Small core teams build a game up slowly, then more and more are added until just before release when a mad scramble for anyone and everyone they can be bought borrowed or stolen to get the game released on time. Then there’s no work except for the core team on the next game.

The obvious solution is to have many games running in one studio to even out the team sizes and absorb the crunch, but that implies either studio sizes beyond anything we see currently (and no increase in per project scope) or much smaller scope for games.

I’ve seen models like they work, and be much less painful to work with for everyone involved, but it did require different market conditions to justify the alternative model, I’m not sure the entire industry could switch.

That’s not to say fixing the problem is impossible, just that the bad incentives will always be there to push back against improvements..

Einstein already has special relativity, his legacy is safe. let’s give general relativity to someone else who had a similar idea 20 years later.

I found the preceding argument more compelling.

Actually took them longer than that even.

They had to invent the computer first, and before that they had to create a universe capable of sustaining both life and computers.

Yeah, pretty dubious phrasing. On the other hand, "protect food heritage" is so obviously a reframing that I didn't even concider that as the whole story.

7. People wanting to get home from the pub legally and safely at 3am.

any part of OOP that is "unique to the oop style" and not used by other programming paradigms is going to be the worst part of OOP.

OOP has been around long enough that all the good ideas have been borrowed/copied/reinterpretted/stolen many times over. Any ideas that managed to remain unique to OOP all this time must have sucked.

All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me.

It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further.

The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal.

It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.

>most of that complexity could have been avoided with a better language design

Are you saying that the ownership/borrowing model for memory safety was a poor choice, or that it's possible to make a language on that model that has vastly less complexity than Rust?

Because your phrasing implies the second, but I don't think I've ever heard anyone make that claim before (presumably because there's no such language lying around anywhere, so it seems hard to defend).

If the first, then I'd point out that wouldn't be a language design flaw, but rather a flawed goal (ie a goal that proved too complex to achieve) - their goal was a memory safe language that didn't rely on a GC, and the resultant design complexity is basically the best example of a way to solve for that goal so far. I'm sure there will eventually be simpler options, but I don't think you can blame designers for not having access to undiscovered techniques. That's what most anti-Rust arguements boil down to.

If you just mean you don't like the syntax, then yeah, I agree, it's a bit alien for me too, but I hardly concider that anything beyond personal taste and the difficulty of learning something new.

That does seem sensible yes, I'm also not particularly interested in preventing people from doing stupid things to their cars if they're that insistent on doing them, it just hurts everyone else.

I guess the problem is how to encourage manufacturers to ensure their emissions functions remain high quality. If the _only_ feedback is customers eventually getting failed inspections and thus higher repair bills eventually, which presumably then leads to them complaining about the cost of the cars maintenance, that's a pretty weak feedback loop compared to direct punishment for producing products that fail emissions checks.

The problem is that once you punish manufacturers more directly they start installing these braindead systems in self defense, after all, if nobody can drive their cars when they're broken then they can't be punished for failing emissions checks.

I guess you could just forbid them from blocking customers at the same time as you punish them, but that's a little unsatisfying.

Maybe just require a way to detect modification or emissions override, and anyone who does that pays the fine if they fail inspection, and for anyone else the manufacturer pays. They'd presumably be begging people to install modifications so they can hand off any fines...

Out of curiousity, what solution do you think would work (assuming you accept that enforcing any sort of emissions standards is a good idea overall).

My best attempt: perhaps as long as systems to maintain emissions standards have failed, the vehicle could be made to pay a fine per X miles travelled that approximates the cost of correcting either the actual emissions of that engine or if such data is unavailable, a plausible worst case emissions of the engine. At a vague guess I could see that being $250 per 1000 miles or so (simplifying emissions to be "4x typical CO2 emissions of a van", which could be way off, and current best-case DAC costs to undo the damage ~$250 per tonne).

That's still a fairly steep fine, but at least it isn't artificially limiting the vehicle.

I've yet to see a normally configured browser _not_ be uniquely identifiable many times over through fingerprinting.

At some point it feels like trying to drain the ocean with a cup. Maybe we just need to accept that anyone who really wants to fingerprint you _can_ fingerprint you unless you use a specialist browser.

At that point the solution is fairly obvious, make it legally difficult to use unique fingerprinting and move on (ie stuff like gdpr). People will still do it, but they'll have to balance it with not falling foul of the law and wont be able to abuse it too much.

We wont stop real world facial recognition by all trying to make our faces more similar either, we have to accept it's generally possible to do, but discourage the actual doing of it rather than trying to make it impossible.

(note in both cases, actually preventing it when you have a reason to is totally possible and valid, via specialist browser modes and physical masks respectively)

It's generally true to be fair, reference counting could be used for every garbage collected language (and be much simpler). The only reason they switched to more complex schemes is they're faster on average. Even smart schemes that try to remove unnecessary ref count changes will tend to underperform compared to a (well built) tracing GC. As for a reference, https://en.wikipedia.org/wiki/Tracing_garbage_collection#Per...

The point about predictability is totally valid though (and combined with simplicity is the reason many languages still pick ref counting).

Technically yes, but if you only use it when you need it, it's often not a performance concideration.

And for systems programming, the often overlooked truth is that people care far less about perfect performance than they do about control - ref counting doesn't give up control to a mysterious oracle running in the background which may or may not wreck your performance in hard to predict ways, it just pays a known cost at the time you use it based on how you're using it. (that's not to say performance is irrelevant, but it's not always the top concern, and with control you can always rewrite slow code as needed).

The obvious question is "why can't we have an optional modern garbage collector built into a systems language?", and it's a good question (I remember reading there was one in rust for a while during early development, but it got removed), I think the main reason is that high quality garbage collectors are incredibly complicated, with many trade offs, and a gc that combines well with the rest of a language and various alternative memory tracking solutions is harder than most. The projects that really want one can always implement their own and choose their own tradeoffs, so there's not many use-cases where a generic language-provided one would justify the complexity of implementing it within the language.

The textual information of all books ever written is around 10s of TB.

So if the goal is to store all books for a rainy day, you can buy a grand of storage or you can build the largest library on earth.

That said, a few books would be wise in case of severe energy loss (it would have to be very severe to make running something like a kindle prohibative, but if we're playing doomer then I'll accept a couple of shelves would be sensible).

I believe they do not alter the colour in the region being focused on, they're trying to take advantage of the fact that our peripheral vision is primarily rod-based, and thus unable to discern colour.

So in theory, assuming the display can keep up with eye movements, it should never show you a tightened or limited colour range that you are actually capable of detecting through your eyes.

I suspect it'll be subtly detectable in a couple of ways though, either through rapid eye movements (though I admit I have no clue how fast eye tracking/screen response can be), and secondly (more confidently) that your nose will shine green in the reflected glow of all the green pixels they're cleverly shining where you can't see them directly, and you can definitely see your nose.

>the person writing about the new discovered weird trick almost always fails to precede the article with a big, red, bold "Please don't ever do this"

> It's has been explained enough times. It's just that looking things up for yourself seems to have gone out of fashion.

It appears you've countered your own complaint.

Whilst your point is fair, I do think the fitt's law benefits are pretty huge (ie the infinitely extending target because it's across the screen edge).

It really depends on usage patterns I guess. If you have lots of _really_ small windows then your point is entirely correct, but if people are using large windows then it becomes less clear - there's a fair chance they're moving almost as far to reach the edge of the window for the in-window menu bar, but not benefiting from the screen edge infinite target, at which point the macos model becomes superior.

The thing is I suspect the cut-off applies even for half-screen windows these days, I think the benefits of screen edge scale better than the benefits of window edge (since you can always move faster if you don't have to aim well). On the other hand, I guess there's an upper limit to practical window size, regardless of how large screens get.

The rich/poor divide does indeed exist and has always existed, but that floats separately to the poverty divide. changing one does not change the other. Imagine an ancient communist utopia where all the bread is split evenly - and the 20% who aren't making bread spread their more interesting items across the population equally. Maybe you'll get some nice pottery. By any modern measure of poverty, you have created a utopia of poverty, everyone would be below the modern poverty line.

The rich of ancient times had to scrape their wealth from the labour of _so many_ people.

Meanwhile, if we tried applying the ancient poverty line to a modern rich society, we'd have trouble defining it clearly, even homeless people might sit above it, it barely makes sense.

There's no doubt they help the poor a _little bit_ .

The question is whether there exist alternative solutions that help the poor a lot more by not wasting so much helping the rich (or especially in this case - those buying and selling fossil fuels, industries we'd prefer to be slowing down rather than encouraging with tax breaks).

Eg if the same money "spent" on this tax break had instead been a invested in raising the minimum income tax ceiling, benefits, and pensions (by equivalent amounts), it would presumably have gotten more money into the pockets of those most hurt by fuel inflation, which was the claimed goal of the change, but done less to benefit the fossil fuel industry and those who don't really need tax breaks.

Or to go more extreme you could add an untaxed fuel ration (there is a shortage after all), paid for by higher taxes on extreme usage, thus reducing overuse and increasing affordability at the same time. But that's practically communism, so can't possibly be done (to be fair, it'd be very expensive to implement, so not sure it's a serious suggestion).

It would be a lot simpler if anti-competitive behaviour only encompassed clearly immoral and unfair behaviour, but it tends to be more nuanced than that. There's no simple rule and a court would probably have to spend a long time concidering such a case.

The essential facilities doctrine might apply (the question isn't whether competitors are literally forbidden from the latest chips, it's whether they're "practically or reasonably" unable to access the latest chips, and all evidence suggests that's currently the case). Possibly it's the competitors own fault for refusing to pay the entirely reasonable price TSMC is insisting on, and perhaps Apple's contract with TSMC actually has carefully written clauses to ensure others could practically gain access without having to spend enormous amounts of money, but which nobody has been willing to use for their own reasons, but it certainly seems possible that the contracts effectively ensure Apple have sole access to the latest hardware, which would line up neatly with the apparent scenario we're in - that Apple currently has sole access to the latest hardware.

That's not to say it's a slam dunk case either. I wouldn't care to guess either way.

The <marquee> shall scroll again.

Needs some <blink> to be True Art though.