Something being unprovable forces it to remain a lowly theory? Yup. The step up from theory is fact.
Furthermore, ID introduces a hypothesis which is not needed to explain the evolution of life, so it falls foul of Occam's razor. I don't understand this at all. http://pespmc1.vub.ac.be/OCCAMRAZ.html Occam's Razor says one should not increase, beyond what is necessary, the number of entities required to explain anything. If anything Occam's razor argues for ID. And the evolution of life can be explained as a side effect.
As I said before the two theories are not mutually exclusive.
However I did like your last comment. Incidentally I am not an atheist, but I think it's extremely defeatist to invoke the "God made it happen" argument, rather than trying to find a conventional scientific explanation. Think what we would have missed out on over the past 2000 years. and I agree 100%.
Still that's not a reason to not consider ID as well. Why limit ourselves?
I listened to a radio show about this topic last night. What I got from it is a couple of points.
1. Intelligent Design is a theory, which is widely critised as being unscientific.
2. Evolution has not been proved, and thus remains "the theory of evolution".
3. That there are mitocontria in the cells which are like motors, which must be made and could not have happened by chance. (This is where I lost it).
I've done work with genetic algorithms on computers and I can safely say that out of apparent randomness fantasic results can occur. But on the other hand the Intellegent Design people would say that someone (me) would have have to put the conditions in place for the program to work.
Put another way, Intelligent Design people would say that for every level that evolution can be proved, there is a sublevel which can be thought of as put in place by Intelligent Design.
This is of course as unprovable as any faith, and must therefore always remain a theory.
For myself, I think of God as the programmer who puts together the rules for the atoms, and who decides the rules for statistics, and who decides the value of pi, etc. From all this, evolution takes place. So I believe in both. However neither can be proved to the exclusion of the other.
The shows had a unique perspective on Sci-fi, and often had a good twist to keep it interesting. The characters all have individual personalities, and they actually stay true to them during the show. The personalities are all interesting, and believable. Some of the skills possessed are far fetched, but then again this is sci-fi.
The people in the show had the same sorts of problems that people have now, (money) and are just trying to get by in their world. This helps people to relate to them.
The reasons it couldn't make it through a season are not due to the show, but rather the lack of scheduling. Nobody could find it. It was moved around so many time slots that it never had a chance to develop a following... (I obviously stand corrected).
I also like the writing. It is humorous and entertaining, without the need of a laugh track. I'm so sick of cheers/friends/king of hill/fresh new price/fraser, that whenever I hear a laugh track the channel gets turned. This was original. This was entertaining.
The fact that some people don't like it is ok. They haven't had their fill of all the other shit that's on TV now.
I've 3 kids. The youngest I sent to Montessori, and I must say he is the one getting A's while the other two are always struggling. (when he entered kindergarten he was already adding and subtracting, numbers up to 100, (probably more cause he understood the pattern) and was well on the way to understanding multiplication. I think he's found school boring for the most part, cause he get's the concepts much faster then the others in his class. He does homework studiously, and without complaint.
I think if the school systems adopted the Montessori method of teaching, many (if not all) of the kids would be much better off. They not only teach the basics, they teach the proper frame of mind to approach learning with.
I seriously wish I had sent my other kids to Montessori as well. But it was too late for them.
The problem with MS having the OS and the apps under one umbrella corperation is that the apps developers get inside info about the OS. The OS has "special" hooks put in to assist the apps. This is a problem because it excludes other companies from developing equivilent apps.
If MS were to be broken up into 2 or more companies, then API information between the companies would (in theory) be the same information that everyone else in the world would have access to. Yes you would have two virtual monopolies, (Office and OS) but at least it wouldn't be one monopoly that can squeeze out other companies.
Releasing specs is at best a stopgap measure, as over time, new operating systems and versions of apps are created, (with new hidden APIs). Even then, how would you know if all the API's have been released? I would bet that there are some hidden ones that even MS developers don't know, but rely on without realizing it.
The wikipedia says that it "comes in the form of a Knoppix-based LiveCD", and I'd like to try it out. (course it's/.'d now). But if there is a torrent available I'd like to know about it.
Yes I've noticed this too. Somedays it seems very blatent, that either the (pro Microsoft) person has been totally brainwashed, or is being paid to spin a bad news story.
Of course, what proof do you have for it, other then the sneaking suspision.
Well, the first thing I thought of when I saw your comment// constants for CustomerID struct is that it's very limiting. I would normally use something like that as globably as possible, so that everywhere I was using something to do with an Agent Name, it would also have to do with an AgentNameLen. Perhaps that's just my coding style. But I have found that using one define to cover multiple cases is better then using one define for each case. You end up with more consistant code, and the code has fewer unexpected differences. Also I can see that comment getting out of sync with the code in a very short time. (ie the next time someone uses those defines for some other struct which also has an AgentName, or CustomerName in it.)
The second thing I thought of was the second comment// define CustomerID struct was the redundent type of comment that I hate. Useless since right below it is the definition of the struct. In your discussion, you said much of the samething yourself, and stated a comment for each block saying what your are doing. I think that it's good having a large/*========.... ====*/ to separate sections, it's much more important to comment why you do something rather then what something is.
The example is definitely slanted. But it was off the top of my head to get a point across.
Good point, however I've been stung when an array is actually a pointer to an array... (You get the size of a pointer). Not usually the result you are looking for, and hard to debug, since it can end up with trashed pointers. But I suppose that's a matter of careful coding in the first place.
As far as using #define's or const for defining the array size and using that as a definition of the length of the array when iterating, it seems pretty obvious to me that it's a good method. You can't have two defines with different values, at the least you will get warnings.
I've worked on a number of large projects as well, and I have found that 1. Like you comments keep me sane. 2. Self-documenting code keeps me sane. 3. Code and Comments drift over time, and after several people and time has passed, I don't trust comments. (better to read code, not comments). 4. Self-documenting code tends to keep in sync with the intention of the code over time and people.
An example of this is if the function name is: List *GetListOfUglyPeople(); and someone changes it to only get ugly people with big noses they will likely change the name of the function to List *GetListOfUglyPeopleWithBigNoses();
But when they change the name of the function all of a sudden, other functions which call the original one, complain that they can't find it. So the programmer then has to update them as well. This has the benefit of 1. Keeping the understanding of the code intact. 2. (helping to) insure a code review when the algorithm changes. 3. This also tends to help weed out programming errors.
I've done this where I thought a function would be better called GetIndex(), (because that's what it did), and when I did that and then went through all the functions that used it, I noticed that there were many redundant calls, that could be eliminated. The code had drifted from doing several things to doing one thing, but the calling code hadn't followed in all cases. By following the self-documenting rule, I got the code back in sync.
So I still believe in my 80% self-documenting code and 20% comment rule. The 20% is for those comments that can't be explained easily with code...
No, I'm arguing the case of self documenting code is better then non-self-documenting code+comments.
The purpose of a structure can change overtime, which is why it's a good idea to give the structure a meaningful name in the first place. CustomerID should have given a clue. (Although I admit my off-the-top-of-my-head example could have a better name, maybe CustomerAgentRelationShip). If the meaning of a structure changes, then the name change will cause a refactoring to occur which helps keep the code consistant. If the meaning changed, but comment wasn't updated then the comment can become worse then useless. It can be come misleading. Keeping comments in sync with code is difficult to do, especially if a comment describes an algorithm which spans several functions. If one of the deep down functions get's changed, will the maintainer know to update the discriptive comment way up top?
Certainly, adding a comment that says your struct is, in fact, a structure is not a good thing to do.
The comment was// CustomerID struct the important part was "CustomerID" But in general I agree, that the "struct" is redundant.
I find that for simple code that requires little thought, little in the way of comments is required. Sometimes comments just get in the way as the code progresses over time, and the comments don't. It's better to code with long descriptive variable names, and structures then depend on comments.
struct CustomerID { int CustomerID; char AgentName[AgentNameLen]; char CustomerName[CustomerNameLen]; };
or
struct CoID//Customer ID structure { int ID;// ID number for the customer char AName[41];// Agent Name char CName[51];// Customer Name };
To me the first is much more clear, and throughout the code will be obvious as to it's use. The second is mildly clear, but will degrade as new things get added to the structure. The first also allows things like for(int i=0;iAgentNameLen;i++) which makes it very clear that you are iterating throught the agent name.
Algorithm's should be documented, as much as possible, at the top of the function, and any function that takes more then a screen should be looked at to see if it can be broken up into smaller functions.
(Almost) Always code towards maintainability, never speed. Usually it pays off within the year.
So to sum up. In order of importance: 80% code clearly with an eye towards maintainablity 20% comment
1 - How much will it cost to reinstall everything? That's IT time, == $$$.
This time would be the same time that it cost to upgrade to a new version of Word. (That's IT time too!)
2 - How much will it cost to upgrade some computers, since OOo is usually more resource-hungry than Office?
Do you really think that upgrading to a new version of Word will use less resources?
3 - How much will it cost in money and grief to retrain everybody (yes, there are people who just get by with Word provided you don't ever change anything to their computers). It will cost what it costs... Once. Then whenever a new version of OO comes out there will be no cost. However if they were to upgrade to Word, they would have the almost the same cost, cause there's new features there too! Also as it was pointed out in an earlier post, it's easier to move away from Word to OO then the other way around.
4 - How much grief will the remaining file format incompatibilities with Office bring to the school? None. OO can read and write both formats. If the school wants to stay with.doc they can. If they want to gradually move over, they can do that too. If they want to do a massive change (By reading files, then writing them out) they can do that to. It's not that difficult.
So please stop being the typical mindless free software drone and start being a bit more realistic.
So please stop being the typical mindless MS drone and start being a bit more realistic.
(and to think I've got you marked as a friend too:D
Isn't it funny how when "Enterprise" Linux users (read corporate) have to hire people to handle all the changes it is that the "Kernel Changes Draw Concern from the Open Source Community"
Sounds to me like the Open Source Community is REALLY HAPPY to have faster desktops, better gaming machines.
I think it's a case of sour grapes. They've got to spend money so complain, and by the way, make it sound legitimate by saying it's the Open Source Community.
Slashdot Mirror
Something being unprovable forces it to remain a lowly theory? Yup. The step up from theory is fact.
Furthermore, ID introduces a hypothesis which is not needed to explain the evolution of life, so it falls foul of Occam's razor. I don't understand this at all. http://pespmc1.vub.ac.be/OCCAMRAZ.html Occam's Razor says one should not increase, beyond what is necessary, the number of entities required to explain anything. If anything Occam's razor argues for ID. And the evolution of life can be explained as a side effect.
As I said before the two theories are not mutually exclusive.
However I did like your last comment. Incidentally I am not an atheist, but I think it's extremely defeatist to invoke the "God made it happen" argument, rather than trying to find a conventional scientific explanation. Think what we would have missed out on over the past 2000 years.
and I agree 100%.
Still that's not a reason to not consider ID as well. Why limit ourselves?
I listened to a radio show about this topic last night. What I got from it is a couple of points.
1. Intelligent Design is a theory, which is widely critised as being unscientific.
2. Evolution has not been proved, and thus remains "the theory of evolution".
3. That there are mitocontria in the cells which are like motors, which must be made and could not have happened by chance. (This is where I lost it).
I've done work with genetic algorithms on computers and I can safely say that out of apparent randomness fantasic results can occur. But on the other hand the Intellegent Design people would say that someone (me) would have have to put the conditions in place for the program to work.
Put another way, Intelligent Design people would say that for every level that evolution can be proved, there is a sublevel which can be thought of as put in place by Intelligent Design.
This is of course as unprovable as any faith, and must therefore always remain a theory.
For myself, I think of God as the programmer who puts together the rules for the atoms, and who decides the rules for statistics, and who decides the value of pi, etc. From all this, evolution takes place. So I believe in both. However neither can be proved to the exclusion of the other.
IMHO
The shows had a unique perspective on Sci-fi, and often had a good twist to keep it interesting. The characters all have individual personalities, and they actually stay true to them during the show. The personalities are all interesting, and believable. Some of the skills possessed are far fetched, but then again this is sci-fi.
The people in the show had the same sorts of problems that people have now, (money) and are just trying to get by in their world. This helps people to relate to them.
The reasons it couldn't make it through a season are not due to the show, but rather the lack of scheduling. Nobody could find it. It was moved around so many time slots that it never had a chance to develop a following... (I obviously stand corrected).
I also like the writing. It is humorous and entertaining, without the need of a laugh track.
I'm so sick of cheers/friends/king of hill/fresh new price/fraser, that whenever I hear a laugh track the channel gets turned. This was original. This was entertaining.
The fact that some people don't like it is ok. They haven't had their fill of all the other shit that's on TV now.
I've 3 kids. The youngest I sent to Montessori, and I must say he is the one getting A's while the other two are always struggling. (when he entered kindergarten he was already adding and subtracting, numbers up to 100, (probably more cause he understood the pattern) and was well on the way to understanding multiplication. I think he's found school boring for the most part, cause he get's the concepts much faster then the others in his class. He does homework studiously, and without complaint.
I think if the school systems adopted the Montessori method of teaching, many (if not all) of the kids would be much better off. They not only teach the basics, they teach the proper frame of mind to approach learning with.
I seriously wish I had sent my other kids to Montessori as well. But it was too late for them.
You are a history teacher so you should know...
Those who do not know history, are doomed to repeat it.
Those who do know history, are doomed to watch it being repeated.
The problem with MS having the OS and the apps under one umbrella corperation is that the apps developers get inside info about the OS. The OS has "special" hooks put in to assist the apps. This is a problem because it excludes other companies from developing equivilent apps.
If MS were to be broken up into 2 or more companies, then API information between the companies would (in theory) be the same information that everyone else in the world would have access to. Yes you would have two virtual monopolies, (Office and OS) but at least it wouldn't be one monopoly that can squeeze out other companies.
Releasing specs is at best a stopgap measure, as over time, new operating systems and versions of apps are created, (with new hidden APIs). Even then, how would you know if all the API's have been released? I would bet that there are some hidden ones that even MS developers don't know, but rely on without realizing it.
The wikipedia says that it "comes in the form of a Knoppix-based LiveCD", and I'd like to try it out. (course it's /.'d now). But if there is a torrent available I'd like to know about it.
You're real name isn't Bob or Doug is it? :)
Doc, Just had to say.
I like your sense of humour.
Didn't Issac Newton discover this? Isn't it called calculus? (Passing a formula when describes a curve instead of the curve itself?)
Then again. It seems obvious to me as well.
Did they get the shot?
Everyone has a purpose in life. Some people are just there to show the rest of us what NOT to do!
Yes I've noticed this too. Somedays it seems very blatent, that either the (pro Microsoft) person has been totally brainwashed, or is being paid to spin a bad news story.
Of course, what proof do you have for it, other then the sneaking suspision.
Well, the first thing I thought of when I saw your comment // constants for CustomerID struct is that it's very limiting. I would normally use something like that as globably as possible, so that everywhere I was using something to do with an Agent Name, it would also have to do with an AgentNameLen. Perhaps that's just my coding style. But I have found that using one define to cover multiple cases is better then using one define for each case. You end up with more consistant code, and the code has fewer unexpected differences. Also I can see that comment getting out of sync with the code in a very short time. (ie the next time someone uses those defines for some other struct which also has an AgentName, or CustomerName in it.)
// define CustomerID struct was the redundent type of comment that I hate. Useless since right below it is the definition of the struct. In your discussion, you said much of the samething yourself, and stated a comment for each block saying what your are doing. I think that it's good having a large /*========.... ====*/ to separate sections, it's much more important to comment why you do something rather then what something is.
The second thing I thought of was the second comment
The example is definitely slanted. But it was off the top of my head to get a point across.
I believe we could work with each other's code without too many problems :)
Good point, however I've been stung when an array is actually a pointer to an array... (You get the size of a pointer). Not usually the result you are looking for, and hard to debug, since it can end up with trashed pointers. But I suppose that's a matter of careful coding in the first place.
As far as using #define's or const for defining the array size and using that as a definition of the length of the array when iterating, it seems pretty obvious to me that it's a good method. You can't have two defines with different values, at the least you will get warnings.
Interesting reply.
I've worked on a number of large projects as well, and I have found that
1. Like you comments keep me sane.
2. Self-documenting code keeps me sane.
3. Code and Comments drift over time, and after several people and time has passed, I don't trust comments. (better to read code, not comments).
4. Self-documenting code tends to keep in sync with the intention of the code over time and people.
An example of this is if the function name is:
List *GetListOfUglyPeople();
and someone changes it to only get ugly people with big noses they will likely change the name of the function to
List *GetListOfUglyPeopleWithBigNoses();
But when they change the name of the function all of a sudden, other functions which call the original one, complain that they can't find it.
So the programmer then has to update them as well. This has the benefit of
1. Keeping the understanding of the code intact.
2. (helping to) insure a code review when the algorithm changes.
3. This also tends to help weed out programming errors.
I've done this where I thought a function would be better called GetIndex(), (because that's what it did), and when I did that and then went through all the functions that used it, I noticed that there were many redundant calls, that could be eliminated. The code had drifted from doing several things to doing one thing, but the calling code hadn't followed in all cases. By following the self-documenting rule, I got the code back in sync.
So I still believe in my 80% self-documenting code and 20% comment rule. The 20% is for those comments that can't be explained easily with code...
No, I'm arguing the case of self documenting code is better then non-self-documenting code+comments.
// CustomerID struct
The purpose of a structure can change overtime, which is why it's a good idea to give the structure a meaningful name in the first place. CustomerID should have given a clue. (Although I admit my off-the-top-of-my-head example could have a better name, maybe CustomerAgentRelationShip). If the meaning of a structure changes, then the name change will cause a refactoring to occur which helps keep the code consistant. If the meaning changed, but comment wasn't updated then the comment can become worse then useless. It can be come misleading. Keeping comments in sync with code is difficult to do, especially if a comment describes an algorithm which spans several functions. If one of the deep down functions get's changed, will the maintainer know to update the discriptive comment way up top?
Certainly, adding a comment that says your struct is, in fact, a structure is not a good thing to do.
The comment was
the important part was "CustomerID"
But in general I agree, that the "struct" is redundant.
for(int i=0;iAgentNameLen;i++)
should have read
for(int i=0;i<AgentNameLen;i++)
(slashdot error)
I find that for simple code that requires little thought, little in the way of comments is required. Sometimes comments just get in the way as the code progresses over time, and the comments don't. It's better to code with long descriptive variable names, and structures then depend on comments.
//Customer ID structure // ID number for the customer // Agent Name // Customer Name
For example which would you rather read.
#define AgentNameLen 41
#define CustomerNameLen 51
struct CustomerID
{
int CustomerID;
char AgentName[AgentNameLen];
char CustomerName[CustomerNameLen];
};
or
struct CoID
{
int ID;
char AName[41];
char CName[51];
};
To me the first is much more clear, and throughout the code will be obvious as to it's use. The second is mildly clear, but will degrade as new things get added to the structure.
The first also allows things like
for(int i=0;iAgentNameLen;i++)
which makes it very clear that you are iterating throught the agent name.
Algorithm's should be documented, as much as possible, at the top of the function, and any function that takes more then a screen should be looked at to see if it can be broken up into smaller functions.
(Almost) Always code towards maintainability, never speed. Usually it pays off within the year.
So to sum up. In order of importance:
80% code clearly with an eye towards maintainablity
20% comment
Now that sounds like the voice of experience. :)
Are you from the outland?
Tell me, if two people are in a room and one left so the other was left, which of them was left? They can't both be left... right?
1 - How much will it cost to reinstall everything? That's IT time, == $$$.
.doc they can. If they want to gradually move over, they can do that too. If they want to do a massive change (By reading files, then writing them out) they can do that to. It's not that difficult.
:D
This time would be the same time that it cost to upgrade to a new version of Word. (That's IT time too!)
2 - How much will it cost to upgrade some computers, since OOo is usually more resource-hungry than Office?
Do you really think that upgrading to a new version of Word will use less resources?
3 - How much will it cost in money and grief to retrain everybody (yes, there are people who just get by with Word provided you don't ever change anything to their computers).
It will cost what it costs... Once. Then whenever a new version of OO comes out there will be no cost. However if they were to upgrade to Word, they would have the almost the same cost, cause there's new features there too!
Also as it was pointed out in an earlier post, it's easier to move away from Word to OO then the other way around.
4 - How much grief will the remaining file format incompatibilities with Office bring to the school?
None. OO can read and write both formats. If the school wants to stay with
So please stop being the typical mindless free software drone and start being a bit more realistic.
So please stop being the typical mindless MS drone and start being a bit more realistic.
(and to think I've got you marked as a friend too
Maybe you need to try again. SaveAs can save in several different version of word, which are all the "doc" format.
Isn't it funny how when "Enterprise" Linux users (read corporate) have to hire people to handle all the changes it is that the "Kernel Changes Draw Concern from the Open Source Community"
:)
Sounds to me like the Open Source Community is REALLY HAPPY to have faster desktops, better gaming machines.
I think it's a case of sour grapes. They've got to spend money so complain, and by the way, make it sound legitimate by saying it's the Open Source Community.
I for one, welcome our BIG FAT KERNEL!
Nice web site. Just the type I like to read.