28 Mar, 2010, donky wrote in the 1st comment:
Votes: 0
David Haley said:
See post #138: "I think it's fair to simply disagree with such claims, while still questioning them some more just in case there is some additional insight to be had." Also see Deimos's post #160. Getting people to expound (usefully) on their claims, even if you disagree with them, can help make sure that you aren't missing something. You of all people should be familiar with this. :wink:
That said I think we've pretty much reached the point where this isn't much more useful expounding of claims going on.

Now, in no way do I wish to portray the topic as a waste of time, but I wonder if a large part of its existence comes as an act of procrastination on the part of the participants. If a programmer just knuckles down and implements something, they can evolve out the kinks as time passes regardless of what techniques or language they use.

  • Is it possible to implement systems in interesting and worthwhile ways with exceptions? Yes.
  • Is it possible to implement systems in interesting and worthwhile ways without exceptions? Yes.
  • Is it possible to implement systems in interesting and worthwhile ways with object orientation? Yes.
  • Is it possible to implement systems in interesting and worthwhile ways without object orientation? Yes.
  • Does it matter if your commands are implemented on the player object? Not really.
  • Does it matter that your "world" handler dispatches commands? Not really.

Most of these things will show their pluses and minuses over time, chances are you are going to migrate your commands out of your player object. Refactor your code to make more or less use of exceptions as appropriate. Refactor your codebase to use object orientation in a lesser or greater fashion as the need arises.

By just plugging away on your own, you'll come to an understanding of the potential of each of these things as you use them, and will be able to understand how to apply them better when the need arises. In some way I think it is comparable to the case where people accuse you of "rewriting the wheel", in practice writing your own implementation of something is inherently valuable because of the understanding it gives you. Not only do you understand why the wheel behaves the way it does, but it opens your mind to the possibilities of building a different wheel when the opportunity arises, or to understanding when a wheel is truly needed.

Now there are obvious benefits to being in situations where you are exposed to new ideas, including participating in forum discussions. But in the same way that following advice to not "rewrite the wheel" can prevent you from gaining valuable understanding and perspective, following advice from forum discussions can result in adopting a solution without having gained the perspective and understanding that would have come from making the step yourself.
28 Mar, 2010, flumpy wrote in the 2nd comment:
Votes: 0
Re-inventing wheels has it's place, that is mainly why I write my codebase.

If I wanted a short cut I'd ask here, mainly because no-one else would have asked before or I could not find info anywhere else.

I think there's a difference between reinventing the wheel and going ahead and building the entire car and finding you do not even have space for the wheel you are going to invent (to stretch another analogy) and I think this kind of forum is useful for that.

I also get some great ideas here too, thing I'd never think of, like you say.

I am a little confused however: what is this topic asking of us? Are we supposed to reflect on our conduct or something else?
28 Mar, 2010, Runter wrote in the 3rd comment:
Votes: 0
Without disagreeing too much with any particular point I'd like to inject a little context here.

All implementations do not have equal positives and negatives that balance the scale.
Particular problems lend themselves to particular answers.
Experience (i.e. mistakes) makes one wise. Hopefully wise enough to find that implementation the next time that solves this particular problem.

This is the entire reason that over the years patterns have emerged as a taught standard.

All that being said, I leave the wheel reinvention to you guys. :)
29 Mar, 2010, David Haley wrote in the 4th comment:
Votes: 0
donky said:
Not only do you understand why the wheel behaves the way it does, but it opens your mind to the possibilities of building a different wheel when the opportunity arises, or to understanding when a wheel is truly needed.

Maybe. Or maybe you become convinced that your way was best because you came to it after much sweat, blood and tears, and become so entrenched in how you saw the problem that you actually become less open to other possibilities.

There's a big difference between undertaking implementation as an exercise in understanding, and simply forging ahead.

Being able to learn from one's mistakes means understanding what mistakes one made in the first place. At least when you ride a bike, your mistakes are immediately visible in the form of scrapes and bruises.

