- #1
BicycleTree
- 520
- 0
I've been thinking about object oriented programming. It's not new to me, but I've been thinking about it, especially since now I am doing more projects with many different objects to keep track of.
It seems to me that with object oriented programming, you have to know what are essentially special passwords in order to do anything. Certainly doing things becomes easier once you know the "passwords," but without the passwords you can barely do _anything_.
So how about a move to more "basic" ideas: where you program based on certain simple rules in an environment of simple rules, at a pretty low level. This does not have to be a low hardware level, but at least a fundamental level of abstraction that you can build the other things out of. Eight years or so ago I got a book on writing C games for DOS, and pixel-by-pixel to the screen was understandable. Sure, you built methods on that (mainly at that stage it was the book making the methods, I would just use them, but that's not the point) so that stuff didn't take so long to write, but basically there was a substrate that you could return to; you had a "big picture," i.e. pixels on the screen, that everything was based on, conceptually.
I think it might be good to start with a very low level, or somewhat low level, and incorporate more objects and functions only once you know what you're doing. That way you would nearly start out knowing how to do everything, and all the rest of learning would just be learning shortcuts. Like a single, unified abstract data type, moderately high-level but without having too many distinct parts to understand in a few sittings, and incorporating the whole computer under its wing. Probably memory I/O. Generalize first... then make objects.
These are just some probably under-informed ramblings. I need to understand the computer better. At least, I think that OOP should be taught from low-level up, so if it is the easiest eventual way to program, at least it would be based on a firm understanding of the operating system and hardware from step 1. I need to learn more stuff about this. Anyway...
How many different basic system-style objects, like for file I/O, user I/O, networks, graphics, do you have to know to be an effective professional programmer? Not counting meta-objects like ADTs.
It seems to me that with object oriented programming, you have to know what are essentially special passwords in order to do anything. Certainly doing things becomes easier once you know the "passwords," but without the passwords you can barely do _anything_.
So how about a move to more "basic" ideas: where you program based on certain simple rules in an environment of simple rules, at a pretty low level. This does not have to be a low hardware level, but at least a fundamental level of abstraction that you can build the other things out of. Eight years or so ago I got a book on writing C games for DOS, and pixel-by-pixel to the screen was understandable. Sure, you built methods on that (mainly at that stage it was the book making the methods, I would just use them, but that's not the point) so that stuff didn't take so long to write, but basically there was a substrate that you could return to; you had a "big picture," i.e. pixels on the screen, that everything was based on, conceptually.
I think it might be good to start with a very low level, or somewhat low level, and incorporate more objects and functions only once you know what you're doing. That way you would nearly start out knowing how to do everything, and all the rest of learning would just be learning shortcuts. Like a single, unified abstract data type, moderately high-level but without having too many distinct parts to understand in a few sittings, and incorporating the whole computer under its wing. Probably memory I/O. Generalize first... then make objects.
These are just some probably under-informed ramblings. I need to understand the computer better. At least, I think that OOP should be taught from low-level up, so if it is the easiest eventual way to program, at least it would be based on a firm understanding of the operating system and hardware from step 1. I need to learn more stuff about this. Anyway...
How many different basic system-style objects, like for file I/O, user I/O, networks, graphics, do you have to know to be an effective professional programmer? Not counting meta-objects like ADTs.