Redundant rambling on about OOP

[BicycleTree]

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.

 

[chroot]

I really don't know what you're going on about, but languages all basically share the same features (file I/O, console I/O, etc.). Once you learn one language, it should not be hard to pick up another. I think what you're complaining about is the fact that you need to learn nearly all of C++'s keywords, and nearly all the concepts of object orientation, before writing even a rather trivial program.

Perl is one of the only languages I know which tries to mimic the learning process of natural languages like English and French, which you do not attempt to learn in their entirety before using them. If you don't know a word, you circumlocute. Larry Wall, the inventor of Perl, had the idea that you should not have to learn all of Perl's keywords or libraries to begin using it; you might only need to learn five or ten keywords to get something working. Then, if you learned more keywords, you would simply streamline your code, making it simpler, faster, and better.

Personally, I think this approach failed. While there may be some intermediate programs of academic interest which demonstrate that graduated-learning process, in the real world, you still need to learn 90% of Perl before being able to work with it professionally.

- Warren

 

[ramollari]

Basically you're saying: why are so many low-level details hidden from programmers. For example why can't we program the GUI directly with pixels in OO languages? I believe this is because of two reasons, the OS and information hiding (abstraction). The Operating System restricts the applications from what they can do and what resources they can access. For example they are not allowed to draw on any pixel on the screen, but only in a window area, and this through requests to the OS. On the other hand, abstraction with classes makes it more convenient for programmers to create and manipulate GUI elements like buttons, text fields, etc, as if they were real objects. This of course is associated with the tradeoff that the programmer is kept ignorant of what actually happens.

 

[BicycleTree]

Ramollari, I know all that. That's not what I'm saying. You could still work at a pretty low level over the OS; it doesn't have to be hardware to be so low.

Chroot, I did learn C++ at one point but now I think I've forgotten most of it. I'm actually using Java and HTML now. The problem isn't the complexity of the language itself. I think anyone can learn a language in a short time if they know other languages. It's the number of the objects that you have to deal with to get things done. There are only 40 keywords in Java, but the Java API is gigantic.


I think that what we need is an organized compendium of how to do various things in a particular language. A tree of information of ways to do things. This may already exist. I mean something where you can think, well, I want to do this--and then follow the tree and quickly find a bunch of ways that people have already done it. It could be publically modified, so that anyone could post a way of doing things that they figured out. You could give ratings to other people's posted methods in three categories: usefulness/correctness, relevance to your problem, and also as to being correctly placed in the tree, and you could post someone else's post somewhere else in the tree if you think it would go there better. If someone's post continually gets low ratings for usefulness/correctness it would disappear. If someone's post continually gets low ratings for being correctly placed in the tree, it would be moved to the section where people think it should go. If someone's post continually gets low ratings for relevance to your problem, but high ratings for the other two categories, then nothing would happen to it; apparently it would just be a solution to an obscure problem, worth keeping, but there should still be a "relevance to your problem" category so that people wouldn't give low marks for "usefulness/correctness" just because the post addressed an obscure problem. Maybe a low-relevance but correct and correctly placed post would get moved nearer to the end of the list of solutions for that particular branch.

Users could post as guests or be registered, and if they are registered and they post useful solutions, they would gain more power--so they could post more than just code solutions, but also propose new branches to the tree, which would be rated like any other. The more useful code solutions a user posts, the higher-level are the new branches he can propose. So the tree would slowly evolve to match new categories of problems in need of solution.

So then when you want to use the tree, and say you want to do something with graphics, you'd click graphics (probably one of the big first branches of the tree) and then click the type of graphics you wanted to do, and maybe click a branch or two below that, and there would probably be a way or a few ways that people have already done it, from a line or two of code to a whole function.

What do you think?

And what's the most similar thing to this that already exists?

 

[chroot]

How about... sourceforge?

- Warren

 

[BicycleTree]

Hmm... looking at sourceforge, it does seem to be organized along the lines I am talking about. But it's about whole projects instead of simple little "how do I do this" things. Useful, but for a different reason.

I was really only talking about the tree being publically-created because it was an idea I had at the moment. The important part is the end result, being able to find the information to solve the specific problem quickly. That would probably be in a book somewhere--do you know of any books that are organized like that? For example, in the image file processing thread, I was looking for the solution to reading pixels from an image file. My answer turned out to be one line of code, BufferedImage input = ImageIO.read(new File(INPUT));. Are there any resources where I could start with the idea "reading pixels from an image file" and quickly come to that line of code (with an explanation)?

And, as related to the last question of the first post of this thread, is that necessary? There are many thousands of classes in the Java API but how many of those does a developer use, speaking generally, in making a real application?

I don't have any experience programming real stuff, so I may be making a mountain of a the too-many-classes molehill. If you only need to know 20 standard classes to get things done, then it doesn't matter anyway.

 

[chroot]

Well, it only took me about five minutes or so of grepping through the API docs to find the classes needed to read pixel data from an image, namely BufferedImage. That doesn't seem particularly painful to me. If there were some enormous website full of code snippets, it might've taken me only 30 seconds, saving me 4:30. That would've been great, I guess, but I'm probably only totally stuck on a problem like that about once every couple of weeks, so the website would hardly impact my productivity at all.

- Warren

 

[egsmith]

My answer turned out to be one line of code, BufferedImage input = ImageIO.read(new File(INPUT));. Are there any resources where I could start with the idea "reading pixels from an image file" and quickly come to that line of code (with an explanation)?

It sounds like your describing Perl's CPAN.
However, since you are a Java programmer, I think
http://java.sun.com/j2se/1.5.0/docs/api/
meets your requirements. It provides a class tree view and an index view that includes short descriptions which can be searched via your browser. Sure, it's massive, but hey, there are a lot of problems, many special case, out there :)