That said, I have the same question flumpy does: what exactly is the question here? Or are we creating another thread that is merely procrastination on the part of its participants? :wink:
29 Mar, 2010, donky wrote in the 5th comment:
Votes: 0
flumpy said:
I think there's a difference between reinventing the wheel and going ahead and building the entire car and finding you do not even have space for the wheel you are going to invent (to stretch another analogy) and I think this kind of forum is useful for that.

I do not get how the stretched analogy relates as it stands, so I am unable to address this.

flumpy said:
I am a little confused however: what is this topic asking of us? Are we supposed to reflect on our conduct or something else?

Why does there need to be a question? I was floating a possible interpretation of the topic in order to gauge what people thought of it.
29 Mar, 2010, donky wrote in the 6th comment:
Votes: 0
David Haley said:
donky said:
Not only do you understand why the wheel behaves the way it does, but it opens your mind to the possibilities of building a different wheel when the opportunity arises, or to understanding when a wheel is truly needed.

Maybe. Or maybe you become convinced that your way was best because you came to it after much sweat, blood and tears, and become so entrenched in how you saw the problem that you actually become less open to other possibilities.

This is entirely possible. But it is a possible fault equally likely to occur in anyone developing anything, rather than specifically someone who would develop in the way I outlined.

David Haley said:
There's a big difference between undertaking implementation as an exercise in understanding, and simply forging ahead.

There is? If the difference is so big, then perhaps it would be possible for you to easily highlight it for me?

David Haley said:
Being able to learn from one's mistakes means understanding what mistakes one made in the first place. At least when you ride a bike, your mistakes are immediately visible in the form of scrapes and bruises.

This to me seems like a general sentiment about how it would be nice to have perfect knowledge. Perhaps I misunderstand this? If someone implements something and expects immediate visibility of problems, then they are doing it wrong. Implementing something would be hopping on the bike, and the scrapes and bruises would become apparent in due course. The ride would last for the life of the implementation as it stands. This might end tomorrow, or it might end a year from now. The end might be the revelation of an ill-advised approach that didn't meet the needs. It might be new needs that were not apparent at the time of implementation. Or the needs might simply change, perhaps through changes in dependent code.

David Haley said:
That said, I have the same question flumpy does: what exactly is the question here?

Answered in my reply to flumpy.
29 Mar, 2010, donky wrote in the 7th comment:
Votes: 0
flumpy said:
I am a little confused however: what is this topic asking of us? Are we supposed to reflect on our conduct or something else?

I caught the tail end of the editing period and lost this the last time, when I went to give more context.. so trying again..

I was interested in seeing if the post resonated or not. All the replies have indicated a lack of identification with the possible interpretation of procrastination, which is perfectly valid. As I stated I was not portraying the topic as a waste of time, and taken to more of an extreme, certainly not as containing bad conduct that required reflection. It goes without saying that if people are here participating in this topic and others, then they gain enough from it to make it worth their while.

The question was implied, but not explicitly asked. It is whether people would be better served in more personal action, rather than sharing of personal opinions. Given the consistent sentiment given in response to the question, it has been answered. However, if I were to instead rely on the points made both through extended analogies and general statements, I would remain unconvinced.
29 Mar, 2010, KaVir wrote in the 8th comment:
Votes: 0
donky said:
The question was implied, but not explicitly asked. It is whether people would be better served in more personal action, rather than sharing of personal opinions.

I think it very much depends on the individual. Just as some people enjoy playing muds and some enjoy developing them, so there are some people who enjoy discussing them. I don't get so much pleasure from playing muds these days, but I do still enjoy developing and discussing them. Sometimes I need a break from development, anyway, and I often find it helpful to bounce ideas around - particularly if I can't decide how to proceed with a particular problem.

