https://acko.net/blog/on-asmjs/

Do you suppose motivated individuals might have used something like this to bury wrongthink at a time when mods insisted such a thing wasn't happening, and even if it was, it was happening to all tribes equally so really it wasn't a big deal?

It's that experts in a field generally agree that what comes out is insidiously hollow garbage.

This isn't a "semi-religious" belief. It's linear token soup and diffusion bakes running headfirst into actual expertise, second and third order effects, refined skill and taste, and so on.

If you actually want to see civilization advance, you cannot rely on machines that merely mash up existing intellectual output while pretending to have expertise.

We already had that in the form of art school avant-gardism. AI is just style transfer of that, with corporate sycophancy and valley hyperbole as a veneer.

Like every other AI tool it mainly seems to exist to produce productivity porn. Summarize the meetings nobody could be bothered to summarize. Write the docs nobody can be bothered to read or write. Communicate as an end, not a means, because the company your work for has transitioned into the dead-weight phase.

- Unified toolbar and titlebar dates from much earlier... it was 10.4, not 10.7.

- The brushed metal look was supposed to be applied to "appliance-like" apps as opposed to "document-like" apps... But Apple was never able to stick to that rule themselves.

There are a few design ideas that always turn out to be bad when implemented, but which designers seem to have to learn the hard way. Transparency is the biggest one, but I guess so is excessive rounding now.

Blaming lack of adoption purely on regressive factors follows the same frame that AI firms set. It isn't very effective satire for that reason.

It couldn't be that there is something essential and elementary that is wrong with the output, no... all these experienced experts are just troglodites and wrong and we should instead tag along with the people who offloaded the parts of their work they found tough to a machine the first chance they got.

There's no such thing as ape coding. There's still just coding, and vibe coding.

Title is misleading.

>Wizardchan, a smaller and misogynistic forum for male virgins

I see the media has learned exactly nothing since the days any of this was relevant. Just apply the usual adjectives until consensus is achieved.

There's nothing more credible than sockpuppetting a dead person to renounce anything related, amirite?

There is nothing about that intro that is offensive. Reading comprehension ought to tell you that "pun intended" is a joke to make the bitter pill that OP wrote garbage easier to swallow.

Which one turns +1, -1, +1, -1, .. into all zeroes?

You ought to know this because the fourier transform of [1 0 1] is a cosine of amplitude 2 on the complex unit circle e^(i*omega), which means the DC quefrency needs to be 2 to get the zeroes to end up at nyquist.

The frequency response H(z) (= H(e^i*omega)) of [1 1 1] on the other hand will have its minimum somewhere in the middle.

Also here's a post that will teach you how to sight read the frequency response of symmetric FIR filters off the coefficients: https://acko.net/blog/stable-fiddusion/

Go look up what a z-transform is, and begone.

For filter sizes > 2, box blurs are ass.

Chicken.

Seriously, the degree to which supposed engineering professionals have jumped on a tool that lets them outsource their work and their thinking to a bot astounds me. Have they no shame?

The reason the filters used in the post are easily reversible is because none of them are binomial (i.e. the discrete equivalent of a gaussian blur). A binomial blur uses the coefficients of a row of Pascal's triangle, and thus is what you get when you repeatedly average each pixel with its neighbor (in 1D).

When you do, the information at the Nyquist frequency is removed entirely, because a signal of the form "-1, +1, -1, +1, ..." ends up blurred _exactly_ into "0, 0, 0, 0...".

All the other blur filters, in particular the moving average, are just poorly conceived. They filter out the middle frequencies the most, not the highest ones. It's equivalent to doing a bandpass filter and then subtracting that from the original image.

Here's an interactive notebook that explains this in the context of time series. One important point is that the "look" that people associate with "scientific data series" is actually an artifact of moving averages. If a proper filter is used, the blurryness of the signal is evident. https://observablehq.com/d/a51954c61a72e1ef

_Especially_ because emotional safety is what Twitter used to be about before they unfucked the moderation.

The Strange Case of "Engineers" Who Use AI

I rely on AI coding tools. I don’t need to think about it to know they’re great. I have instincts which tell me convenience = dopamine = joy.

I tested ChatGPT in 2022, and asked it to write something. It (obviously) got some things wrong; I don’t remember what exactly, but it was definitely wrong. That was three years ago and I've forgotten that lesson. Why wouldn't I? I've been offloading all sorts of meaningful cognitive processes to AI tools since then.

I use Claude Code now. I finished a project last week that would’ve taken me a month. My senior coworker took one look at it and found 3 major flaws. QA gave it a try and discovered bugs, missing features, and one case of catastrophic data loss. I call that “nitpicking.” They say I don’t understand the engineering mindset or the sense of responsibility over what we build. (I told them it produces identical results and they said I'm just admitting I can't tell the difference between skill and scam).

“The code people write is always unfinished,” I always say. Unlike AI code, which is full of boilerplate, adjusted to satisfy the next whim even faster, and generated by the pound.

I never look at Stack Overflow anymore, it's dead. Instead I want the info to be remixed and scrubbed of all its salient details, and have an AI hallucinate the blanks. Thay way I can say that "I built this" without feeling like a fraud or a faker. The distinction is clear (well, at least in my head).

Will I ever be good enough to code by myself again? No. When a machine showed up that told me flattering lies while sounding like a silicon valley board room after a pile of cocaine, I jumped in without a parachute [rocket emoji].

I also personally started to look down on anyone who didn't do the same, for threatening my sense of competence.

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)

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.

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

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