3 ms·

"Programming is not telling the machine what to do." What is that called then? I am interested in controlling hardware, whatever that is called. I think Torv

by 3xblah 8y ago

"Programming is not telling the machine what to do." What is that called then? I am interested in controlling hardware, whatever that is called. I think Torvalds once said in a comment that is why he wrote his own kernel. He wanted better control of his hardware. Something like that. "... telling the next programmer what the machine does." You mean what the code does? This sounds like drudgery. I can see why one might be overly sensitive about how source code looks before even attempting to read it. I am just a hobbyist writing programs for myself. There is no "next programmer".

thestoicattack 8y ago
Unless you are writing one-off programs that you never come back to -- which is certainly possible! -- it's possible that "future you" is the next programmer.
- otikik 8y ago
  Bingo.
- 3xblah 8y ago
  That is true. There are some I never edit as long as they continue to work. Others I am continuously editing on a regular basis. Others are really "one-offs" that I keep just in case. If I need them again in the future, I might rewrite from scratch if my learning has changed significantly since the last edit. I have found the best thing I can do for the "future me" is to keep programs relatively small and keep the number of files low. This is one reason I like terseness and the idea of keeping "everything" (almost) on one page/screen. I am just not capable of understanding a large project as deeply as I would like. I thought this paragraph summarises the issue well: "To them, once you've sufficiently studied that screen or two of code, you can understand all of it at the same time. If it's spread out over thousands of files, it's very difficult to understand all of it, which leads to bugs, unnecessary abstraction, and the need for advanced tooling just to work with your own project's code." This is from https://github.com/tlack/b-decoded https://github.com/tlack/b-decoded

by 3xblah 8y ago

thestoicattack 8y ago

Unless you are writing one-off programs that you never come back to -- which is certainly possible! -- it's possible that "future you" is the next programmer.

otikik 8y ago
Bingo.
3xblah 8y ago
That is true. There are some I never edit as long as they continue to work. Others I am continuously editing on a regular basis. Others are really "one-offs" that I keep just in case. If I need them again in the future, I might rewrite from scratch if my learning has changed significantly since the last edit. I have found the best thing I can do for the "future me" is to keep programs relatively small and keep the number of files low. This is one reason I like terseness and the idea of keeping "everything" (almost) on one page/screen. I am just not capable of understanding a large project as deeply as I would like. I thought this paragraph summarises the issue well: "To them, once you've sufficiently studied that screen or two of code, you can understand all of it at the same time. If it's spread out over thousands of files, it's very difficult to understand all of it, which leads to bugs, unnecessary abstraction, and the need for advanced tooling just to work with your own project's code." This is from https://github.com/tlack/b-decoded https://github.com/tlack/b-decoded