Occasionally I discuss such issues with my players, but very few of them are developers, so while their feedback is really useful it doesn't cover everything. I have had the occasional mud developer drop by for a chat, and that's always nice, but they're usually pretty busy with their own projects - and if they do hang around for a while it tends to be because they're taking a break from their own muds, so I don't like to pester them too much.

I suppose I should really look into adding IMC. But even then, I'd prefer discussing complex ideas on forums, as I can better organise my thoughts before posting.

Quite a lot of my mud was based on concepts from MUD-DEV and mud discussion forums, by the way. I'd like to put together a list of all my sources of inspiration at some point, I think it would be quite interesting to see just how much of my design has been influenced by mud discussions.


EDIT: Just one other point I wanted to mention…

Sometimes I look at new muds in development, and read their forums, where their staff talk about how they're all former players of "Mud X". When I look at their design and proposed features, it's pretty obvious that they're just creating a near-clone of "Mud X" because that's all they know. While I disagree with many of the MudBytes regulars on many issues, I think the sheer diversity of knowledge and backgrounds can really help to expand the readers' perspective.
29 Mar, 2010, flumpy wrote in the 9th comment:
Votes: 0
donky said:
The question was implied, but not explicitly asked. It is whether people would be better served in more personal action, rather than sharing of personal opinions. Given the consistent sentiment given in response to the question, it has been answered. However, if I were to instead rely on the points made both through extended analogies and general statements, I would remain unconvinced.


Ok that makes sense.

Personal opinions are often based on personal experience. Sometimes a personal opinion can seem like stylistic preference (as I have stated before somewhere) which can seem arbitrary, almost fashion based. However, until you have walked a mile in that coders shoes, often superficial looking decisions cannot be dismissed out of hand.

I, for example, spend my time solving problems with objects. I have had experience with a lot of very bad code, and had the pressures of a live environment thrust upon me and very little time in which to solve those problems. When I do arrive at a solution, it is very carefully balanced and thought out, because I know at some point in time someone else will have to handle what I wrote and will have the same environmental pressures thrust upon them too. I was not always like that, I was quite gung-ho as a less experienced programmer, and that would always cause me or someone else problems down the line.

To address the extended analogy point: the only reason I ever use analogies is because sometimes they are good at expressing abstract ideas, and the point of reference for anyone trying to understand a general concept is often the world around them (such as the re-inventing the wheel analogy, or the toilet in the living room analogy). An initial nudge is often what some require to get them thinking in a new way. I do not see a problem discussing an analogy as an initial talking point, but if someone misses the point of the analogy (to express a new way to think about a problem) and starts to pick it apart because it does not address underlying problems, it can often mean this person is entrenched in their own thought patterns and cannot step back to see "the bigger picture".

