unconed

1) A system that needs _seconds per tile_ is not suitable for real-time anything imo.

The irony is that you explicitly posited your thing as a successor to Perlin noise when in fact, it's just a system that hallucinates detail on top of Perlin (feature) noise. This is dishonest paper bait and the kind of AI hubris that will piss off veterans in the scene.

2) I'm also disappointed that nowhere is there any mention of Rune Johansen's LayerGen which is the pre-AI tech that is the real precedent here.

Every time I see a paper from someone trying to apply AI to classic graphics tech, it seems they haven't done the proper literature study and just cite other AI papers. It seems they also haven't talked to anyone who knows the literature either. https://runevision.com/tech/layerprocgen/

3) >The top level input is perlin noise because it is genuinely the best tool for generating terrain at continental scale

This is a non-sense statement. I don't know what you are thinking here at all, except maybe that you are mistakenly using "Perlin" as a group noun for an entire style of functions.

Perlin has all sorts of well-known issues, from the overall "sameyness" (due to the mandatory zero-crossings and consistent grid size) as well as the vertical symmetry which fails to mimic erosion. Using it as the input to a feature vector isn't going to change that at all.

The idea of using plate tectonics is much better, but, vastly _different_ from what you have done. And btw, every plate tectonics simulation that I've seen does not look convincing. If you treat it as a simple transport problem, the result just looks like a Civilization 1 map. But if you want to treat it seriously, then the tectonics have to be the source of all your elevation changes, and not just some AI hallucination on top afterwards. The features would all have to make sense.

Your abstract states that classic terrains are "fundamentally limited in coherence"... but even to my non-geologist eye, your generated heightmaps seem incredibly blobby and uncanny. This makes me think that a real geologist would immediately spot all sorts of things that don't make any sense. For example, if you added water and rivers to the terrain, would it work, or would you end up with non-sense loops and Escher-like watersheds?

