4 ms·

> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately

> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. Ah, like a jackhammer? One of those huge ones attached to a digger they use to break open the roads? It’s a right-tool-for-the-job kind of thing. Some roads can be mended with a shovel. Some need a jackhammer. If you limit your development to “what a human being can hold in their head” you are artificially limiting yourself. The whole reason we use higher level languages is so that the machine can exceed what a human can hold in their head.

derefr 6y ago
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.
- shadofx 6y ago
  >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. It is organizationally costly to upgrade the human brain to increase RAM. Much cheaper to increase HDD storage through rote memorization and even more cheaper to access External storage on StackOverflow. That is where Verbosity helps, to signal when to stream certain Paradigms into your active memory, and keywords to use when searching for answers online. A 4mb Language can't run on a 3mb brain, so the efficiency it offers at compressing your mental model is useless. But if you have a 1mb Language kernel that dynamically streams 1mb of Paradigms at a time, and then uses the last 1mb to work on the code, then you are capable of functioning.

derefr 6y ago

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.

shadofx 6y ago
>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. It is organizationally costly to upgrade the human brain to increase RAM. Much cheaper to increase HDD storage through rote memorization and even more cheaper to access External storage on StackOverflow. That is where Verbosity helps, to signal when to stream certain Paradigms into your active memory, and keywords to use when searching for answers online. A 4mb Language can't run on a 3mb brain, so the efficiency it offers at compressing your mental model is useless. But if you have a 1mb Language kernel that dynamically streams 1mb of Paradigms at a time, and then uses the last 1mb to work on the code, then you are capable of functioning.