Let's have a Slashdot-mediated mirror grinding event! With enough hands and effort we could easily make a giant telescope for only a few hundred pizzas. Then we only need to pay for the rocket; surely if we chipped in a buck or two, that would cover it.
If you do that, you will lose most of your customers. Only big business will want to pay high prices (say a couple of hundred dollars) for any software, and when you reduce your target from everyone (1 billion people) to big businesses (10000?) it's a big deal. Also, you usually need a lot of pull to even get through the door at a company like that, and pull is not something most nerds will have.
> Then why do people keep using TVs, DVD players, stereos, watches, telephones,...?
Because the PC is not as good for those purposes. For example, I can watch TV on my PC, but if I do that I have to sit in a chair through the whole thing to be close enough to see the screen clearly. If I could redirect output to a larger screen on the living room wall, I wouldn't need a TV or a DVD player. People want stereos because they go in the living room, while the PC is in the office. If I could control the PC from the living room and have the sound card output to the speakers there, then I wouldn't need the stereo.
It all comes down to having the interface and the output where you need them, so if Mr.Gates wants us to use the PC for everything, he'll need to make everything into a PC periferal. This will undoubtedly make them cheaper than standalone gadgets, since they will not need processors, memory, software, etc. And I would be quite happy to buy them for the price, the convenience, and the centralized (and programmable!) control.
> Literally hundreds or thousands of programmers that used > to charge for their services now work for free. Definitely > an improvement over the old days where you had to buy every little utility.
Yeah, an improvement for everyone except the programmers... Although, it's not like you could sell "any little utility" in the old days either.
> you can push things called factors around; that > has nothing to do with Fowlerian refactoring
I have never heard of anyone named Fowler, and chances are that most people who speak of "refactoring" had not either. This is not "equivocation" or "fallacy of composition", but rather the difference between the meaning of the word given to it by its creator and the one actually in general use.
> Encapsulation does not decrease coupling in any way; > it simply hides non-coupled parts from one another.
When I tell you to encapsulate your class, I imply that you would also reconsider the design of the other code that uses it to reduce coupling. Encapsulate, as in "put it in a capsule", which other code can swallow regardless of what's inside. To do this, you must define an interface and rewrite all the other code to make proper use of it. I can't see how you can do this without decoupling. I take it that you are one of those people who want everything specified to the last detail, while I am a big-picture person, who assumes that others can figure out the details for themselves. This is obviously the root of our communication problem.
> This is why I suggested Alexandrescu-style functors
Perhaps you could explain what they are? A google search turns up nothing except references to his book. It sounds like a good one, so I'll probably buy it some time, but you really shouldn't assume that everyone in the world has read it.
> You should realize that statics are static variables, and that > static functions, despite having static in their name, are not statics at all.
Well, there we are splitting linguistic hairs again. Human language is not that precise; words are simply references to shared concepts and if your word-concept map is different from mine (and, quite likely from many many other people), there is no need to take offence. As long as you can see what I mean, there should be no problem.
> This is myth: static local arrays are not in any > way faster than nonstatic local arrays.
Big static local arrays are most definitely slower because they are built at runtime:
#include <stdio.h>
int main (void) {
const char* c_Strings[2] = { "Hello", "World" };
for (int i = 0; i < 2; ++ i)
printf ("%s\n", c_Strings[i]);
return (0); }
Try compiling this to assembly. My gcc 3.4.3 generates c_Strings at runtime on the stack, even with optimization turned on. If you make it static, this does not happen. However, speed is not really the issue here; it mainly helps reduce the size of the code.
>> As for threaded code, I never write any > Obviously. You also clearly don't write libraries, > where you cannot guess about the nature of outside code.
On the contrary, I write little but libraries. I just write libraries for non-threaded code, and I don't "guess" the nature of the outside code, I define it by telling the user exactly what the library is for. And it is usually not for threaded applications.
> You do realize that the event mechanism in essentially every > major OS is driven by an underlying threaded model, right?
Absolutely. It doesn't have to be this way though. In fact, to implement a good event mechanism is currently my main personal project, and I am determined to make threads entirely unnecessary in it. Theads create far more problems than they solve, IMO, and I haven't seen any good use for them that I couldn't rework into an asynchronous design. Threads and single-thread event systems really do the same thing: share the CPU between several tasks, with the former doing it at the instruction level and the latter doing it at a logical packet level.
> As far as event driven code being faster, well, horseshit. > Show me non-naive test code which supports this in any way.
According to the FAQ on their website, the membership benefits are pretty much nonexistent. Now that the price is lower, you don't get the magazine any more.
I would say that it is. Mathematically, if you convert (a+b/c)bc into abc+bb and then to b(ac+b), I call it refactoring, since it involves moving factors around. In programming I say "refactoring" to mean "extract interfaces from your code and use them to pull up modules, which can then be encapsulated into classes".
>> Encapsulate everything you possibly can. Make stuff private
> Whereas these are good principles, it will have zero effect on the problem at hand.
It will have a great deal of effect on the problem at hand, which is the increasing the speed of developer builds. If your modules don't let their intrails hang out, changing them does not require rebuilds anywhere outside the module. This is the only real way to solve the problem.
> No. Being static can introduce dozens of subtle > bugs, particularly in threaded or reentrant code
Well, yes; I should have made it more clear that I meant static functions in C, which simply mean that the named function is not used outside the file. The other important use of static is for const arrays inside functions, which should be declared static to allow the compiler to put them in the data segment at compile time instead of building them whenever the function is entered.
As for threaded code, I never write any; in my experience, event-driven asynchronous designs give much better and faster results, because the lack of any data sharing bugs, race conditions, and locks makes debugging easier, and the absence of context switches makes the CPU happier. It also makes data-coupling of components easier.
> Furthermore, this not only has no effect on compile time, > but for primitive types static doesn't have the speed > increase effect most people seem to expect.
Actually, it may decrease performance by causing a cache miss. Local variables on the stack would already be in cache because the top of the stack is a heavily used area, while the data segment, where static variables are, is accessed rarely.
> Whereas things should be const by default, there > are times at which constness is not conceptually > correct despite that you won't be altering the > variable in this particular use.
This is more about interface design, where it is indeed important to determine what is mutable and how. Obviously, in such a case the "make everything you don't modify in const", would not apply. You'd actually have to think:)
> when during the repair of the const correctness mistake > you discover that you have to overhaul 20% of your source base dependencies.
But implementing const correctness in the first place has a much higher cost. I had a job once where I overhauled about 100000 lines of code in trying to implement const correctness. That was about 70% of the codebase. It was all written by people who never used const.
Speeding up a full build should not be important. The only people who care about it are in your test lab doing daily builds and regression tests, who can start the build overnight and have it ready by morning. Of course, this is the situation in a well-designed application. If you find yourself needing a full rebuild all the time, it means one of two things: 1. you are hacking a core component, or 2. all your components are written with spaghetti code and any change in one forces rebuilds in all the others.
In the first case, try just testing one or two components during development, and then verify all the others when the API is stabilized. This is, incidentally, the advantage you gain from using header files: once the API is stable, you never need to rebuild that component again except to fix bugs (which require rebuilding only that component).
In the second case, you need some serious refactoring. Look at the code and break it up. Encapsulate everything you possibly can. Make stuff private and static. Make everything you don't modify const. Keep it up until each component is accessed only through its API and that API is clean. Trust me, this is possible in any project. The enormous decrease in maintenance costs will more than pay for any time you spend on it.
What programmer can resist overoptimization? Here it goes:
> Is Keeping things short preferable, or will two or more pages be acceptable?
The most obvious error is the extra capitalization of Keeping. After fixing that simple bug:
> Is keeping things short preferable, or will two or more pages be acceptable?
Know your API. The english language has a wonderful word for "two or more" that ensures you don't have too many "or"s. This also removes the need for a comma:
> Is keeping things short preferable or will several pages be acceptable?
Making it obvious that the advice is for "you" saves the reader a few brain cycles:
> Should I keep things short or in several pages?
If the first part is true, then the second part is necessarily false. This useful fact allows further contraction and removes a syntax ambiguity between "things" and "pages" that helps brain compiler writers keep their parser simple:
> Should I keep things short?
If you keep "things" short, some people may want to reuse the question for other "things":
> Should things be short?
There. Only 23 characters instead of the original 76. This 70% reduction in size will save brain space and processing power that could be used to write another resume.
Remember that text is human readable only because you have a text editor. Any binary format can be human readable if you have a definition file and an editor that can show the data using it. If such a tool is made available on all platforms, all binary formats will become as easy to read and edit in raw form as text is.
> I am just countering your claim that software > patents shouldn't exist at all) to produce > something useful and novel shouldn't enjoy a > temporary monopoly from the fruits of his labour
If you want to protect your algorithm, just don't release the source code. If you really have a novel idea, chances are that others would not be able to duplicate it just by using the program. This way you get your temporary monopoly without incurring the cost of filing patent lawsuits.
> "all patents must be abolished" responders need > not bother. go visit economic history 101 instead.
There is no evidence whatever that patents promote innovation. In fact, the most pressing problem in modern business is avoiding the use of any patented methods.
> there will never be a problem for a criminal to > find a gun that does not contain this "smart" technology.
The point of "smart guns" is not to prevent you from killing people, but to prevent other people from taking your gun away from you and killing you. This is quite relevant for police officers, who are in most places the only ones with a gun.
It's the stats, silly...
on
Getting the Girl
·
· Score: 2, Funny
> Do you see any short bald dudes with a big pot > belly on any of these boxes either? No, it's all > he-man looking dudes busting at the seams with muscles
Be serious. Why would I want to play a "short bald dude" character? It would be a really boring game since he'd probably have a str of 3 or 4 and a measly 15 hp, giving me hours upon hours of "level grind" until I can get his sorry lazy ass sufficiently trained to take on anything bigger than a rat.
> there is a classical American definition (one that is considered > an insult). That is what USSR and China did.
USSR has never claimed to be a communist society. It was a goal to reach in the future, but certainly not the reality. USSR stands for Union of Soviet Socialist Republics, and none of its citizens ever called its government system "communism". It was called socialism, and it is indeed exactly what you describe: a centrally controlled, planned economy.
> It is one where a small privilaged group of ppl decide > what products to make and how much they will costs. > They are protected by the state by a number of laws > from any real compition.
You are missing the point. There was no competition because there was no such thing as a "company". Competition existed, but only between different factories in the same industry, and consisted mostly of "overachieving the plan"; competing on quantity rather than quality. It's not that increasing quality was beyond them, it's that quality is more difficult to measure when the only way to do so is with quality inspectors.
> They were expensive, quite poorly built, and had poor support.
I'd agree on the last two, but not the first. If anything was plentiful in USSR, it was cheap stuff.
> The largest of the companies would routinely take > over the smaller ones, either by virtue of their size, or by using state laws.
You are thinking of the United States. USSR didn't have companies. (Not until Gorbachev, anyhow)
> it had better milage/better service than American cars. > In terms of safety, well, you died if they crashed. hummmmm....
Nonsense. You obviously haven't seen the Volga; (the second most popular model after Zhiguli). That beast was made of steel so thick, you could drive in Iraq in it. In fact, I remember seeing some neat commercials where it was walked on by elephants, dropped from a three story building, and still started fine and drove away. When you have a planned economy and don't have to pay for the steel, you can use as much as the boss thinks is necessary.
> Ppl would trade goods/service for other goods/service. > I am sure that you have heard the term "house raising" or "Barn raising".
These are entirely different practices. When you barter, you get something you believe to be equally valuable to what you gave away. When you do "barn raising", you are doing community service, where you give away something of value, thinking that you might get something back later. Barter is a trade, with a buyer and a seller. Money just makes the process easier. Community service is not a trade, it's indentured servitude, because you are not guaranteed to get equal value for what you give.
> It was a sign of bad faith to not participate if you were capable. > In fact, to not participate routinely excluded the family from the community.
Same in the USSR under socialism. Boy, I can sure remember washing those floors as a kid...
> A number of them objected to these, as they would stifle innovation.
And they do, as numerous Slashdot articles argue.
> to allow one to produce the idea, but not stifle the future
With the result that nobody ever looks into the Patent database in fear of "willful infringement". So how is this better than just not telling anyone?
> So, I am curious. Which is really communist and which > is true-American capitalists as well as patriots?
Well, gosh darn it, you have nearly convinced me. I'd never thought I would have to agree that the United States is a communist country.
Slashdot Mirror
> it perpetuates the idea it is Linux rather than the
> distribution that would represent the value proposition.
Well then, if Linux doesn't really count, then my favorite distribution is FreeBSD!
The new Xbox is a really drastic 360 degree change in direction!
Let's have a Slashdot-mediated mirror grinding event! With enough hands and effort we could easily make a giant telescope for only a few hundred pizzas. Then we only need to pay for the rocket; surely if we chipped in a buck or two, that would cover it.
See this argument.
> You need to price it high as hell
If you do that, you will lose most of your customers. Only big business will want to pay high prices (say a couple of hundred dollars) for any software, and when you reduce your target from everyone (1 billion people) to big businesses (10000?) it's a big deal. Also, you usually need a lot of pull to even get through the door at a company like that, and pull is not something most nerds will have.
> if they want the software to be free, they use the GPL
Only because of firebrand preaching from GPL fanatics. There are no other reasons.
> The PC has more software, more competition, more richness than anything else
But it does! Except for competition, but I am sure he meant "competition between processes for the CPU".
> Then why do people keep using TVs, DVD players, stereos, watches, telephones, ...?
Because the PC is not as good for those purposes. For example, I can watch TV on my PC, but if I do that I have to sit in a chair through the whole thing to be close enough to see the screen clearly. If I could redirect output to a larger screen on the living room wall, I wouldn't need a TV or a DVD player. People want stereos because they go in the living room, while the PC is in the office. If I could control the PC from the living room and have the sound card output to the speakers there, then I wouldn't need the stereo.
It all comes down to having the interface and the output where you need them, so if Mr.Gates wants us to use the PC for everything, he'll need to make everything into a PC periferal. This will undoubtedly make them cheaper than standalone gadgets, since they will not need processors, memory, software, etc. And I would be quite happy to buy them for the price, the convenience, and the centralized (and programmable!) control.
> Literally hundreds or thousands of programmers that used
> to charge for their services now work for free. Definitely
> an improvement over the old days where you had to buy every little utility.
Yeah, an improvement for everyone except the programmers... Although, it's not like you could sell "any little utility" in the old days either.
Guy: so, what's your number?
Girl: It's in Pi.
Guy: but I don't know your name to do the checksum!
Girl: It's in Pi too.
> Then, the competition will be between companies
> and not some sort of xenophobic constest between
> mutually distrustful national governments.
You mean, like Microsoft and... uh...
> has nothing to do with Fowlerian refactoring
I have never heard of anyone named Fowler, and chances are that most people who speak of "refactoring" had not either. This is not "equivocation" or "fallacy of composition", but rather the difference between the meaning of the word given to it by its creator and the one actually in general use.
> Encapsulation does not decrease coupling in any way;
> it simply hides non-coupled parts from one another.
When I tell you to encapsulate your class, I imply that you would also reconsider the design of the other code that uses it to reduce coupling. Encapsulate, as in "put it in a capsule", which other code can swallow regardless of what's inside. To do this, you must define an interface and rewrite all the other code to make proper use of it. I can't see how you can do this without decoupling. I take it that you are one of those people who want everything specified to the last detail, while I am a big-picture person, who assumes that others can figure out the details for themselves. This is obviously the root of our communication problem.
> This is why I suggested Alexandrescu-style functors
Perhaps you could explain what they are? A google search turns up nothing except references to his book. It sounds like a good one, so I'll probably buy it some time, but you really shouldn't assume that everyone in the world has read it.
> You should realize that statics are static variables, and that
> static functions, despite having static in their name, are not statics at all.
Well, there we are splitting linguistic hairs again. Human language is not that precise; words are simply references to shared concepts and if your word-concept map is different from mine (and, quite likely from many many other people), there is no need to take offence. As long as you can see what I mean, there should be no problem.
> This is myth: static local arrays are not in any
> way faster than nonstatic local arrays.
Big static local arrays are most definitely slower because they are built at runtime:
Try compiling this to assembly. My gcc 3.4.3 generates c_Strings at runtime on the stack, even with optimization turned on. If you make it static, this does not happen. However, speed is not really the issue here; it mainly helps reduce the size of the code.
>> As for threaded code, I never write any
> Obviously. You also clearly don't write libraries,
> where you cannot guess about the nature of outside code.
On the contrary, I write little but libraries. I just write libraries for non-threaded code, and I don't "guess" the nature of the outside code, I define it by telling the user exactly what the library is for. And it is usually not for threaded applications.
> You do realize that the event mechanism in essentially every
> major OS is driven by an underlying threaded model, right?
Absolutely. It doesn't have to be this way though. In fact, to implement a good event mechanism is currently my main personal project, and I am determined to make threads entirely unnecessary in it. Theads create far more problems than they solve, IMO, and I haven't seen any good use for them that I couldn't rework into an asynchronous design. Threads and single-thread event systems really do the same thing: share the CPU between several tasks, with the former doing it at the instruction level and the latter doing it at a logical packet level.
> As far as event driven code being faster, well, horseshit.
> Show me non-naive test code which supports this in any way.
I can point you to the
Maybe the probe is going through thick clouds and the friction on the hull increases while inside.
According to the FAQ on their website, the membership benefits are pretty much nonexistent. Now that the price is lower, you don't get the magazine any more.
> Decoupling isn't refactoring.
:)
I would say that it is. Mathematically, if you convert (a+b/c)bc into abc+bb and then to b(ac+b), I call it refactoring, since it involves moving factors around. In programming I say "refactoring" to mean "extract interfaces from your code and use them to pull up modules, which can then be encapsulated into classes".
>> Encapsulate everything you possibly can. Make stuff private
> Whereas these are good principles, it will have zero effect on the problem at hand.
It will have a great deal of effect on the problem at hand, which is the increasing the speed of developer builds. If your modules don't let their intrails hang out, changing them does not require rebuilds anywhere outside the module. This is the only real way to solve the problem.
> No. Being static can introduce dozens of subtle
> bugs, particularly in threaded or reentrant code
Well, yes; I should have made it more clear that I meant static functions in C, which simply mean that the named function is not used outside the file. The other important use of static is for const arrays inside functions, which should be declared static to allow the compiler to put them in the data segment at compile time instead of building them whenever the function is entered.
As for threaded code, I never write any; in my experience, event-driven asynchronous designs give much better and faster results, because the lack of any data sharing bugs, race conditions, and locks makes debugging easier, and the absence of context switches makes the CPU happier. It also makes data-coupling of components easier.
> Furthermore, this not only has no effect on compile time,
> but for primitive types static doesn't have the speed
> increase effect most people seem to expect.
Actually, it may decrease performance by causing a cache miss. Local variables on the stack would already be in cache because the top of the stack is a heavily used area, while the data segment, where static variables are, is accessed rarely.
> Whereas things should be const by default, there
> are times at which constness is not conceptually
> correct despite that you won't be altering the
> variable in this particular use.
This is more about interface design, where it is indeed important to determine what is mutable and how. Obviously, in such a case the "make everything you don't modify in const", would not apply. You'd actually have to think
> when during the repair of the const correctness mistake
> you discover that you have to overhaul 20% of your source base dependencies.
But implementing const correctness in the first place has a much higher cost. I had a job once where I overhauled about 100000 lines of code in trying to implement const correctness. That was about 70% of the codebase. It was all written by people who never used const.
Speeding up a full build should not be important. The only people who care about it are in your test lab doing daily builds and regression tests, who can start the build overnight and have it ready by morning. Of course, this is the situation in a well-designed application. If you find yourself needing a full rebuild all the time, it means one of two things: 1. you are hacking a core component, or 2. all your components are written with spaghetti code and any change in one forces rebuilds in all the others.
In the first case, try just testing one or two components during development, and then verify all the others when the API is stabilized. This is, incidentally, the advantage you gain from using header files: once the API is stable, you never need to rebuild that component again except to fix bugs (which require rebuilding only that component).
In the second case, you need some serious refactoring. Look at the code and break it up. Encapsulate everything you possibly can. Make stuff private and static. Make everything you don't modify const. Keep it up until each component is accessed only through its API and that API is clean. Trust me, this is possible in any project. The enormous decrease in maintenance costs will more than pay for any time you spend on it.
What programmer can resist overoptimization? Here it goes:
> Is Keeping things short preferable, or will two or more pages be acceptable?
The most obvious error is the extra capitalization of Keeping. After fixing that simple bug:
> Is keeping things short preferable, or will two or more pages be acceptable?
Know your API. The english language has a wonderful word for "two or more" that ensures you don't have too many "or"s. This also removes the need for a comma:
> Is keeping things short preferable or will several pages be acceptable?
Making it obvious that the advice is for "you" saves the reader a few brain cycles:
> Should I keep things short or in several pages?
If the first part is true, then the second part is necessarily false. This useful fact allows further contraction and removes a syntax ambiguity between "things" and "pages" that helps brain compiler writers keep their parser simple:
> Should I keep things short?
If you keep "things" short, some people may want to reuse the question for other "things":
> Should things be short?
There. Only 23 characters instead of the original 76. This 70% reduction in size will save brain space and processing power that could be used to write another resume.
Remember that text is human readable only because you have a text editor. Any binary format can be human readable if you have a definition file and an editor that can show the data using it. If such a tool is made available on all platforms, all binary formats will become as easy to read and edit in raw form as text is.
> I am just countering your claim that software
> patents shouldn't exist at all) to produce
> something useful and novel shouldn't enjoy a
> temporary monopoly from the fruits of his labour
If you want to protect your algorithm, just don't release the source code. If you really have a novel idea, chances are that others would not be able to duplicate it just by using the program. This way you get your temporary monopoly without incurring the cost of filing patent lawsuits.
> "all patents must be abolished" responders need
> not bother. go visit economic history 101 instead.
There is no evidence whatever that patents promote innovation. In fact, the most pressing problem in modern business is avoiding the use of any patented methods.
> there will never be a problem for a criminal to
> find a gun that does not contain this "smart" technology.
The point of "smart guns" is not to prevent you from killing people, but to prevent other people from taking your gun away from you and killing you. This is quite relevant for police officers, who are in most places the only ones with a gun.
> If you're dealing with someone who has the foresight to use an EMP pulse
You mean, like the police?
"Hey, matey, got a match?"
> Do you see any short bald dudes with a big pot
> belly on any of these boxes either? No, it's all
> he-man looking dudes busting at the seams with muscles
Be serious. Why would I want to play a "short bald dude" character? It would be a really boring game since he'd probably have a str of 3 or 4 and a measly 15 hp, giving me hours upon hours of "level grind" until I can get his sorry lazy ass sufficiently trained to take on anything bigger than a rat.
> I also remember thinking "That's not building a pc" ...
>
> PCs are appliances and talking about how people are "modding" them
Sort of like games nowadays. Nobody writes them any more. Everyone just mods the ones he buys.
> there is a classical American definition (one that is considered
> an insult). That is what USSR and China did.
USSR has never claimed to be a communist society. It was a goal to reach in the future, but certainly not the reality. USSR stands for Union of Soviet Socialist Republics, and none of its citizens ever called its government system "communism". It was called socialism, and it is indeed exactly what you describe: a centrally controlled, planned economy.
> It is one where a small privilaged group of ppl decide
> what products to make and how much they will costs.
> They are protected by the state by a number of laws
> from any real compition.
You are missing the point. There was no competition because there was no such thing as a "company". Competition existed, but only between different factories in the same industry, and consisted mostly of "overachieving the plan"; competing on quantity rather than quality. It's not that increasing quality was beyond them, it's that quality is more difficult to measure when the only way to do so is with quality inspectors.
> They were expensive, quite poorly built, and had poor support.
I'd agree on the last two, but not the first. If anything was plentiful in USSR, it was cheap stuff.
> The largest of the companies would routinely take
> over the smaller ones, either by virtue of their size, or by using state laws.
You are thinking of the United States. USSR didn't have companies. (Not until Gorbachev, anyhow)
> it had better milage/better service than American cars.
> In terms of safety, well, you died if they crashed. hummmmm....
Nonsense. You obviously haven't seen the Volga; (the second most popular model after Zhiguli). That beast was made of steel so thick, you could drive in Iraq in it. In fact, I remember seeing some neat commercials where it was walked on by elephants, dropped from a three story building, and still started fine and drove away. When you have a planned economy and don't have to pay for the steel, you can use as much as the boss thinks is necessary.
> Ppl would trade goods/service for other goods/service.
> I am sure that you have heard the term "house raising" or "Barn raising".
These are entirely different practices. When you barter, you get something you believe to be equally valuable to what you gave away. When you do "barn raising", you are doing community service, where you give away something of value, thinking that you might get something back later. Barter is a trade, with a buyer and a seller. Money just makes the process easier. Community service is not a trade, it's indentured servitude, because you are not guaranteed to get equal value for what you give.
> It was a sign of bad faith to not participate if you were capable.
> In fact, to not participate routinely excluded the family from the community.
Same in the USSR under socialism. Boy, I can sure remember washing those floors as a kid...
> A number of them objected to these, as they would stifle innovation.
And they do, as numerous Slashdot articles argue.
> to allow one to produce the idea, but not stifle the future
With the result that nobody ever looks into the Patent database in fear of "willful infringement". So how is this better than just not telling anyone?
> So, I am curious. Which is really communist and which
> is true-American capitalists as well as patriots?
Well, gosh darn it, you have nearly convinced me. I'd never thought I would have to agree that the United States is a communist country.