This may be because they have had greater success in solving a problem "in their own way", it may be because they are stubborn, or a combination of both, or just having fun. Most of the time, unfortunately, it is because coders are stubborn beasts. That's human nature. We deal with the world around us by using abstractions, even at a very detailed level, and expressing those abstractions in a context which is useful to someone else is hard especially if the coder has a different mind-set. That's why most pattern or UML books do not try to tell you /where/ in your code to use the pattern, but what problem it solves. Patterns (and I don't just mean OO patterns) can often express the idea far better, but do not always address context. Code examples are often the best, because you can see at least some assumed context far more clearly.

So yes, discussing opinions and ideas are useful, but often there is no more to explain than "it works this way for me 80% of the time, you'll just have to trust my experience". Experience is important for programming wisdom (as someone else pointed out), but experience varies from coder to coder and discussing it (at least in this format) can lead to misunderstandings and so on*.


(Edited for clarity).

* and no, DH, clarifying a concept in English does not always help the concept come across better, I would often prefer code :wink:
29 Mar, 2010, shasarak wrote in the 10th comment:
Votes: 0
  • Does it matter if your commands are implemented on the player object? Yes.

  • Does it matter that your "world" handler dispatches commands? Yes.

Corrected that for ya. :wink:

donky said:
By just plugging away on your own, you'll come to an understanding of the potential of each of these things as you use them, and will be able to understand how to apply them better when the need arises. In some way I think it is comparable to the case where people accuse you of "rewriting the wheel", in practice writing your own implementation of something is inherently valuable because of the understanding it gives you. Not only do you understand why the wheel behaves the way it does, but it opens your mind to the possibilities of building a different wheel when the opportunity arises, or to understanding when a wheel is truly needed.

It's a given that no design will be anywhere near correct at the first draft. Successful software is created in a highly iterative way; some of those iterations will be functional changes, and some will be refactoring. However, I see nothing to be gained by willfully ignoring the past experience of other people in comparable situations. Learning every single principle of good coding by direct, first-hand trial and error wastes an awful lot of potentially productive time.
29 Mar, 2010, David Haley wrote in the 11th comment:
Votes: 0
donky said:
But it is a possible fault equally likely to occur in anyone developing anything, rather than specifically someone who would develop in the way I outlined.

I'm not sure what this sentence is trying to say. You seem to be meaning to create an opposition of some sort but the concept in the first half dominates the concept in the second half.

donky said:
David Haley said:
There's a big difference between undertaking implementation as an exercise in understanding, and simply forging ahead.


There is? If the difference is so big, then perhaps it would be possible for you to easily highlight it for me?

I find myself in the case of having a distinction so obvious to me that it's hard to put it into words, but here's to trying. The difference is that of understanding the theory and desiring to test the practice, or use practice to better understand the nuances of the theory, versus not understanding the theory and simply mucking about empirically in order to perhaps derive the theory. It is unclear to me if you are advocating mucking about or previous understanding of what is going on. It sounds like you are advocating the former, although I suspect that you are advocating some mix of the two.

donky said:
Answered in my reply to flumpy.

Contrary to apparent belief, I can in fact read posts addressed to people other than me so you don't need to specify this. :wink:

donky said:
This to me seems like a general sentiment about how it would be nice to have perfect knowledge. Perhaps I misunderstand this? If someone implements something and expects immediate visibility of problems, then they are doing it wrong. Implementing something would be hopping on the bike, and the scrapes and bruises would become apparent in due course. The ride would last for the life of the implementation as it stands. This might end tomorrow, or it might end a year from now. The end might be the revelation of an ill-advised approach that didn't meet the needs. It might be new needs that were not apparent at the time of implementation. Or the needs might simply change, perhaps through changes in dependent code.

Well, perhaps it might be a general statement (many statements are, including yours here, ne?), but I'm not sure how that makes it uninteresting. What I meant is that when you are doing things like riding a bike, it's immediately obvious when you fall over and bang yourself up. But not all programming mishaps are quite so obvious. Yes, yes, if your program falls over and crashes, it's pretty obvious that a mistake was made. But some mistakes are subtle, and indeed I've seen many programmers engaging in bad practice over and over again simply because they didn't realize it was bad practice. Or perhaps they knew something was wrong/annoying, but had not yet realized that anything could be done about it.

Obviously all the things you say about needs becoming apparent or changing over time is true as well. There's no use in trying to design the entire application and all of its future needs from the very start. But this doesn't change what I said either.

flumpy said:
To address the extended analogy point: the only reason I ever use analogies is because sometimes they are good at expressing abstract ideas, and the point of reference for anyone trying to understand a general concept is often the world around them (such as the re-inventing the wheel analogy, or the toilet in the living room analogy). An initial nudge is often what some require to get them thinking in a new way. I do not see a problem discussing an analogy as an initial talking point, but if someone misses the point of the analogy (to express a new way to think about a problem) and starts to pick it apart because it does not address underlying problems, it can often mean this person is entrenched in their own thought patterns and cannot step back to see "the bigger picture".

To elaborate briefly on what I said in the other thread, analogies can be extremely useful to convey an idea to somebody who doesn't have much exposure to it. And yes, maybe that same somebody will reject the analogy because they're stubborn. But really, analogies are not that useful when the rubber hits the road and it's time to demonstrate things. If I ask for a proof of some mathematical statement, I don't expect to receive a somewhat fuzzy, even if somewhat useful, response in return. Similarly, if somebody states "my way of programming is the One True Way and you're all blockheads for programming otherwise, and haven't seen the light", I will not be satisfied with hand-waving but will require statements that hold up to scrutiny etc. (at least, if I am to be convinced).
29 Mar, 2010, flumpy wrote in the 12th comment:
Votes: 0
David Haley said:
Similarly, if somebody states "my way of programming is the One True Way and you're all blockheads for programming otherwise, and haven't seen the light", I will not be satisfied with hand-waving but will require statements that hold up to scrutiny etc. (at least, if I am to be convinced).


Would you call "empirical evidence" valid? You frequently use it in your examples as to why it should be done one way over another. I believe Shas in the last thread was saying, effectively, "this has been done a million times before and thought long and hard about lots of times, that's why you should do it this way", i.e. he's referring to third party empirical evidence in his solutions.

Now it seems to me, and I'm not attacking you here, that you cannot have it both ways. Empirically, in an object oriented language (which I still believe is what was being used and discussed - even more so now Deimos has mentioned several times he's using ruby), resolving problems using OO principals is far better than using non-OO principals. The OO principals are there because programmers have hit these sorts of issues over and over again, and have written large white papers and books about the solutions. Saying "this is the way it has been shown to be best in most circumstances" is not hand waving, nor is it invalid, and I think you have to concede this point.

