9 truths that computer programmers know that most people don't
macleodsawyer.com
macleodsawyer.com
In my experience, one of the most counterintuitive truths that (good) programmers understand is that security is, in most cases, the opposite of obscurity. It's really hard to explain to a non-programmer that the most secure system is the one that everyone understands perfectly.
I could go on... there are lots more. Like, the mythical man month is something most of us know about now. The deep relationship between randomness and compressibility. Cryptographic hashing. How a single number can be used to represent the answers to a set of yes-no questions. And so on.
>How a single number can be used to represent the answers to a set of yes-no questions.
Now imagine you have a set of questions like that, to be stored for kajillions of items. You can efficiently pack those yes-no questions into a single number for each item. Like, in the unix file permission system, 5 expands out to "let others read this; don't let others write this; let others execute this".
- As a single entity: I usually think in decimal so you could write a "single" decimal number (e.g. 234) and convert it to binary and the 1 and 0 character mean Yes / No.
- As a single character: You could just write a random character (e.g. ॐ ), specifying that is has to be interpreted as a number in Base N+1 and ॐ + 1 = 10. This is useless though.
Um... yeah. Who wrote this exactly? An actual programmer? And what does binary have to do with it? I am a fan of 0-indexing, don't get me wrong, but certainly we don't do it for the sake of efficiency. If anyone knows better let me know, but as far as I am aware it has much more to do with a more natural expression of a set, as well as dealing with pointers whose first element lies 0 elements away.
Update: Fixed the post, I wrote it at 4am, and just pulled that part from another source.
"Who wrote this exactly? An actual programmer? "
start + index * offset
points to `start` when `offset` is 0 (ie, array indexing in C and other languages with 'direct' memory access).Any other reason?
still he might be a programmer, just not a 'real programmer' - some kind of web dev or script kiddie, and therefore knows little or nothing about memory addressing
At the museum of flight in Seattle there is a 747. It's the first 747 that was built and partially taken apart (or never put together in the first place). Halfway down the interior fuselage you can seen the terrifyingly small cable pulleys that transfer pilot commands laterally to the wing control surfaces. The track in which the cable runs seemed not much deeper than the cable itself. If, say, a suddent jolt of turbulence dislodged the cable, something not good might happen. I'm sure aero engineers would say this is how airplanes have always worked and there's no chance the cable will fail. Programmers do the same thing: This is the way the database/web service/storage has always worked and there's no chance it will fail.