(mostly I'm disappointed that the level of expertise in AI tech is so low that all these things have to be pointed out instead of being things you already knew)

The solution to seeing more Bret Victor-ish tooling is for people to rediscover how to build the kind of apps that were commonplace on the desktop but which have become a very rare art in the cloud era.

Direct manipulation of objects in a shared workspace, instant undo/redo, trivial batch editing, easy duplication and backup, ... all things you can't do with your average SaaS and which most developers would revolt for if they'd had to do their own work without them.

Recently I tried to hack in a feature into Transmission for Mac. All I wanted to do was add a single checkbox per torrent, which corresponded to a property in the libtransmission back-end, but which isn't exposed.

And sorry, but, it was a complete mess from start to finish. Instead of just mapping a boolean value to a state, the entire read and write path was this elaborate game of telephone. In React I would just use something like a cursor to traverse and mutate state immutably, and the rendering part would take care of itself. There was also a bunch of extra code to remember and apply defaults, which in a more functional system like React is generally managed via composition.

One of the article's claims is that the React model is suboptimal because UIs are more stable than it assumes. But this isn't true because the edge cases is what you will end up spending the most dev time on.

A declarative approach lets you achieve N features in mostly O(n) lines of code. When you do things imperatively, you're instead having to orchestrate up to O(n^2) state transitions in O(n^2) lines of code.

The React model is also not that different from immediate mode, which is very popular in games, where performance is important. The main difference is that React has an answer to what happens when you can't fit all the work into one rendering cycle, via memoization and sparse updates.

This gets you similar perf to classic retained mode, but without all the tedious MVC plumbing.

PS: Here's how i use patching as a basis for state management, https://usegpu.live/docs/reference-live-@use-gpu-state

Changes in mood result from changes in behavior.

If you don't feel like doing something you know is good for you, do it anyway. You'll feel better afterwards.

Apple already went through this before with PowerPC -> x86. They had universal binaries, Rosetta, etc. to build off of. And they got to do it with their own hardware, which includes some special instructions intended to help with emulation.

TOML is basically a formalization of the old INI format, which only existed in ad-hoc implementations. It's not really a "language", just a config data syntax like JSON. It doesn't have major footguns because it doesn't have a lot of surface area.

The various features it has for nesting and arrays make it convenient to write, but can make it harder to read. There is no canonical serialization of a TOML document, as far as I can tell, you could do it any number of ways.

So while TOML has its use for small config files you edit by hand, it doesn't really make sense for interchange, and it doesn't see much use outside of Rust afaik.

Event sourcing gives you all the technical overhead of replayable transactions while giving your end-users none of the benefits (e.g. undo/redo). It's purely an infrastructure-level feature that only makes auditors and sysadmins happier.

Because the person whose job depends on keeping the customers happy is not the same as the person whose job depends on making spreadsheet numbers go up.

>The semantics of React code are very different to imperative straight line code.

Yes and all you have to do is learn why those semantics exist in order to do react well.

Unfortunately too many programmers still think they can just mimic other code to figure it out.

The old fogeys don't rely on printf because they can't use a debugger, but because a debugger stops the entire program and requires you to go step by step.

Printf gives you an entire trace or log you can glance at, giving you a bird's eye view of entire processes.

I dunno why people are praising this, because it makes it impossible to do natural scribbles. It's picking the algorithm over the result.

Perfect freehand is the right way to solve this.

It's bizarre that they prioritize parsimony over correctness. Laying out long documents can happen in the background, but shouldn't be deferred to when you actually scroll.

Bouncy animations that overshoot just seem like a bad idea in general. The purpose of a UI animation is to guide the eye, but the bounce explicitly introduces a reversal of motion at the end before stopping.

Easing functions are just very cargo culty. We've had the same basic set that dates from the Flash era. Now there's an Apple variant that's just a parametric version of the same idea, but it lacks guaranteed continuity and it's even harder to control?

Personally I've had far better results using the repeated-lerping-towards-a-target trick, aka a true exponential ease. When stacked, you get a classic LTI (linear time invariant) system, and the math around how those behave is well established.

Classic hand-drawn animation does often use stretching and squeezing to emphasize and to create a sense of anticipation, but that's very different and always dependent on the specific motion. You can't automate that by making everything act like jello.

"What promises were made, by whom?"

Technically true, but practically tone deaf.

WebGPU is both years too late, and just a bit early. Wheras WebGL was OpenGL circa 2005, WebGPU is native graphics circa 2015. It shouldn't need to be said that the bleeding edge new standard for web graphics shouldn't be both 10 years out of date and awful.

Vendors are finally starting to deprecate the old binding model as the byzantine machinery that it is. Bindless resources are an absolute necessity for the modern style of rendering with nanite and raytracing.

Rust's WGPU on native supports some of this, but WebGPU itself doesn't.

It's only intuitive if you don't realize just how huge the gap is between dispatching a vertex shader to render some triangles, and actually producing a lit, shaded and occlusioned image with PBR, indirect lighting, antialiasing and postfx. Would you like to render high quality lines or points? Sorry, it's not been a priority to make that simple. Better go study up on SDFs and beziers.

Which, tbh, is the impression I get from webgpu efforts. Everyone forgets the drivers have been playing pretend for decades, and very few have actually done the homework. Of those that have, most are too enamored with being a l33t gfx coder to realize how terrible the dev exp is.

You mean the same commission that disregarded precedent, to instead exclude right wing members at a time when they are getting more votes?

You're operating under the old left vs right definition when it's obviously shifted towards globalism vs national sovereignty. Nobody believes the left stands for supporting the laborers and their interests anymore.

I made a similar tool that can work on images and the camera. In addition to color picking, it adds moving stripes so you can visually tell the difference between colors you might otherwise not tell apart.

https://unblind.tech

We already have plenty of techniques that are fast enough for classic UI rendering. There is no conceivable bottleneck for the kind of stuff that is on your screen right now. It's not a matter of "doing something quickly" imo, that's an issue specific to the games industry, and largely caused by the need to make entirely custom, animated, textured UIs as a feature for a single product.

What projects like Slug and Vello rather show is that GPU coding remains so obtuse that you cannot tackle an isolated subproblem like 2D vector rendering, and instead have to make apple pie from scratch by first creating the universe. And then the resulting solution is itself a whole beast that cannot just be hooked up to other API(s) and languages than it was created for, unless that is specifically something you also architect for. As the first slide shows, v1 required modern GPUs, and the CPU side uses hand-optimized SIMD routines.

2D vector graphics is also just an awkward niche to optimize for today. GPUs are optimized for 3D, where z-buffers are used to draw things in an order-independent way. 2D graphics instead must be layered and clipped in the right order, which is much more difficult to 'embarrassingly' parallelize. Formats like SVG can have an endless number of points per path, e.g. a detailed polygon of the United States has to be processed as one shape, you can't blindly subdivide it. You also can't rely on vanilla anti-aliasing because complementary edges wouldn't be fully opaque.

Even if you do go all the way, you'll still have just a 2D rasterizer. Perhaps it can work under projective transform, that's usually pretty easy, but will it be significantly more powerful or extensible than something like Cairo is today? Or will it just do that exact same feature set in a technologically sexier way? e.g. Can it be adapted to rendering of 3D globes and maps, or would that break everything? And note that rasterizing fonts as just unhinted glyphs (i.e. paths) is rarely what people what.

>assuming that vaccination would indeed prevent transmission was a good guess based on prior vaccinations.

It wasn't.

First of all, they didn't need to guess, because immunology already knew that there is a difference between immunity in the mucus membranes (which is where respiratory infection has to be fought) versus in the blood. The latter is where the immune response is generated if you get an intramuscular injection. This turns out to be have been immunology 101, as testified by e.g. immunologist Liliane Schoofs to my government. You will also note subsequent efforts put into a nasal version of the vaccine that wouldn't have this design problem. There were, in fact, lies.

Second of all, the net effect of getting "vaccinated" was that people got a green pass to go out during winter time, sit across each other in bars and restaurants, and breathe each other's air, while explicitly believing they were immune, even though they were not. The argument that this was still a net positive seems preposterous and a form of magical thinking, where the people who got the ineffective shot were still somehow better off, even though they were engaging in far riskier behaviors.

The people who didn't get the shot meanwhile were forced to stay inside unless they were recently tested. So the hypothesis that the shots reduced illness by reducing transmission is likely also false. There is ample evidence now of spike protein being produced far longer than was ever promised in some patients, and also signs of immunodeficiency, which means the shots themselves were also not an unalloyed good.

What this thread mostly shows is that "anti-vax" remains a magical word, a dividing line between the Good People Who Believe Science and the Bad People Who Dismiss it. The actual details of the vaccine science are not known, and the story many people tell in retrospect does not hold up to basic scrutiny. They are willing to admit to individual instances of error, overstatement or deception in the management of COVID, but they are rarely willing to put them all together and see how this radically changes the entire picture.

Because what it looks like is an insane lobbying effort of governments and influencers, enormous amounts of public money being spent on shots we didn't need, a huge propaganda effort to silence any dissent as "anti-vax" and "anti-science", and all this because likely it did escape from a lab, and the people responsible for developing and funding it were terrified of being held accountable, and having their field shut down as the irresponsible LARP it was. Following some of these star virologists (e.g. Marion Koopmans) online is quite hilarious, because it is very obvious none of their excuses hold up.

Yep I totally didn't notice it because it's off to the side and looks like some kind of promo box.

The idea that nothing has changed is by itself pretty preposterous. The gender ratio of college students is a big one, for instance, which keeps shifting in women's favor.

Plus, we just came out of a decade and a half of focused and persistent activism. If none of that changed anything, then a big lesson ought to be not to listen to the activists or their suggestions.

If you look at the outline of the paper, something should also stand out. Despite the fact that this claims to be science which examines the nature of how men and women are treated in CS, the ultimate focus is purely on confirming the pre-existing conclusions:

- that when women and men are being treated differently, this is always biased against women and in favor of men

- that it is the fault of men and male attitudes

- that is never the fault of women or female attitudes

In fact, feminism has a great sleight-of-hand that they consistently use for this. When they can blame men, they blame men. But if logic and evidence would require them to blame women, then it's suddenly the fault of "society", "unconscious biases" and "attitudes" whose origin is a mystery.

Just one example. While the paper dedicates a lot of ink to the ills of the "male environment", it does note that women communicate differently, e.g. with more "hesitation", "excessive qualifiers" and "excessively polite and deferential".

If you then go look at what the paper's recommendations are for women to "build confidence" it is to:

- attend classes with other women

- find female role models

- join women's groups

At no point is it considered that maybe women in a masculine environment should instead start acting and talking more like men, if they want the men to include them in their discussions and feel like she is one of them.

So yeah. Not much has changed. Not much will change. Because they keep entering a field full of people who are not like them, and expecting that mere complaints will feminize the whole lot.

Putting AI disclaimers at the end of your post seems like the wrong way to do it. If you feel the need to put a disclaimer, put it at the top. Otherwise, what's the point?

Notice how many of these were created after 2000, when efforts to get women into IT were already in full swing (certainly at my university).

Women have had two decades now to demonstrate that it was the fault of gatekeeping that certain parts of programming remain almost exclusively male (with the giant asterisk of MtF-trans being an oddly prevalent archetype, and thus, really a false signal).

It's sad, but the feminist perspective is to start from the assumption that sexism is the cause, and work backwards from that.

As someone else pointed out: there is no substitute for just doing the work, especially in a field where all you need to do is show up and publish. The barriers couldn't be lower, compared to virtually every other field, but that objective measure is irrelevant because the motivation is to validate a subjective feeling of collectivized mistreatment. The implication is that we are sorely missing out on some unique insights and contributions, and yet, everyone would welcome those insights, if they were there.

If you go look, you can find endless casual declarations about how women are better at communicating, empathizing, judgement and taste... but if there is even a single thing that it would appear men are always going to be better at, then that's treated as a Problem to be solved by complaining about it. This mainly serves to attract attention and resources so they can turn complaining into their job, or at least, a lucrative source of leads and income.

I've written a similar `useDerivedState` hook before, which is basically formalizing the lastValue !== value / setLastValue pattern that the docs teach you.

But there is a major blind spot. The reason you want the dependencies is to reset the state when the outside demands it. But only way you can reset such a state is if the dependency _changes_. So it's not possible to reset the state back to the _same_ value as before.

To do that, you either need to manually manage the component lifecycle with a `key={..}` on the outside, or, you need to add e.g. a `version={N}` counter as an extra prop, to handle the edge case. Except, at that point, it makes more sense to rely on `version` entirely.

The 'proper' solution I've found is to actually write code to do what the policy and etiquette demands. E.g. for a number input, you can't aggressively reformat the contents because that's unusable, but you can check if the current text parses to the same value as before (if it is a valid number). There is no way to hide this sort of nuance with a generic state hook, it's too context-specific.

What is most useful is to treat the bridge between controlled and uncontrolled state as its own wrapper component, e.g. called <BufferedInput>, which has a render prop to actually render the <input> itself. It accepts a `value / onChange` on the outside, but passes on a different `text / onChange` to the inside. Give it a `parse`, `format` and `validate` prop that take functions, and you can clean up a lot of messy input scenarios.

Yes, immutability is a requirement. And if you think that's a "special style of coding" then you probably haven't run into situations where that is a necessity, like optimistic updates with rollback, or undo/redo systems.

Mutable code is code that destroys the paper trail of what happened.

>The point of UI framework is to do the optimization for me

No, the point of the UI framework is to allow you to build applications that work correctly and perform well. The React style of coding is designed to scale up to large applications of e.g. a Figma or Excel caliber, while eliminating entire categories of subtle bugs. If you've never coded something like that, React will seem like it is getting in your way.

>Also if "memo" optimization is that good why does one have to add it manually?

Because the compute vs memory trade-off isn't always free, especially in a world where CPU computations are much faster than accessing uncached memory.

This is the virtual DOM mental model of react, and it is pretty much entirely wrong.

- React doesn't really distinguish between DOM components and your own components in how it evaluates. It's all part of the same "VDOM" tree. Creating and updating HTML tags doesn't flow differently from updating the props on your own components.

- React does sparse updates, starting at the topmost component(s) whose state changed. Frequently this is just one widget or a button. Full tree re-evaluation is rare.

- If a component has the _exact_ same `children` prop as before (`===`), as is often the case with e.g. context providers, because it was assigned by a parent, then React will skip re-rendering the children entirely with no effort from the developer.

- If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before. This means even if your state lives high up in the tree, judicious use of memo can make it zippy af.

TLDR: If your react app is re-calculating the entire tree, you suck at react and you never bothered to learn it. Skill issue, git gud, etc. You're welcome.

I would call this behavior solipsistic: the maker only engages with a caricature of their audience that happens to perfectly confirm their preconceptions, while handwaving away very simple and logical objections from the people in the room.

The weirdest part is them dressing it up as "you deserve better" when they are clearly ignoring their existing paying customers and retroactively stealing back content that was published and paid for.

The excuse that people didn't discover the toggle to skip disturbing scenes is ridiculous: just show it on first launch.

I suspect and wonder whether superhot vr was simply forced to remove this content to get first party promotion on certain platforms, and the reason it sounds illogical is because of Sinclair's maxim: they act like they don't understand because their income depends on not understanding it.

>A bit of a nostalgic read, I bet everyone remembers the first time they tried ChatGPT-4, and the conversations about it at gatherings/BBQs.

No, and no. Never tried it. Nobody in my circles does.

The AI hype bubble illustrated.

People who keep telling me I will be left behind keep not producing all this amazing, flawless, refined software that AI was supposed to build.

Pop quiz: make a 3 columns layout with fixed width header and sidebars, with a sticky footer at the bottom of the page, and which reaches full height even if the main content is shorter than the sidebar, or vice versa... even if the whole page is shorter than the browser. It must work in IE6-8.

Spoiler: you can't.

If that's your take away from the comment, then reading comprehension is dead.

Where in your comment did you mention the IE angle? The effect of lack of dev tools? Where did you mention the boondoggle of CSS2 tables and how everyone had to learn a whole new way of making floats behave? Where did you mention the laundry lists of named hacks that people used to get around browser parser differentials?

You didn't. You wrote the story as it is being told instead of how it happened.

You just don't know what you're talking about.