My short repsonse to the article:
these are just few examples for when it would be nice to have more multithreading applied to all kinds of programs. It's not nice if you can't even move a window on screen because the interface is blocking on something. Multithreading is the way to go. Everyone agrees on the problem. Things block. And no, multithreading is not necessarily the answer to that. An article is OK to claim that it is - but it seems to imply its the only way, which is an unfortunately common misunderstanding. Am I to take advice about threading from someone who does not seem to even know what the alternative is?
After reading some more just to make sure I was not misunderstanding him, and that he really does not understand, there is really no need for me to read any longer.
You are wrong, so maybe your tone should be a little more humble:-)
Its obvious that you don't know about asynchronous I/O. Single-threaded designs are not meant for you to create threads in your event handlers, but to do your event handling asynchronously. See Twisted as an example.
This gets rid of all the thread problems, and introduces a few problems which are far easier to handle. The main problem it introduces, is that long computations or blocking operations will block the entire program. However, finding those bugs, and fixing them (e.g: converting those to be split/asynchronous, or very rarely, have their own process), is a much easier and more cost-effective process.
Games indeed have no OSS equivalent (Not that I find having them a good justification of copyrights, even if indeed copyrights are neccessary!)
Its important to understand that the existence of copyrighted software to perform a certain task is a huge disincentive for the market to summon the creation of any opensource equivalent of that task.
In today's world, if OpenOffice is the only option, and OpenOffice has a problem that a business cannot handle, it will buy Microsoft Office.
If copyrights are abolished and OpenOffice is the only option, and has a problem that a business cannot handle, it will pay a software firm to fix it for them - which would make the result available for everyone else, as a side effect.
Even if as many as 80% of businesses will attempt to keep improvements inhouse, the 20% who won't (as software has little to do with their business) will more than make up for it.
Also, laws can be made to protect those who "leak" software improvements to the world (against losing their job, etc) as they are acting in the benefit of society as a whole.
C++ and threading each introduce high complexity and difficulty, and their combination might even be worse.
While they can be used to achieve great performance, your claim was that they made programming easy.
How was it easy? Did you not have to deal with synchronization of your objects between the threads? Did you not have to debug non-deterministic race conditions? Deadlocks?
No. I suggest that it is one driver for the creation of content. Clearly other mechanisms from live performance to altruism also serve as effective motivators to varying degrees.
I believe the main driver is the free market.
I have suggested before that the biggest single advantage of a copyright-style framework over any other method I've seen proposed is that it provides a credible mechanism for creators to make expensive works and each of many consumers to contribute a small share of the cost. In other words, it encourages the widest possible distribution of the works that take the most time and effort to produce, rather than charging higher amounts by making enjoyment of such works a scarce commodity (commissioned work, limited ticket sales at concerts, etc.).
It most certainly does not encourage the widest possible distribution, by placing artificial scarcity on the distribution. Limited ticket sales at concerts do not pose any limit whatsoever on the distribution of recordings of such concerts. That maximizes distribution, copyright does not.
Free Software is a terrible example to use if you're trying to show a better way than copyright. The amount of useful, high quality commercial software developed via copyright absolutely dwarfs the amount of useful, high quality software developed under a Free Software model. Even flagship Free Software titles are often not as good as the commercial equivalents. And of course, this particular argument ignores the fact that commercial software development pays the rent for a large proportion of the people who contribute to Free Software in their spare time.
Firstly, you are confusing "commercial" with closed-source (as many open-source products are commercial).
I believe Free Software is a great example. Copyright makes it possible to highly increase the funding of software projects, and yet Free Software can still compete and often beat the quality of closed-source software whose distribution is artificially scarce. This is significant evidence that the Free Software model works better and more efficiently. It creates higher-quality software for a fraction of the price. It is true that many open-source developers are funded by closed-source work. However, I believe that if copyrights are abolished, closed-source software will cease to exist, and the free market will summon the creation of open-source work. A lot more people will get paid to do open source work than they are today.
About your claim about the quality, the only such package I know of such claim is Photoshop. Lets see some Free Software vs Closed Software comparisons from various times, and see if you can get a concensus about your quality statement:
Linux kernel vs the Windows kernel.
Firefox vs Internet Explorer.
Python/Ruby/Perl vs Visual Basic.
Thunderbird vs Outlook express.
Linux's automatic package management (apt) vs the lack thereof.
Compiz vs Auro.
KDE/Gnome vs the Windows desktop.
In my opinion, much software progress was made up to the darkness of the 80's, when software was still being researched and developed in the open (the creation of Lisp, C, UNIX, Smalltalk, TCP/IP and many more). Once software copyrights took hold, "closed-source" de-facto standards such as (.DOC, WinAPI, etc) took hold. The Windows line became standard (A huge step back from Unix). Visual Basic was created. This is the contribution copyrights to the world of software. The amount of man-years wasted on reverse-engineering or reimplementing basic features in the closed-source world is staggering.
Again, this one is easy: far less work was produced, and far fewer people enjoyed it because it wasn't as widely available.
The fact fewer people enjoyed it is not due to the lack of copyright, it is due to the lack of distribution technologies. It was as widely a
You seem to try and imply that copyright, or more specifically, the collection of royalty payment for each copy, is the primary driver for the creation of content.
If that is the case, how do you explain the masses of Free Software? How do you explain the rich culture and works that were created before copyrights were even invented? How do you explain the fact that publishers struggled to be the ones to get to publish the 9/11 Commission Report, even though they could not get a copyright on it, and even though any other publisher could publish it as well? How do you explain that this report made quite a buck for the publisher that published it anyhow?
If indeed copyright drives quality content (which I believe it does not), is it really worth the extra laws that have to imposed on all citizens? Is it worth the trouble of policing information?
Israel targets only militants, but due to them hiding in condensed civilian populace, civilians get killed. The Palestinians are targeting innocent civilians, even though they could target just the military without getting any civilians killed at all.
I agree there's a problem. I think the problem is that __iter__ on iterators returns self.
I think that you don't want a "for" loop or general iteration to just take an iterator and continue where it left off by default.
If it used an explicit syntax, such as:
for item in tillend(iter): # where tillend takes an iterator, and has an __iter__ that returns that iterator.
Is less error-prone than:
for item in iter:
Exactly because of the reason you mention.
It will be clear that: for item in tillend(iter):... for item in tillend(iter):...
is problematic, because tillend makes clear that its a stateful iterator being consumed.
As for a workaround for now, just be careful to always assume you're being given an iterator, and list'ify it when you want to iterate it more than once. Also make sure you name iterators "iter" something so you don't forget that they are stateful.
Implement address space separations for security/reliability purposes
I believe the use of superior hardware access, and address space separations should die out in favor of an alternative: runtime-level protection.
As more and more systems move to be based on bytecode-running virtual machines and as JIT's and hardware improves, it is becoming clearer that in the future, "static native code" (C/C++ executables and such) will die out to make room for JIT'd native code (Java/.NET). I believe that this will happen because JIT can and will optimize better than a static compiler running completely before execution. Such languages are also easier to develop with.
Once such runtimes are used, some aspects of reliability/safety are guaranteed (memory overruns cannot occur. References to inaccessible objects cannot be synthesized). By relying on these measures for security, as well, we can eliminate both the need for elevated kernel access, and address space/context switches. This is desirable for several reasons:
Simplicity. Lack of address space separations (processes) is simpler.
Uniformity of communication: Objects can use one another without regard of "process boundaries", as long as a reference to the object exists.
Performance: While "safe" languages are considered of lower performance today (and will have better JIT'd performance in the future), they can eliminate context and address space switches which have considerable costs in current systems.
Once relying on the runtime for security and reliability, a "kernel" becomes nothing more than a thread scheduler and a hardware abstraction object library.
I believe this is the correct design for future systems, and is my answer to the micro vs monolothic question: Neither!
You're probably make wires of a different material. Or with some kind of antibiotic. Its probably a simpler problem to solve than an all-wire eating menace that cannot be destroyed.
The point is that when deciding whether to join a war, it doesn't matter what the leaders think, or their inner motivations. What matters is what they do.
The leaders may be filthy scumbags, but if they give an opportunity to fight against the Hitler menace, good moral people take that opportunity.
The Poland example is quite irrelevant. The leaders did not go to war to protect Poland at all - they went to war because Hitler violated his treaties, and they finally realized he's not going to stop until they stop him. This realization simply came about when Germany invaded Poland.
They should have gone to war, along with the Czech who wanted to fight him, but Chamberlain was a fool and thought he could appease Hitler.
Besides, "expansionism" can even be moral, if this expansion replaces a brutal regime in that area.
In summary your post is about random facts from the war, some of which show that millionaires had an interest in the conflict. You basically also said that from a purely selfish perspective, going to fight for your country is not the best option.
To both of those points, may I say: DUH.
My point with bringing up that war as a justified war. Fighting against the Nazis was a noble and worthy goal, one that people less selfish than yourself dearly cared about and thus joined the war, and sacrificed so much.
May I suggest to you to try to become, or at least try to look a bit less selfish.
A figure I read in Peak oil awareness claims that to effectively replace gasoline with solar panels, we need to replace the current 10 square kilometers of solar panels in the world today, with 300,000 square kilometers.
The reason no new refineries are being built, is because the oil companies know that the amount of new oil left to discover is smaller than the amount current refineries can handle.
That is - peak oil has arrived, and there's not much left to refine.
Its not that _my_ code and comments go out of sync. Its that it is rare that I can't get the code to speak for itself, without comments being necessary.
It does happen, and I do sometimes have to write some comments because communicating something via the naming or other coding artifacts is impossible, but only very rarely.
Discipline is nice, and you should have it, but a system that requires less of it is better, because discipline is not boolean. Whenever discipline is required, some percentage of the time, it will not be adhered, and if there's an alternative that requires less discipline, its a better one.
I also despise the XP directive to not comment code, which Fowler promotes. Consider the goal, not the means. The goal is documenting the code. Those who go against comments (me included) are not against documentation of the code. We are against documentation that may easily lose sync with the code, where better forms of documentation exist.
The other forms of documentation are meaningful names. If you want to document a sub-expression, which does not have a name, give it a name, by assigning it into a variable before using it. If a piece of code does not have a name, then give it a name by putting it in a separate function.
Variable and function names are much less likely to go out of sync with the meaning of the code than comments are, are more concise and less redundant (so they avoid violating the DRY principle).
Remember, bad/wrong documentation is worse than no documentation.
As to the Rupert Sheldrake thing: It is bogus. My mind doesn't influence anything. If I ran under a train the morning of the election (so I wouldn't vote anymore), no one else's mind would change because of that. Sheldrake's nonsense has been experimentally tested to be just that.
Its not that your mind is influencing things. And also, sometimes your mind's process P will generate some really rare results, given weird enough inputs (I doubt that they are _that_ rare, though -- If they actually tested that by, say, going away on the voting day, they'd probably not be the only ones to do so, from the exact same considerations!)
Let me demonstrate the philosophical argument another way: Say there are a bunch of foreign people from the same country on a bus.
I ask you to guess their answer to the question: "How are you?", I give you 3 options. Then, I tell you that the answer to the question by the first guy was "Great, mate'", which is one of the 3 options. Will you not raise the odds that the other foreigners from the same country also answer the same?
When the brain process is simple enough (almost identical environment, probably similar moods, and an identical question), it takes just a few people to find correlation between seemingly independent decisions. Surely you are going to say the first person asked is not influencing the other persons who don't even know he was asked, to answer the same. Yet whatever it is that he chooses seemingly independently to answer, raises the odds of that same answer being answered from the others.
In much more complicated environments, such as elections, the correlation wouldn't be as strong, ofcourse, but it would still be there, especially with so many people involved.
If your brain process is truly unique and not correlated to any other brain process, then I agree - there is no point for you to vote.
"Its impossible to sum the goods and bads of an idea that wasn't tried out." It is very well possible to decide on the sum of good and bad without trying. I guess that if I had had the plan to hand out atomic bombs to Palestinians, you would agree that the balance is negative. Or do you insist on a trial first?
My intuition agrees, but I don't find it completely impossible that giving the Palestinians a-bombs would have surprising effects, perhaps positive. Perhaps their threat of using it would change public opinion in Israel, which would then accelerate peace. Ofcourse I don't believe that, but I am just illustrating that counter-intuitive results are possible.
The soviets getting a-bombs un-intuitively prevented war, rather than cause it. Global warming may lead to a cooling of Europe, due to a change of direction in the gulf stream. And so on.
But even if we cannot predict the sum, we can try it, just once, on a small scale and if society doesn't shatter we could do it again on a somewhat larger scale etc.
With that I can agree! That sounds like a plan. "Small scale" should probably translate to "few people" at first, and to a "limited time span" later, and only after being reasonably sure of the safety, it can become a system.
"How do you know that everything is out in the open? " Please give trying the idea of comparing a proposal with the current situation another shot. How many of the ideas, facts provided etc. are in the open now? If you send a letter to a politician, you cannot even be sure it goes past his/her secretary. You may receive a response, with an argument that you may or may not be able to refute. If someone else could the likelihood that he would hear about it from you is next to zero.
That is a very bad example. You are proposing to change the system of elections, not the system of politician communications. The voting is currently implemented with technology simple enough, that creating large-scale frauds in ways that average people serving as observ
Of course, any woman that doesn't accept you as life-partner because you didn't spend enough money on her engagement item is superficial, materialistic trash anyway. By requiring that the male spend a lot of resources on the gift, the female:
Makes it less likely that this male is wasting his efforts on competing females.
Gets proof that the male has enough resources that its worthwhile for him to spend many of them on her.
Its simply the manifestation an evolutionary mechanism: the handicap principle.
Tell me one thing. Did your 100% test coverage only cover modules, nicely and cleanly separated and spoon fed under controlled conditions, or did you also test concurrency issues under various heavy processing and communication loads? All that on embedded hardware? Oh... I thought so. Not sure where I got personal, boy. Anyhow, our 100% test coverage covered, as I said, certain non-trivial modules. I cannot expand too much on details here, but the tests covered real use conditions, and not a single implementation bug regarding these modules was reported from the customer at any later stage. Some bugs existed, but they were specification-level.
Not every piece of code is a Windows GUI to access a database. Where I work, we are in a highly competitive safety related embedded market. Our customers are mainly military all over the world. In case our hardware or software makes a mistake, we can't pop up a window and say "sorry for the inconvenience". In the extreme cases, people's lives can be at stake. We are EXTREMELY cautious about how we write code, up to the point of being PARANOID, and believe me, if you knew who we are, you'd be glad we are like that. Good for you. Sounds like you should be working harder to get 100% coverage then:-) You also implied you have a lot of concurrency. You might want to reduce the concurrency for better testability and reliability, if that is possible.
And according to your remark on what we deserve: tell that to Ariane V people. NO amount of testing, code reviews or strict coding standards and processes makes your code completely free of errors. Some of our customers even want to know the exact numbers of code lines added/modified/removed while accessing the criticality of a change request. Beautifying the variables "to be more readable" can be an option for you. It's not for us. I also have vast experience in the realm of extremely-reliable software - and my experience indicates that refactoring is a positive thing towards that goal, not a negative one.
If you let code duplication remain, If you let misleading variable names remain, If you let tight coupling remain,
all because you fear modifying the code: you've already lost - simply because these attributes of the code will soon translate into bugs as soon as that code is touched, and you will eventually need to modify code.
These two approaches to handling high-reliability code tend to self-reinforce themselves:
Those that believe code mustn't be touched - end up with code duplication and misleading names that they dare not fix. Then the code really becomes untouchable, because modifying code with these harmful properties without inserting bugs is virtually impossible. When they try to make any change, they will get burnt by the bugs, and further reinforce that changes should not be made.
Those that believe code must always be top-notch-quality, even at the costs of more test coverage that allows for more confidence in making changes, will have better code that is not untouchable. They will succeed when changing the code which will reinforce their approach that changes are relatively safe.
I think you might be inside an environment that's dug itself up into the first category, and can no longer get out.
Where I worked, we had people with both mindsets, and while both were equally successful in the resulting reliability that they achieved, the latter group could handle more complicated requirements and obviously had much more dynamic code that could handle "moving target" requirements. The better quality, more readable and more reusable code was also a nice side effect of the latter approach.
Slashdot Mirror
After reading some more just to make sure I was not misunderstanding him, and that he really does not understand, there is really no need for me to read any longer.
You are wrong, so maybe your tone should be a little more humble :-)
Its obvious that you don't know about asynchronous I/O. Single-threaded designs are not meant for you to create threads in your event handlers, but to do your event handling asynchronously. See Twisted as an example.
This gets rid of all the thread problems, and introduces a few problems which are far easier to handle. The main problem it introduces, is that long computations or blocking operations will block the entire program. However, finding those bugs, and fixing them (e.g: converting those to be split/asynchronous, or very rarely, have their own process), is a much easier and more cost-effective process.
Games indeed have no OSS equivalent (Not that I find having them a good justification of copyrights, even if indeed copyrights are neccessary!)
Its important to understand that the existence of copyrighted software to perform a certain task is a huge disincentive for the market to summon the creation of any opensource equivalent of that task.
In today's world, if OpenOffice is the only option, and OpenOffice has a problem that a business cannot handle, it will buy Microsoft Office.
If copyrights are abolished and OpenOffice is the only option, and has a problem that a business cannot handle, it will pay a software firm to fix it for them - which would make the result available for everyone else, as a side effect.
Even if as many as 80% of businesses will attempt to keep improvements inhouse, the 20% who won't (as software has little to do with their business) will more than make up for it.
Also, laws can be made to protect those who "leak" software improvements to the world (against losing their job, etc) as they are acting in the benefit of society as a whole.
C++ and threading each introduce high complexity and difficulty, and their combination might even be worse.
While they can be used to achieve great performance, your claim was that they made programming easy.
How was it easy? Did you not have to deal with synchronization of your objects between the threads? Did you not have to debug non-deterministic race conditions? Deadlocks?
No. I suggest that it is one driver for the creation of content. Clearly other mechanisms from live performance to altruism also serve as effective motivators to varying degrees.
I believe the main driver is the free market.
I have suggested before that the biggest single advantage of a copyright-style framework over any other method I've seen proposed is that it provides a credible mechanism for creators to make expensive works and each of many consumers to contribute a small share of the cost. In other words, it encourages the widest possible distribution of the works that take the most time and effort to produce, rather than charging higher amounts by making enjoyment of such works a scarce commodity (commissioned work, limited ticket sales at concerts, etc.).
It most certainly does not encourage the widest possible distribution, by placing artificial scarcity on the distribution. Limited ticket sales at concerts do not pose any limit whatsoever on the distribution of recordings of such concerts. That maximizes distribution, copyright does not.
Free Software is a terrible example to use if you're trying to show a better way than copyright. The amount of useful, high quality commercial software developed via copyright absolutely dwarfs the amount of useful, high quality software developed under a Free Software model. Even flagship Free Software titles are often not as good as the commercial equivalents. And of course, this particular argument ignores the fact that commercial software development pays the rent for a large proportion of the people who contribute to Free Software in their spare time.
Firstly, you are confusing "commercial" with closed-source (as many open-source products are commercial).
I believe Free Software is a great example. Copyright makes it possible to highly increase the funding of software projects, and yet Free Software can still compete and often beat the quality of closed-source software whose distribution is artificially scarce. This is significant evidence that the Free Software model works better and more efficiently. It creates higher-quality software for a fraction of the price.
It is true that many open-source developers are funded by closed-source work. However, I believe that if copyrights are abolished, closed-source software will cease to exist, and the free market will summon the creation of open-source work. A lot more people will get paid to do open source work than they are today.
About your claim about the quality, the only such package I know of such claim is Photoshop. Lets see some Free Software vs Closed Software comparisons from various times, and see if you can get a concensus about your quality statement:
In my opinion, much software progress was made up to the darkness of the 80's, when software was still being researched and developed in the open (the creation of Lisp, C, UNIX, Smalltalk, TCP/IP and many more).
Once software copyrights took hold, "closed-source" de-facto standards such as (.DOC, WinAPI, etc) took hold. The Windows line became standard (A huge step back from Unix). Visual Basic was created. This is the contribution copyrights to the world of software. The amount of man-years wasted on reverse-engineering or reimplementing basic features in the closed-source world is staggering.
Again, this one is easy: far less work was produced, and far fewer people enjoyed it because it wasn't as widely available.
The fact fewer people enjoyed it is not due to the lack of copyright, it is due to the lack of distribution technologies. It was as widely a
You seem to try and imply that copyright, or more specifically, the collection of royalty payment for each copy, is the primary driver for the creation of content.
If that is the case, how do you explain the masses of Free Software?
How do you explain the rich culture and works that were created before copyrights were even invented?
How do you explain the fact that publishers struggled to be the ones to get to publish the 9/11 Commission Report, even though they could not get a copyright on it, and even though any other publisher could publish it as well? How do you explain that this report made quite a buck for the publisher that published it anyhow?
If indeed copyright drives quality content (which I believe it does not), is it really worth the extra laws that have to imposed on all citizens? Is it worth the trouble of policing information?
Its not about the number of dead.
Its about intent.
Israel targets only militants, but due to them hiding in condensed civilian populace, civilians get killed.
The Palestinians are targeting innocent civilians, even though they could target just the military without getting any civilians killed at all.
I agree there's a problem. I think the problem is that __iter__ on iterators returns self.
... ...
I think that you don't want a "for" loop or general iteration to just take an iterator and continue where it left off by default.
If it used an explicit syntax, such as:
for item in tillend(iter): # where tillend takes an iterator, and has an __iter__ that returns that iterator.
Is less error-prone than:
for item in iter:
Exactly because of the reason you mention.
It will be clear that:
for item in tillend(iter):
for item in tillend(iter):
is problematic, because tillend makes clear that its a stateful iterator being consumed.
As for a workaround for now, just be careful to always assume you're being given an iterator, and list'ify it when you want to iterate it more than once. Also make sure you name iterators "iter" something so you don't forget that they are stateful.
They do this using:
I believe the use of superior hardware access, and address space separations should die out in favor of an alternative: runtime-level protection.
As more and more systems move to be based on bytecode-running virtual machines and as JIT's and hardware improves, it is becoming clearer that in the future, "static native code" (C/C++ executables and such) will die out to make room for JIT'd native code (Java/.NET).
I believe that this will happen because JIT can and will optimize better than a static compiler running completely before execution. Such languages are also easier to develop with.
Once such runtimes are used, some aspects of reliability/safety are guaranteed (memory overruns cannot occur. References to inaccessible objects cannot be synthesized). By relying on these measures for security, as well, we can eliminate both the need for elevated kernel access, and address space/context switches. This is desirable for several reasons:
Once relying on the runtime for security and reliability, a "kernel" becomes nothing more than a thread scheduler and a hardware abstraction object library.
I believe this is the correct design for future systems, and is my answer to the micro vs monolothic question: Neither!
You're probably make wires of a different material. Or with some kind of antibiotic. Its probably a simpler problem to solve than an all-wire eating menace that cannot be destroyed.
The point is that when deciding whether to join a war, it doesn't matter what the leaders think, or their inner motivations. What matters is what they do.
The leaders may be filthy scumbags, but if they give an opportunity to fight against the Hitler menace, good moral people take that opportunity.
The Poland example is quite irrelevant. The leaders did not go to war to protect Poland at all - they went to war because Hitler violated his treaties, and they finally realized he's not going to stop until they stop him. This realization simply came about when Germany invaded Poland.
They should have gone to war, along with the Czech who wanted to fight him, but Chamberlain was a fool and thought he could appease Hitler.
Besides, "expansionism" can even be moral, if this expansion replaces a brutal regime in that area.
The brain treats the body as though it was a tool!
(and it is one)
In summary your post is about random facts from the war, some of which show that millionaires had an interest in the conflict.
You basically also said that from a purely selfish perspective, going to fight for your country is not the best option.
To both of those points, may I say: DUH.
My point with bringing up that war as a justified war. Fighting against the Nazis was a noble and worthy goal, one that people less selfish than yourself dearly cared about and thus joined the war, and sacrificed so much.
May I suggest to you to try to become, or at least try to look a bit less selfish.
So you're saying Israel should just kill all of the Palestinians?
Its certainly in its physical power (probably not politically/internationally possible, ofcourse).
You are a little cynical, aren't you?
Would you not have fought for the allies in World War II?
Was it also a fight for the millionaires?
Given that it takes a few decades to rebuild a given city with enough financial backing, you can't really "set back" a country more than that.
The wires you mention destroying probably require a few months to a few years to rebuild...
A figure I read in Peak oil awareness claims that to effectively replace gasoline with solar panels, we need to replace the current 10 square kilometers of solar panels in the world today, with 300,000 square kilometers.
Sounds kind of impractical.
The reason no new refineries are being built, is because the oil companies know that the amount of new oil left to discover is smaller than the amount current refineries can handle.
That is - peak oil has arrived, and there's not much left to refine.
An even more blatant example: Intellectual Weapons.
(They buy vulnerabilities from security researchers, and then they try to patent all possible security fixes)
To them, perhaps.
But I act according to me, not according to them.
Moral differences can and should lead to conflicts - you should fight for your morals, not others'.
Its not that _my_ code and comments go out of sync. Its that it is rare that I can't get the code to speak for itself, without comments being necessary.
It does happen, and I do sometimes have to write some comments because communicating something via the naming or other coding artifacts is impossible, but only very rarely.
Discipline is nice, and you should have it, but a system that requires less of it is better, because discipline is not boolean. Whenever discipline is required, some percentage of the time, it will not be adhered, and if there's an alternative that requires less discipline, its a better one.
The other forms of documentation are meaningful names. If you want to document a sub-expression, which does not have a name, give it a name, by assigning it into a variable before using it. If a piece of code does not have a name, then give it a name by putting it in a separate function.
Variable and function names are much less likely to go out of sync with the meaning of the code than comments are, are more concise and less redundant (so they avoid violating the DRY principle).
Remember, bad/wrong documentation is worse than no documentation.
As to the Rupert Sheldrake thing: It is bogus. My mind doesn't influence anything. If I ran under a train the morning of the election (so I wouldn't vote anymore), no one else's mind would change because of that. Sheldrake's nonsense has been experimentally tested to be just that.
Its not that your mind is influencing things. And also, sometimes your mind's process P will generate some really rare results, given weird enough inputs (I doubt that they are _that_ rare, though -- If they actually tested that by, say, going away on the voting day, they'd probably not be the only ones to do so, from the exact same considerations!)
Let me demonstrate the philosophical argument another way:
Say there are a bunch of foreign people from the same country on a bus.
I ask you to guess their answer to the question: "How are you?", I give you 3 options.
Then, I tell you that the answer to the question by the first guy was "Great, mate'", which is one of the 3 options.
Will you not raise the odds that the other foreigners from the same country also answer the same?
When the brain process is simple enough (almost identical environment, probably similar moods, and an identical question), it takes just a few people to find correlation between seemingly independent decisions.
Surely you are going to say the first person asked is not influencing the other persons who don't even know he was asked, to answer the same. Yet whatever it is that he chooses seemingly independently to answer, raises the odds of that same answer being answered from the others.
In much more complicated environments, such as elections, the correlation wouldn't be as strong, ofcourse, but it would still be there, especially with so many people involved.
If your brain process is truly unique and not correlated to any other brain process, then I agree - there is no point for you to vote.
"Its impossible to sum the goods and bads of an idea that wasn't tried out."
It is very well possible to decide on the sum of good and bad without trying. I guess that if I had had the plan to hand out atomic bombs to Palestinians, you would agree that the balance is negative. Or do you insist on a trial first?
My intuition agrees, but I don't find it completely impossible that giving the Palestinians a-bombs would have surprising effects, perhaps positive. Perhaps their threat of using it would change public opinion in Israel, which would then accelerate peace. Ofcourse I don't believe that, but I am just illustrating that counter-intuitive results are possible.
The soviets getting a-bombs un-intuitively prevented war, rather than cause it.
Global warming may lead to a cooling of Europe, due to a change of direction in the gulf stream.
And so on.
But even if we cannot predict the sum, we can try it, just once, on a small scale and if society doesn't shatter we could do it again on a somewhat larger scale etc.
With that I can agree! That sounds like a plan.
"Small scale" should probably translate to "few people" at first, and to a "limited time span" later, and only after being reasonably sure of the safety, it can become a system.
"How do you know that everything is out in the open? "
Please give trying the idea of comparing a proposal with the current situation another shot. How many of the ideas, facts provided etc. are in the open now? If you send a letter to a politician, you cannot even be sure it goes past his/her secretary. You may receive a response, with an argument that you may or may not be able to refute. If someone else could the likelihood that he would hear about it from you is next to zero.
That is a very bad example. You are proposing to change the system of elections, not the system of politician communications.
The voting is currently implemented with technology simple enough, that creating large-scale frauds in ways that average people serving as observ
Its simply the manifestation an evolutionary mechanism: the handicap principle.
Tell me one thing. Did your 100% test coverage only cover modules, nicely and cleanly separated and spoon fed under controlled conditions, or did you also test concurrency issues under various heavy processing and communication loads? All that on embedded hardware? Oh... I thought so. Not sure where I got personal, boy. Anyhow, our 100% test coverage covered, as I said, certain non-trivial modules.
I cannot expand too much on details here, but the tests covered real use conditions, and not a single implementation bug regarding these modules was reported from the customer at any later stage. Some bugs existed, but they were specification-level. Not every piece of code is a Windows GUI to access a database. Where I work, we are in a highly competitive safety related embedded market. Our customers are mainly military all over the world. In case our hardware or software makes a mistake, we can't pop up a window and say "sorry for the inconvenience". In the extreme cases, people's lives can be at stake. We are EXTREMELY cautious about how we write code, up to the point of being PARANOID, and believe me, if you knew who we are, you'd be glad we are like that. Good for you. Sounds like you should be working harder to get 100% coverage then
If you let code duplication remain,
If you let misleading variable names remain,
If you let tight coupling remain,
all because you fear modifying the code: you've already lost - simply because these attributes of the code will soon translate into bugs as soon as that code is touched, and you will eventually need to modify code.
These two approaches to handling high-reliability code tend to self-reinforce themselves:
I think you might be inside an environment that's dug itself up into the first category, and can no longer get out.
Where I worked, we had people with both mindsets, and while both were equally successful in the resulting reliability that they achieved, the latter group could handle more complicated requirements and obviously had much more dynamic code that could handle "moving target" requirements. The better quality, more readable and more reusable code was also a nice side effect of the latter approach.