Linked by Takuya Murata on Tue 18th May 2004 06:26 UTC
My physics teacher likes to say that physics like to make problems they face look like ones that they know how to solve. A simple harmonic oscillation was one he frequently used in class, as is presumably the case in physics in general.
Permalink for comment
To read all comments associated with this story, please click here.
First of all, _every_ problem can be solved either iterative or recursive. The conversion between iterative and recursive implementations follow simple rules and can even be done automatic.
Second, but very important: You (and a lot of other people) have to learn first that OOP is a way to design code, but it is not a matter of using a specific language. You can write perfectly designed OO code with plain C or even assembler as well as you can produce procedural code with Smalltalk. Some of these language give better support for a specific style than others, but most of them do not enforce a style. So it's basically on the author which style he chooses.
And, maybe even more important: An object oriented solution is only admirable if you want to solve an object oriented problem. This is the most common mistake "young" programmers who have been trained in OOP without having a look at the bascis.
Last but not least, for _sure_ computers are able to handle concurrent tasks. They have been for ages, machines with multiple processors have "always" been around. But on the other hand, it doesn't matter at all. If used correctly, concurrency can ease your design instead of making it more complex. You just have to gain some experience and learn how to handle your tool.
First of all, _every_ problem can be solved either iterative or recursive. The conversion between iterative and recursive implementations follow simple rules and can even be done automatic.
Second, but very important: You (and a lot of other people) have to learn first that OOP is a way to design code, but it is not a matter of using a specific language. You can write perfectly designed OO code with plain C or even assembler as well as you can produce procedural code with Smalltalk. Some of these language give better support for a specific style than others, but most of them do not enforce a style. So it's basically on the author which style he chooses.
And, maybe even more important: An object oriented solution is only admirable if you want to solve an object oriented problem. This is the most common mistake "young" programmers who have been trained in OOP without having a look at the bascis.
Last but not least, for _sure_ computers are able to handle concurrent tasks. They have been for ages, machines with multiple processors have "always" been around. But on the other hand, it doesn't matter at all. If used correctly, concurrency can ease your design instead of making it more complex. You just have to gain some experience and learn how to handle your tool.