A jackhammer is like a codegen tool, or maybe a code formatter: it “writes” or “edits” a lot of code for you, quickly, but it’s not doing
programming per se. You can’t use a jackhammer to put together the pieces of a lacquered cigar box,
faster. You can’t use a jackhammer to
build much of anything, really.
(But I should note that a jackhammer also doesn’t required a powered exoskeleton to wield. The power is instead “built into” the jackhammer itself. Less like an IDE; more like a batch command-line tool. I’ve got nothing against batch command-line tools! But their presence is usually orthogonal to the design quality of a language, so they’re kind of irrelevant here.)
Back to the point: programming is something human minds do. Not by holding the whole codebase in your head at once; but by loading and unloading parts from your mind, where at any given time you need a useful amount of mental-model loaded at once in order to see your way through to changing it. (This is why structured programming using macro-assemblers was a revolution in productivity: modules, functions, and block-statements are intuitive units to be mentally loaded/unloaded as a whole, freeing programmers from needing to keep an unbounded mental buffer of JMP spaghetti.)
The more high-friction the language, the less of it can fit in your mental buffer at a time, and so the more “cold lookups” your mind will suffer, where you need to look something up about the codebase (likely evicting something else in the process.)
Consider a process running on a computer without enough memory to keep the entire process’s hot state loaded into said memory at a time. The result is swapping: a slow, high-overhead process of constantly reloading state from disk and evicting other state in the process.
On computers, we can fix swapping by adding more memory—enough to comfortably hold the hot state. But human minds can’t just be upgraded like that. Rather than making our memories bigger, we have to make the state smaller — to pack it more tightly and efficiently into our memory. A low-friction language is one that packs better.
Using an IDE to paper over the problems of a high-friction language, is like seeing a computer system that’s swapping, and “fixing” it by replacing its slow HDD storage with fast RAIDed NVMe storage. Sure, performance increases. But the program is still doing something stupid — a bunch of needless swaps-to-disk. It’s just doing them quickly. The money that had been spent on that RAIDed NVMe storage, could have been much-better spent on just adding more RAM to the system.
And the effort that a human goes to to learn an IDE, could have been much-better spent on learning a language the mental model of which packs better into the human mind.