Reaction for: Alternative Designs by Saul Daddy

This sounds a lot like what Shoe and Phil were talking about on Friday. The idea of teaching different ways of problem solving to solve different problems is very important. OOP is a great way of solving problems, but sometimes it is far and away from being the quickest. These are the design decisions that 15 tries to teach the students. How and why you choose one method of problem solving over another. My question is is it performance, time, money, or what bottom line that should be used to determine which method of problem solving should be used?

I think that this is not easily answered. How does one know when it is time to use a certain pattern? Is elegance the bottom line or is performance? These questions are what we need to think about when we teach a programming paradigm. I think that, for example, the 15 students do not justify why they make decisions and therefore do not understand why they lose credit for "bad design". That is all I have to say.


Reactions


Danah:

In addition, no one agrees what makes good design or elegant code. which only confuses the problem.


Jon:

Personally, I think the important aspect(s) of programming vary depending on the problem. In some applications, such as some graphics, having fast effecient code is more important than an elegant, extensible design. In other large software applications, the opposite is true. This makes it very difficult to give truisms about how to code or design.


Andrew

I'm not really sure what the aim of what I am about to write is but maybe something useful will come out of it...

I know one reason why I really love programming (especially OO programming, though I will now admit that lisp has a decent quality to it that grows on me everyday...) is that solving new problems is really exciting. but not only that I find it totally exciting to create new solutions to old problems, or to to just find a situation where a really cool pattern could be used. This is what thrills me.

Just today I was talking to Lucas about his usefull tool and some ideas of how it should be implemented. We came upon an aspect of it where it might make sense for him to use some sort of a pattern (though I cannot really find a match for it in the Gang-of-Four Design Patterns book) which would decouple the object relationships from their graphical representation. Just thinking of these neat way to solve it got be all giddy inside and made me want to tackle the problem.

So maybe what I am getting is that sometimes problems in and of themselves aren't necesesarily the only motivation for solving them. Perhaps the nature of their solutions (not just the solutions themselves) is also an important motivating factor. If we can make these appealing to the students as well perhaps we can get more people interested.

[BACK]