| ▲ | godelski 2 hours ago | |
There's a balance of levels of abstraction. Abstraction is a great thing. Abstraction can make your programs faster, more flexible, and more easy to understand. But abstraction can also make your programs slower, more brittle, and incomprehensible.The point of code is to write specification. That is what code is. The whole reason we use a pedantic and somewhat cryptic schema is that natural language is too abstract. This is the exact reason we created math. It really is even the same reason we created things like "legalese". Seriously, just try a simple exercise and be adversarial to yourself. Describe how to do something and try to find loopholes. Malicious compliance. It's hard, to defend and writing that spec becomes extremely verbose, right? Doesn't this actually start to become easier by using coding techniques? Strong definitions? Have we not all forgotten the old saying "a computer does exactly what you tell it to, not what you intend to tell it to do"? Vibe coding only adds a level of abstraction to that. It becomes "a computer does what it 'thinks' you are telling it to do, not what you intend to tell it to do". Be honest with yourself, which paradigm is easier to debug? Natural language is awesome because the abstraction really compresses concepts, but it requires inference of the listener. It requires you to determine what the speaker intends to say rather than what the speaker actually says. Without that you'd have to be pedantic to even describe something as mundane as making a sandwich[1]. But inference also leads to misunderstandings and frankly, that is a major factor of why we talk past one another when talking on large global communication systems. Have you never experienced culture shock? Never experienced where someone misinterprets you and you realize that their interpretation was entirely reasonable?[2] Doesn't this knowledge also help resolve misunderstandings as you take a step back and recheck assumptions about these inferences?
Because, as you should be able to infer from everything I've said above, the problem isn't actually about randomness in the system. Making the system deterministic only has one realistic outcome: a programming language. You're still left with the computer doing what you tell it to do, but have made this more abstract. You've only turned it into the PB&J problem[1] and frankly, I'd rather write code than instructions like those kids are. Compared to the natural language the kids are using, code is more concise, easier to understand, more robust, and more flexible.I really think Dijkstra explains things well[0]. (I really do encourage reading the entire thing. It is short and worth the 2 minutes. His remark at the end is especially relevant in our modern world where it is so easy to misunderstand one another...)
[0] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...[1] https://www.youtube.com/watch?v=FN2RM-CHkuI [2] Has this happened to you and you've been too stubborn to realize the interpretation was reasonable? | ||