Other than that, I pretty much agree with everything you say there. There _is_ a definite benefit in knowing "another way to do it".
29 Mar, 2010, David Haley wrote in the 13th comment:
Votes: 0
flumpy said:
Would you call "empirical evidence" valid? You frequently use it in your examples as to why it should be done one way over another. I believe Shas in the last thread was saying, effectively, "this has been done a million times before and thought long and hard about lots of times, that's why you should do it this way", i.e. he's referring to third party empirical evidence in his solutions.

Empirical evidence is fine, until you get into a situation where there are different empirical experiences. Then you need to explain things more.

flumpy said:
Empirically, in an object oriented language (which I still believe is what was being used and discussed - even more so now Deimos has mentioned several times he's using ruby), resolving problems using OO principals is far better than using non-OO principals. The OO principals are there because programmers have hit these sorts of issues over and over again, and have written large white papers and books about the solutions. Saying "this is the way it has been shown to be best in most circumstances" is not hand waving, nor is it invalid, and I think you have to concede this point.

I don't really think anybody was disagreeing that using OO principles is better. The disagreement is the extreme to which those principles are pushed. I can agree that OO principles are good, without agreeing that they should be applied 100% of the time to their extreme conclusion. I think that you are somewhat oversimplifying my objection (I won't speak for Deimos here) if you think it comes down to rejecting OO principles.

It's my turn to use an analogy now. :tongue: Many tasks are useful, so useful that they become almost ritualized. The ritual serves a useful purpose. But when the ritual itself becomes the purpose, rather than the original purpose, something has gone wrong. The case is similar here: I believe that some OOP'ers push their principles beyond their usefulness. Some OOP'ers also have a tendency to be holier than thou, in a way similar to functional programmers. (Not saying you're like this flumpy, by the way.)

