We used to call those who would fall for these tricks "script kiddies", as all they know about how to "hack" is to blindly run things others have made.
While I get the difference between creators vs users, in the end we're all users in someone else's perspective.
Maybe you've built your own tools, but that's just applying someone else's library.
Maybe you've built your own library, but that's just using someone else's OS and IDE.
Maybe you've built your own OS, but you're still just applying a language that an actually smart person developed.
Maybe you've developed your own language, but that's just an abstraction of actual hardware activity, which the actual geniuses who tamed silicon built.
Maybe you've built your own hardware, but you're really just applying physical and chemical discoveries that actual smart humans made.
Maybe you've even discovered physical and chemical discoveries yourself! But that's nothing, you're just observing the laws of nature.
Maybe you've created laws of nature yourself, but you're nothing next to your mother, who gave birth to a god.
Otherwise, we can't disregard that there's a spectrum here, and somehow move the "goalpost of lol" all the way to the extreme end. You get to be smug at anyone who is on the "more naive" side of you on this spectrum.
Sounds like GP is just remembering and recalling the days when they were more sophisticated than most.
Tangent: the language isn't an abstraction of the hardware. Hardware has nothing to do with programming languages per se. This is why I dislike the term "low-level language", as if this were some kind of computational atomism. There is no inherent relationship between assembly and C++, for example. C++ is a language, full stop. But if we want to simulate a language on a particular piece of hardware, we must simulate it using the language of the hardware. We must translate it into the language of the hardware. That is, after all, what a compiler is: a translator.
Programming languages were designed to do useful stuff. They can't do this without hardware. There are always concerns of practicality.
> as if this were some kind of computational atomism
NAND gates are computationally atomic, IMO, since to go a level below them you get to the level of physical processes (e.g. electronics) that implement them.
Programming languages are formalisms, and formalisms predate machines that simulate them, even if programming languages only really took off with machinery able to simulate them. You can simulate a programming language entirely with pen and paper if you wanted (tedious, but possible; the lambda calculus was entirely theoretical when when conceived). Regardless, while the utility of programming languages is related to there being machines that can simulate them, the distinction remains.
> NAND gates are computationally atomic
They're an implementation detail of the hardware being used. There is no necessarily relation between a language and a NAND gate. It is not as if, by dissecting a language, you will discover a bunch of NAND gates bounding around underneath. A language doesn't reduce to NAND gate operations. It just so happens that NAND gates are incredibly useful for implementation and simulation. You can implement a fully mechanical computer, or a water computer, if you wanted, even if it isn't very practical.
Software is a mental construct that hardware can simulate.
A script kiddie would only know enough to be dangerous, how to download and run the prepackaged kit, and wouldn't understand how/why it works or fails.
Whereas a seasoned cracker may apply the same tools in a systematic way that's informed by knowledge of the underlying concepts, and how to make the most out of options, and adapt to particular targets.
I never thought about it before, but now I’m contemplating it