I've been using All-in-Wonders in my primary desktop almost exclusively for the last 9 years. I am currently running an All-In-Wonder Radeon under Windows XP, and it has run impeccably regardless of the driver set I've had installed. I have also owned a Rage 128 Pro All-In-Wonder and an original (Mach64?) All-In-Wonder, both of which I liked well enough to buy their successors. (Never got any of them to work in Linux when they first came out, but ATI has been rather reluctant at releasing proprietary information or supporting Linux until very recently.) IMO, ATI has been providing a solid, well-built product with adequate gaming support and excellent video capture, tv display, hardware assisted MPEG, and associated software for the life of the All-In-Wonder brand name.
That's because there's a bias among many humans...
I could not agree more. To extend your comment, you will probably find that any animal taking an intelligence test will perform to a degree directly proportional to their genetic similarity to the creators of the test...
So... when you enter a block of text, you click on the on-screen keyboard (or use Character Mapper, etc.) to enter it all. You never use shift-arrow to select text in your WP, and you never italicize or bolden with Ctrl-I or Ctrl-B. Not to mention you never save a document to disk, as that could be considered a script for recreating it.
It's much the same way we function and interact with everything around us.
Not everything we interact with is about a decision on how to adjust our horizontal (or even vertical) orientation. Relatively few decisions, in fact, are related to our spatial orientation. I doubt I would consider a steering wheel to be the best interface mechanism for getting in my car (though a lock wheel of some type may actually work). I have always considered substituting a button press on the screen to be an extremely clunky and annoying substitute for pressing a button on the keyboard, yet often I am forced to use the former rather than the latter. The argument isn't about whether a mouse is an effective pointing device, it's about whether pointing devices should be the focus of computer interface design. IMHO, they shouldn't.
The grandparent of this post was not talking Microsoftese. "Power user" has had a definition long before Microsoft created a user group with that name. The grandparent is simply referring to people who use computers for more than email, word processing, and video games. His definition has nothing to do with their security priveleges, a separate (but somewhat related) subject.
I felt the need to comment on your glaring contradiction:
Am I the only user in the world who almost never feels a need for a script? ... I'm decently well versed in bash and darn near an expert in vbscript and batch,...
No one ever becomes a near expert in a scripting language without needing to use it for something. Either you are not even close to being an expert, or you actually do use scripts to accomplish tasks, or you are arbitrarily limiting your discussion to those tasks ("home") for which you don't need scripts, which is uninteresting.
We have to get away from the mentality that "software-is-like-a-toaster"
Absolutely. Positively. Only you are going in completely the wrong direction. Historically, when a person develops a widget, he does so knowing he is expending his work in the (perhaps vain) belief that if he is successful, people will come to him and pay him money: not for his development work, but for a completed, well-designed widget. The money is for the widget, not the development. In general, people value development work very little, as much more development is accomplished that they don't care about or actually don't want than is desired.
Software development is a young industry, and is currently an art, not an engineering discipline. There are very few rules about software-interface and user-interface design that are actually being followed. The software titles put on the market are purely artistic accomplishments (many games being nearly entirely aural/visual art). It is a huge stretch to imagine people to start considering their software company their "personal software engineer" and paying them a retainer for looking out for their interests.
I am a software developer myself of 20+ years, and as the grandparent to this post stated, the software industry needs to grow up and realize that it can't have anything it wants [just 'cause they're super-techno-geniuses]. Software is simply an artform, and people should not be paying that much for a single performance, let alone double for a second performance with a few ugly glitches removed.
Piracy is the single greatest obstacle to improving the quality of software. In life, you don't get what you don't pay for.
There seems to be a lot of confusion about who the software pirates are. Using my somewhat limited knowledge of traditional pirates, I would say it was more pirate-like to create a formulated idea that was essentially costless to disseminate, and then try to get everyone who heard or used that formulated idea in the future to pay for the original creation. A superb pirate might try to get everyone who used the idea to pay for it on a regular basis, or perhaps every time they used the idea...
Even music, art, literature, and video artists (whose work is much more personal) don't expect people to pay more than once for a copyrighted work, and it used to be that they would find sponsors to commission a piece of artistry before they expended their energy. No one is complaining about talented software developers trying to compensate themselves a little for their work. The complaints are about greedy corporate executives trying to "pirate" money from people who have invested a great deal in the training and research required to use a particular software product, only to find they have to start the paying all over again to keep going.
I think you misunderstand something in the quote block you inserted, cause I'm not sure what the question is. No, nothing is going to be cross-platform on the struct memory block copy. Byte orders might be wrong, structure packing might be different, etc. You especially wouldn't want to do it on an object, because then your function pointers would be stored as well, which is useless at best and more than likely hazardous.
Let me clarify a few things for anyone who has gotten caught up on nearly off-topic issues:
1) I have an option I am aware of known as Option A
2) I have an option I am aware of known as Option B
3) I wish I had an option C (and maybe D, E, and F)
4) Since I have neither taken Option A nor Option B, I am not in the process of optimizing anything (or even thinking about optimization), and, in fact, I haven't even completed investigating C, D, E, or F.
5) It's a little too premature to even be premature.
Saying "adding all this object-oriented behavior will bloat my app and slow it down" is just another instance of Donald Knuth's (originally from CAR Hoare) principle "Premature optimization is the root of all evil".
The topic of conversation here is not some "optimization" technique. The method of saving the game state affects how nearly every variable is declared and whether it is public or private. It affects whether every class is going to have an oddball member function whose purpose is not to manipulate the object itself, but to store its status in some sort of globally-accessible location. It affects the entire game design plan in almost every way, and I have learned over 20 years of programming that if something looks like its going to be inefficient at its task, it's also going to be complex and unwieldy to code.
Saying that, I respect the fact that you are at home with the object-oriented methodology, and, at the very least, you gave me some additional references by which I can gauge things.
...writing a block of memory prevents using _any_ kind of pointer, not just virtual function table pointers. _Any_ kind of a linked list, hash table, dynamically sized array, etc...
Unless your linked list/hash table is made from indexes into the data structure, rather than true process address space pointers. It adds some minor complexity to the referencing and dereferencing, but still might be worth it. If not, you can always just iterate.
My question at the top of this thread had been simplified to refer to staticly-allocated static (global) variables alone, but the argument can be extended to include dynamically-allocated static (global) variables. Dynamic allocation would probably cause an additonal write function call for each allocation, but in my opinion that would still be better than iterating through the gamestate methods of 40,000 objects, each of which has to call a game-context class method (or i/o stream function) to do the actual storing.
It's also a matter of complexity. I don't want every one of my object classes to have a saveme() method, inherited or not. It doesn't seem like it should be their reponsiblity, and they are already complex enough, the little buggers.
Any compiler that rearranged the members of the gamestate structure would need to be scrapped in a hurry. As for cross-platform, any binary game save format has the potential for creating problems there. Am I going to complicate my code by converting binary data (which already exists) to some other format... not on your life.
The object-oriented solution is the garrish hack here. Object classes should have no inherent duty to serialize their game state information at runtime. That should be a responsibility of the language itself (as other posts have mentioned), or some sort of holistic game object, or precomputed as a global data structure as I've shown. You are adding code, data, and object bloat when you create so many classes, all (yes, all) of which have to manage the persistance of their objects.
The author of the article, IMHO, has clearly been on the management side of the development process far too long. While providing many examples for his readers to laugh and sneer at, he provided little in the way of good design advice or practical knowledge. "Keep it simple?" Sounds like he really just wants everyone to do it his way. "Keep it simple" is the essence of every "bad design choice" I make, mainly because I program on my own dollar, not anyone elses.
First, I'd like to thank everyone for all the well-written responses I've received to my question, but...
I think that in some instances the crux of my problem may have been overlooked. The title of this post may have been somewhat misleading (my fault), but I was really more concerned with the avoiding code bloat aspect of my question than the "how to save a game state" part, all while maintaining object-oriented methodology. Some people seem to consider this a silly question, as the object-oriented methodology supposedly allows any technique you want. I beg to differ. When I started out programming many years ago (writing BASIC on an Apple II), I instinctively wrote top-down, procedural, and somewhat structured code that had very few GOTO statements (maybe some when I had mismanaged line numbers). The methodologies I just mentioned do allow for any technique you choose to employ, and can rival the efficiency of any of the spaghetti code that came before. I have never found the same thing to be true for object-oriented methodologies.
Some of my concerns about the techniques mentioned:
The singleton technique seems to be a politically correct label for a global data structure. I don't think my ex-instructor would approve (but seriously, it does seem to be somewhat of an anti-oop construct).
The object serialization technique is basically a sophisticated term for the MyObject.savemyself() that I mentioned at the top of the post. Of course the game data would need to be serialized, rather than letting objects write randomly to the save game file with a brief header describing who had done the writing. My overriding concern with this technique is that it would involve so many function calls for a game that included say, 40,000 objects. My secondary concern would be that depending on the class hierarchy, many different versions of a save game state function would have to be employed. While one post claimed that a universal base class would be able to write the game state out for every derivation, I cannot believe it. Derived classes will always have extra features that affect the game state which they will need to handle themselves (their parents and children can't do it for them).
After spending 15 years trying to clearly understand the object-oriented philosophy (even taking a class at my age), it occurs to me that the object-oriented hype seems to be an attempt at scaling down the operating system philosophy to fit single applications. Objects are "mini-programs" that are supposedly decoupled from the surrounding super-program and protected from dangerous and misbehaving code in other modules (of the same super-program). Funny that after 20 years of procedural programming, I have seldom beheld any of the claimed symptoms of not using object-orientation.
I think the industry went in totally the wrong direction. We should have been fixing our operating systems to more closely mimic the single application philosophy...
But I would still be interested in hearing about a truly efficient, simple, elegant, and nearly code-less object-oriented solution to the save game state problem.
No, I was actually thinking in terms of instantiations, not classes. The concerning feature of the MyObject.saveme() technique would that it would have to be executed for every instantiation of a class, not once per class. Code bloat is largely a concern of execution speed, not necessarily executable size.
The sad truth is that no single individual or nation is capable of deciding, so it is highly unlikely that anything will be decided before something highly regrettable happens.
...what every happened to that whole liberal overpopulation hypothesis in the seventies?
The "liberal overpopulation hypothesis in the seventies" is still being discussed. I subscribe to Scientific American, and they regularly devote a whole issue to the topic.
Liberals keep talking about this global warming concept but haven't been able to back in up with scientific proof.
It is true that many scientists just have a "hunch" that certain trends will eventually cause extremely undesirable events to occur and therefore use their scientific methods in a slightly warped way to try to prove their hunch. The problem is that scientific methods are mostly good at disproving things, not proving things that may or may not happen in the future. The morale of the story is that unless you want to learn everything the really hard way, you yourself should try to come up with and accept the best "hunch" that you can.
My best "hunch" (based on the information that I have received) is that continued overpopulation trends and emissions of greenhouse gases into the atmosphere will eventually cause some sort of serious backlash that will threaten my survival within the next 30 years.
My point was that forests of any size are made up of trees of different sizes (admittedly I may not have used the best analogy). Sometimes it might make sense to have a single, large tree out in the middle of nowhere. Finding the best solution possible means finding the best solution possible, it doesn't mean blindly following the advice of someone who's only rationalization is "that's the way its done." My experience (as an old fart) lets me know that anyone who tries to sell you that line is the last one you should be listening to.
The US wants Iraq to have government that they are not responsible for so that they can start handing over the responsibility of that place to someone else
The only reason the US Government thinks it is important to leave a democracy-friendly government in power is to ensure that Iraq is involved in the western capitalist ventures of the future (with U.S. companies leading the way), not because they are worried about a massive civil war. The problem with imposing sanctions on Iraq was that the government of Iraq was laughing in our face (We have oil, idiots). Of couse everyone in our government would love to abdicate themselves of the responsibility of policing Iraq, but its the price you have to pay when you want to subvert the interests of a large percentage of the people there, for your own.
Iraq was embroiled in civil and neighborly war before we invaded, and will be after we remove our troops, regardless of the superpower affiliations of any existing regime. (For that matter, they are embroiled in civil war now - most of the casualties being Iraqi on both sides of the current conflict.) It is pure rhetoric or naivete to claim that the US has any altruistic mission in the Middle East. The only thing left to discuss is the magnitude of their purely selfish motives, and in what directions they extend.
Future historians will come to realize that once the reconstruction of Iraq is complete, the dymanics of the whole region will be forever and drastically changed, just as it was with Germany and Japan after World War II
Yes, because we are the victors of World War III (U.S. and England vs. little old Iraq). I think the jury might still be out.
we get to baby sit the 2nd largest (cheaply pumped) oil supply in the world
I'm sure the Nazis thought it was a good thing: taking all that art, gold, and technology. I wonder what could happen to make it seem like not such a good thing?
You are confusing production with ownership. The product is produced in the United States. It is owned (in a stock holdings percentage fashion) by Saudi Arabians. I have no idea what the real percentages and figures are, but your calculations are only confirming how alarming (if it is true - as "Fahrenheit 911" stated) 7% would be.
First, let me say I mostly agree with the other criticisms that have been levied against your statements. You seem to be mainly arguing that the most modern software practices are the correct ones mainly because they are modern (and because they are yours).
Second, the limits of the compiler and linker that were referred to originally are most likely hardware or hardware-like limitations (i.e. a PocketPC versus a Gaming PC). The document you referred to would not address implementation-specific limitations like these.
Third, I am not sure why any of you are talking about incremental linking. Incremental linking can be used to reduce fixups of memory address references when linking a single module as well as multiple modules. The root forum message is talking about demodularizing the project (using one object code module for the entire project). I think you are getting the term incremental linking confused with this modularity.
I personally think the most convincing argument for decoupling (modularizing) code is code reuse, using the module for more than one project or for more than one version of a product. With or without this reuse, compile time and link time seem very trivial concerns to be arguing about, especially in the modern hardware age.
I was not saying (to any degree) that every designer should be able to translate his code to C. First, I was saying that learning C was a compromise between what can be learned (in a certain amount of time) and what it would be desirable to know. Second, I was saying that C acts a Rosetta stone, not a language translation dictionary. The Rosetta stone was used to translate ancient Egyptian hieroglyphics to Greek, yet the important thing was not that it translated to Greek specifically, but that it allowed translation at all. Knowing how C works gives an excellent base for being able to figure out the workings of other languages. It also works quite well at figuring out the coding habits of a staggeringly large number of programmers.
You are right, I have not read Ableson and Sussman's book, nor do I know anything about them. I was merely responding to your quotations, and if they are actually fundamentals-oriented, they would have done well to leave out what they said in those particular instances.
I always love to here that old, tired argument (not): We should stick with the way we've always done things because that's
the way we've always done it.
Modules for a 7 million line coding project are probably an average of 50,000 lines each at a minimum (who wants to keep track of more than 140 modules). Yet modules for a 50,000 line coding project will be drastically smaller. No one ever came up with overriding standards for how big a module should be and the limits of what it should accomplish. Depending on the project, demodularization may make perfect sense or it might be utterly ridiculous. The true error occurs when new, more efficient methods are overlooked merely for the sake of doing it the same old way its always been done.
The "higher-quality code" reference is a bit too subjective. Where I work, I have written software that I use extensively and find to be very reliable and easy to augment. Other people at work who do some of the same things that I do would probably find the software I use to be of much lower quality (i.e. hard to use and less reliable - mainly because they are doing everything they are not supposed to be doing).
Programming for love means writing code you yourself want to use for a given task. I don't believe that writing code you want complete strangers to use and enjoy is a real, valid sentiment. It just means you have a hidden agenda. Programming for love roots its superiority in the fact that it is your solution and you can make it do things the way you want.
The Free Software Foundation is simply trying to make it a trend for able individuals to start demanding the freedoms they need to make all their software solutions their own.
Slashdot Mirror
I've been using All-in-Wonders in my primary desktop almost exclusively for the last 9 years. I am currently running an All-In-Wonder Radeon under Windows XP, and it has run impeccably regardless of the driver set I've had installed. I have also owned a Rage 128 Pro All-In-Wonder and an original (Mach64?) All-In-Wonder, both of which I liked well enough to buy their successors. (Never got any of them to work in Linux when they first came out, but ATI has been rather reluctant at releasing proprietary information or supporting Linux until very recently.) IMO, ATI has been providing a solid, well-built product with adequate gaming support and excellent video capture, tv display, hardware assisted MPEG, and associated software for the life of the All-In-Wonder brand name.
That's because there's a bias among many humans...
I could not agree more. To extend your comment, you will probably find that any animal taking an intelligence test will perform to a degree directly proportional to their genetic similarity to the creators of the test...
All things are relative, including intelligence.
So... when you enter a block of text, you click on the on-screen keyboard (or use Character Mapper, etc.) to enter it all. You never use shift-arrow to select text in your WP, and you never italicize or bolden with Ctrl-I or Ctrl-B. Not to mention you never save a document to disk, as that could be considered a script for recreating it.
Somehow I doubt it.
It's much the same way we function and interact with everything around us.
Not everything we interact with is about a decision on how to adjust our horizontal (or even vertical) orientation. Relatively few decisions, in fact, are related to our spatial orientation. I doubt I would consider a steering wheel to be the best interface mechanism for getting in my car (though a lock wheel of some type may actually work). I have always considered substituting a button press on the screen to be an extremely clunky and annoying substitute for pressing a button on the keyboard, yet often I am forced to use the former rather than the latter. The argument isn't about whether a mouse is an effective pointing device, it's about whether pointing devices should be the focus of computer interface design. IMHO, they shouldn't.
The grandparent of this post was not talking Microsoftese. "Power user" has had a definition long before Microsoft created a user group with that name. The grandparent is simply referring to people who use computers for more than email, word processing, and video games. His definition has nothing to do with their security priveleges, a separate (but somewhat related) subject.
I felt the need to comment on your glaring contradiction:
...
Am I the only user in the world who almost never feels a need for a script?
I'm decently well versed in bash and darn near an expert in vbscript and batch,...
No one ever becomes a near expert in a scripting language without needing to use it for something. Either you are not even close to being an expert, or you actually do use scripts to accomplish tasks, or you are arbitrarily limiting your discussion to those tasks ("home") for which you don't need scripts, which is uninteresting.
We have to get away from the mentality that "software-is-like-a-toaster"
Absolutely. Positively. Only you are going in completely the wrong direction. Historically, when a person develops a widget, he does so knowing he is expending his work in the (perhaps vain) belief that if he is successful, people will come to him and pay him money: not for his development work, but for a completed, well-designed widget. The money is for the widget, not the development. In general, people value development work very little, as much more development is accomplished that they don't care about or actually don't want than is desired.
Software development is a young industry, and is currently an art, not an engineering discipline. There are very few rules about software-interface and user-interface design that are actually being followed. The software titles put on the market are purely artistic accomplishments (many games being nearly entirely aural/visual art). It is a huge stretch to imagine people to start considering their software company their "personal software engineer" and paying them a retainer for looking out for their interests.
I am a software developer myself of 20+ years, and as the grandparent to this post stated, the software industry needs to grow up and realize that it can't have anything it wants [just 'cause they're super-techno-geniuses]. Software is simply an artform, and people should not be paying that much for a single performance, let alone double for a second performance with a few ugly glitches removed.
Piracy is the single greatest obstacle to improving the quality of software. In life, you don't get what you don't pay for.
There seems to be a lot of confusion about who the software pirates are. Using my somewhat limited knowledge of traditional pirates, I would say it was more pirate-like to create a formulated idea that was essentially costless to disseminate, and then try to get everyone who heard or used that formulated idea in the future to pay for the original creation. A superb pirate might try to get everyone who used the idea to pay for it on a regular basis, or perhaps every time they used the idea...
Even music, art, literature, and video artists (whose work is much more personal) don't expect people to pay more than once for a copyrighted work, and it used to be that they would find sponsors to commission a piece of artistry before they expended their energy. No one is complaining about talented software developers trying to compensate themselves a little for their work. The complaints are about greedy corporate executives trying to "pirate" money from people who have invested a great deal in the training and research required to use a particular software product, only to find they have to start the paying all over again to keep going.
I think you misunderstand something in the quote block you inserted, cause I'm not sure what the question is. No, nothing is going to be cross-platform on the struct memory block copy. Byte orders might be wrong, structure packing might be different, etc. You especially wouldn't want to do it on an object, because then your function pointers would be stored as well, which is useless at best and more than likely hazardous.
Let me clarify a few things for anyone who has gotten caught up on nearly off-topic issues:
1) I have an option I am aware of known as Option A
2) I have an option I am aware of known as Option B
3) I wish I had an option C (and maybe D, E, and F)
4) Since I have neither taken Option A nor Option B, I am not in the process of optimizing anything (or even thinking about optimization), and, in fact, I haven't even completed investigating C, D, E, or F.
5) It's a little too premature to even be premature.
Saying "adding all this object-oriented behavior will bloat my app and slow it down" is just another instance of Donald Knuth's (originally from CAR Hoare) principle "Premature optimization is the root of all evil".
The topic of conversation here is not some "optimization" technique. The method of saving the game state affects how nearly every variable is declared and whether it is public or private. It affects whether every class is going to have an oddball member function whose purpose is not to manipulate the object itself, but to store its status in some sort of globally-accessible location. It affects the entire game design plan in almost every way, and I have learned over 20 years of programming that if something looks like its going to be inefficient at its task, it's also going to be complex and unwieldy to code.
Saying that, I respect the fact that you are at home with the object-oriented methodology, and, at the very least, you gave me some additional references by which I can gauge things.
...writing a block of memory prevents using _any_ kind of pointer, not just virtual function table pointers. _Any_ kind of a linked list, hash table, dynamically sized array, etc...
Unless your linked list/hash table is made from indexes into the data structure, rather than true process address space pointers. It adds some minor complexity to the referencing and dereferencing, but still might be worth it. If not, you can always just iterate.
My question at the top of this thread had been simplified to refer to staticly-allocated static (global) variables alone, but the argument can be extended to include dynamically-allocated static (global) variables. Dynamic allocation would probably cause an additonal write function call for each allocation, but in my opinion that would still be better than iterating through the gamestate methods of 40,000 objects, each of which has to call a game-context class method (or i/o stream function) to do the actual storing.
It's also a matter of complexity. I don't want every one of my object classes to have a saveme() method, inherited or not. It doesn't seem like it should be their reponsiblity, and they are already complex enough, the little buggers.
I never intended this thread to be a critique on the way I store the game state, but since you asked...
...there isn't any gaurantee the data will be in a contiguous address space. And if by chance they work o one compiler, they will break on another...
...
...
....
...
/ 02/07/1916205&tid=185&tid=137&tid=189&tid=8) that slashdot posted just a week ago.
For the sake of argument:
struct gamestate
{
double gflen;
double gfwdth;
} my_gmstate;
mymemsave(&my_gmstate, sizeof(gamestate));
mymemload(&my_gmstate, sizeof(gamestate));
Any compiler that rearranged the members of the gamestate structure would need to be scrapped in a hurry. As for cross-platform, any binary game save format has the potential for creating problems there. Am I going to complicate my code by converting binary data (which already exists) to some other format... not on your life.
The object-oriented solution is the garrish hack here. Object classes should have no inherent duty to serialize their game state information at runtime. That should be a responsibility of the language itself (as other posts have mentioned), or some sort of holistic game object, or precomputed as a global data structure as I've shown. You are adding code, data, and object bloat when you create so many classes, all (yes, all) of which have to manage the persistance of their objects.
I don't think anyone in this thread has read the "Where have all the cycles gone?" article (http://developers.slashdot.org/article.pl?sid=05
Wow, I don't even know where to begin...
The author of the article, IMHO, has clearly been on the management side of the development process far too long. While providing many examples for his readers to laugh and sneer at, he provided little in the way of good design advice or practical knowledge. "Keep it simple?" Sounds like he really just wants everyone to do it his way. "Keep it simple" is the essence of every "bad design choice" I make, mainly because I program on my own dollar, not anyone elses.
First, I'd like to thank everyone for all the well-written responses I've received to my question, but...
I think that in some instances the crux of my problem may have been overlooked. The title of this post may have been somewhat misleading (my fault), but I was really more concerned with the avoiding code bloat aspect of my question than the "how to save a game state" part, all while maintaining object-oriented methodology. Some people seem to consider this a silly question, as the object-oriented methodology supposedly allows any technique you want. I beg to differ. When I started out programming many years ago (writing BASIC on an Apple II), I instinctively wrote top-down, procedural, and somewhat structured code that had very few GOTO statements (maybe some when I had mismanaged line numbers). The methodologies I just mentioned do allow for any technique you choose to employ, and can rival the efficiency of any of the spaghetti code that came before. I have never found the same thing to be true for object-oriented methodologies.
Some of my concerns about the techniques mentioned:
The singleton technique seems to be a politically correct label for a global data structure. I don't think my ex-instructor would approve (but seriously, it does seem to be somewhat of an anti-oop construct).
The object serialization technique is basically a sophisticated term for the MyObject.savemyself() that I mentioned at the top of the post. Of course the game data would need to be serialized, rather than letting objects write randomly to the save game file with a brief header describing who had done the writing. My overriding concern with this technique is that it would involve so many function calls for a game that included say, 40,000 objects. My secondary concern would be that depending on the class hierarchy, many different versions of a save game state function would have to be employed. While one post claimed that a universal base class would be able to write the game state out for every derivation, I cannot believe it. Derived classes will always have extra features that affect the game state which they will need to handle themselves (their parents and children can't do it for them).
After spending 15 years trying to clearly understand the object-oriented philosophy (even taking a class at my age), it occurs to me that the object-oriented hype seems to be an attempt at scaling down the operating system philosophy to fit single applications. Objects are "mini-programs" that are supposedly decoupled from the surrounding super-program and protected from dangerous and misbehaving code in other modules (of the same super-program). Funny that after 20 years of procedural programming, I have seldom beheld any of the claimed symptoms of not using object-orientation.
I think the industry went in totally the wrong direction. We should have been fixing our operating systems to more closely mimic the single application philosophy...
But I would still be interested in hearing about a truly efficient, simple, elegant, and nearly code-less object-oriented solution to the save game state problem.
email: aofi7@hotpop.com
No, I was actually thinking in terms of instantiations, not classes. The concerning feature of the MyObject.saveme() technique would that it would have to be executed for every instantiation of a class, not once per class. Code bloat is largely a concern of execution speed, not necessarily executable size.
Who gets to decide what the ideal temperature is?
...what every happened to that whole liberal overpopulation hypothesis in the seventies?
The sad truth is that no single individual or nation is capable of deciding, so it is highly unlikely that anything will be decided before something highly regrettable happens.
The "liberal overpopulation hypothesis in the seventies" is still being discussed. I subscribe to Scientific American, and they regularly devote a whole issue to the topic.
Liberals keep talking about this global warming concept but haven't been able to back in up with scientific proof.
It is true that many scientists just have a "hunch" that certain trends will eventually cause extremely undesirable events to occur and therefore use their scientific methods in a slightly warped way to try to prove their hunch. The problem is that scientific methods are mostly good at disproving things, not proving things that may or may not happen in the future. The morale of the story is that unless you want to learn everything the really hard way, you yourself should try to come up with and accept the best "hunch" that you can.
My best "hunch" (based on the information that I have received) is that continued overpopulation trends and emissions of greenhouse gases into the atmosphere will eventually cause some sort of serious backlash that will threaten my survival within the next 30 years.
My point was that forests of any size are made up of trees of different sizes (admittedly I may not have used the best analogy). Sometimes it might make sense to have a single, large tree out in the middle of nowhere. Finding the best solution possible means finding the best solution possible, it doesn't mean blindly following the advice of someone who's only rationalization is "that's the way its done." My experience (as an old fart) lets me know that anyone who tries to sell you that line is the last one you should be listening to.
The US wants Iraq to have government that they are not responsible for so that they can start handing over the responsibility of that place to someone else
The only reason the US Government thinks it is important to leave a democracy-friendly government in power is to ensure that Iraq is involved in the western capitalist ventures of the future (with U.S. companies leading the way), not because they are worried about a massive civil war. The problem with imposing sanctions on Iraq was that the government of Iraq was laughing in our face (We have oil, idiots). Of couse everyone in our government would love to abdicate themselves of the responsibility of policing Iraq, but its the price you have to pay when you want to subvert the interests of a large percentage of the people there, for your own.
Iraq was embroiled in civil and neighborly war before we invaded, and will be after we remove our troops, regardless of the superpower affiliations of any existing regime. (For that matter, they are embroiled in civil war now - most of the casualties being Iraqi on both sides of the current conflict.) It is pure rhetoric or naivete to claim that the US has any altruistic mission in the Middle East. The only thing left to discuss is the magnitude of their purely selfish motives, and in what directions they extend.
Future historians will come to realize that once the reconstruction of Iraq is complete, the dymanics of the whole region will be forever and drastically changed, just as it was with Germany and Japan after World War II
Yes, because we are the victors of World War III (U.S. and England vs. little old Iraq). I think the jury might still be out.
we get to baby sit the 2nd largest (cheaply pumped) oil supply in the world
I'm sure the Nazis thought it was a good thing: taking all that art, gold, and technology. I wonder what could happen to make it seem like not such a good thing?
You are confusing production with ownership. The product is produced in the United States. It is owned (in a stock holdings percentage fashion) by Saudi Arabians. I have no idea what the real percentages and figures are, but your calculations are only confirming how alarming (if it is true - as "Fahrenheit 911" stated) 7% would be.
First, let me say I mostly agree with the other criticisms that have been levied against your statements. You seem to be mainly arguing that the most modern software practices are the correct ones mainly because they are modern (and because they are yours).
Second, the limits of the compiler and linker that were referred to originally are most likely hardware or hardware-like limitations (i.e. a PocketPC versus a Gaming PC). The document you referred to would not address implementation-specific limitations like these.
Third, I am not sure why any of you are talking about incremental linking. Incremental linking can be used to reduce fixups of memory address references when linking a single module as well as multiple modules. The root forum message is talking about demodularizing the project (using one object code module for the entire project). I think you are getting the term incremental linking confused with this modularity.
I personally think the most convincing argument for decoupling (modularizing) code is code reuse, using the module for more than one project or for more than one version of a product. With or without this reuse, compile time and link time seem very trivial concerns to be arguing about, especially in the modern hardware age.
I was not saying (to any degree) that every designer should be able to translate his code to C. First, I was saying that learning C was a compromise between what can be learned (in a certain amount of time) and what it would be desirable to know. Second, I was saying that C acts a Rosetta stone, not a language translation dictionary. The Rosetta stone was used to translate ancient Egyptian hieroglyphics to Greek, yet the important thing was not that it translated to Greek specifically, but that it allowed translation at all. Knowing how C works gives an excellent base for being able to figure out the workings of other languages. It also works quite well at figuring out the coding habits of a staggeringly large number of programmers.
You are right, I have not read Ableson and Sussman's book, nor do I know anything about them. I was merely responding to your quotations, and if they are actually fundamentals-oriented, they would have done well to leave out what they said in those particular instances.
I always love to here that old, tired argument (not): We should stick with the way we've always done things because that's the way we've always done it.
Modules for a 7 million line coding project are probably an average of 50,000 lines each at a minimum (who wants to keep track of more than 140 modules). Yet modules for a 50,000 line coding project will be drastically smaller. No one ever came up with overriding standards for how big a module should be and the limits of what it should accomplish. Depending on the project, demodularization may make perfect sense or it might be utterly ridiculous. The true error occurs when new, more efficient methods are overlooked merely for the sake of doing it the same old way its always been done.
The "higher-quality code" reference is a bit too subjective. Where I work, I have written software that I use extensively and find to be very reliable and easy to augment. Other people at work who do some of the same things that I do would probably find the software I use to be of much lower quality (i.e. hard to use and less reliable - mainly because they are doing everything they are not supposed to be doing).
Programming for love means writing code you yourself want to use for a given task. I don't believe that writing code you want complete strangers to use and enjoy is a real, valid sentiment. It just means you have a hidden agenda. Programming for love roots its superiority in the fact that it is your solution and you can make it do things the way you want. The Free Software Foundation is simply trying to make it a trend for able individuals to start demanding the freedoms they need to make all their software solutions their own.