There's a big difference between what you said ("most circumstances") and discussing a very specific circumstance.
29 Mar, 2010, Deimos wrote in the 14th comment:
Votes: 0
flumpy said:
Empirically, in an object oriented language (which I still believe is what was being used and discussed - even more so now Deimos has mentioned several times he's using ruby), resolving problems using OO principals is far better than using non-OO principals. The OO principals are there because programmers have hit these sorts of issues over and over again, and have written large white papers and books about the solutions. Saying "this is the way it has been shown to be best in most circumstances" is not hand waving, nor is it invalid, and I think you have to concede this point.

Nothing I suggested in that thread violated any OO principle. I don't know why you seem to keep coming back to this, either. I've quite blatantly explained to you countless times that it was a conceptual design discussion. One in which you seem to believe that your solution is the only OO-correct solution possible.

If you have an Apple object, which contains a Seed object, does this violate any OO principles? No. It does not. Even though I could give Apple a Core, and put Seed inside the Core, both ways are valid OOP and differ only in conceptual design.

Please let this be the end of it.
29 Mar, 2010, flumpy wrote in the 15th comment:
Votes: 0
Deimos said:
If you have an Apple object, which contains a Seed object, does this violate any OO principles? No. It does not. Even though I could give Apple a Core, and put Seed inside the Core, both ways are valid OOP and differ only in conceptual design.

Please let this be the end of it.


TBH this has now really gone beyond the scope of your initial post in the other thread :rolleyes:

And really, at least from my perspective, thats not what you were asking as far as I could ascertain. From what I could understand, you were asking if the Apple /should/ BE the core, and the seed, when actually they are really 3 separate parts and, in my experience, /should/ be defined as such. It can still appear to be an apple, to the end user, but really you /should/ separate them, based on empirical evidence of many programmers' experience. None of us understood your context, or your particular circumstance, so non of us could tell if you /must/.

Anyway, yes, lets move on.
29 Mar, 2010, Runter wrote in the 16th comment:
Votes: 0
Deimos said:
flumpy said:
Empirically, in an object oriented language (which I still believe is what was being used and discussed - even more so now Deimos has mentioned several times he's using ruby), resolving problems using OO principals is far better than using non-OO principals. The OO principals are there because programmers have hit these sorts of issues over and over again, and have written large white papers and books about the solutions. Saying "this is the way it has been shown to be best in most circumstances" is not hand waving, nor is it invalid, and I think you have to concede this point.

Nothing I suggested in that thread violated any OO principle. I don't know why you seem to keep coming back to this, either. I've quite blatantly explained to you countless times that it was a conceptual design discussion. One in which you seem to believe that your solution is the only OO-correct solution possible.

If you have an Apple object, which contains a Seed object, does this violate any OO principles? No. It does not. Even though I could give Apple a Core, and put Seed inside the Core, both ways are valid OOP and differ only in conceptual design.

Please let this be the end of it.


And…My choice would be which way models my apple well enough and is the least complicated. You could give your apple a Genetic Code manager, etc etc. The idea that you have to accurately model something isn't true. (Not saying anyone is suggesting it is.) My point is object oriented design doesn't demand you model your objects as accurately as you can to real world representations. Even if your real world is a make believe fantasy world. :)
29 Mar, 2010, flumpy wrote in the 17th comment:
Votes: 0
+1, what Runter said, well put.
29 Mar, 2010, Deimos wrote in the 18th comment:
Votes: 0
You're going to +1 him for saying what I've been trying to convince you of for 2+ days?

Quite a confusing person you are.
30 Mar, 2010, Runter wrote in the 19th comment:
Votes: 0
Deimos said:
You're going to +1 him for saying what I've been trying to convince you of for 2+ days?

Quite a confusing person you are.


Don't rain on my parade. :(
30 Mar, 2010, flumpy wrote in the 20th comment:
Votes: 0
Deimos said:
You're going to +1 him for saying what I've been trying to convince you of for 2+ days?

Quite a confusing person you are.


Confusing perhaps I am, but think consistent I have been.

The language you were using suggested to me that you did not agree that's what /should/ be done. I misunderstood what you were saying, as I've also said. Also I thought I was clear enough in saying that it did not apply if, within your context, you think it mustn't be done that way, e.g you didn't need to reuse the code, etc etc.

Hohum.
0.0/30