This is just another euphemism for Communism. ("From each according to his ability, to each according to his need" - Karl Marx).
The first fatal flaw is it effectively wipes out the incentive to succeed; since someone can be handed a living with zero risk and near zero effort. The success of capitalist nations is because people are willing to risk their savings and comfort and to work much harder if success returns them material comfort. 95% of all small businesses fail even in the best of time. So this approach says that if someone risks everything and loses, the loss is their own. But if they are part of the 5% that succeeds, the government will seize most of what they made and re-distribute it to people that risked nothing.
That failed in the old Soviet Union, it failed in China (who have now introduced capitalism just to create enough GDP to feed their citizens, it failed in Cuba, in failed in North Korea, etc. The British tried 95% top tax rates to give away more free handouts and too many of their biggest and most successful risk-takers took their show to other countries.
If you want to lift the country; you need to provide incentives to increase the percentage of people willing to risk their own money and work hard to succeed; not guarantee the comfort of those who aren't motivated.
The second fatal flaw is that it puts the government in charge of deciding who gets virtually all wealth created by effort. And in such countries, the main beneficiaries are government officials and their accomplices.
There were lots of replies on this subject that talk about keeping backups with friends. That will work in simple cases of data corruption, but it pretty much useless in case of disaster.
Just ask the folks along a hundred-mile, continuous stretch of tornado destruction of whole communities in Alabama last year. Or anywhere along hundreds of square miles near the U.S. Gulf Coast when Katrina hit. Or in North Carolina where many different hurricanes hit. Or in California when - not if - the next big earthquake hits. Or in Japan or anywhere near Thailand when their respective tsunamis hit. Etc.
If your friend's house is anywhere nearby yours, any disaster that wipes out your house may well also wipe out his. Then, where are you?
I strongly vote for instead keeping your backups in a safe-deposit box and in the form of multiple (at least two) fully redundant, slower but cheaper, USB hard drive backups. Modern bank vaults will survive tornadoes, hurricanes, floods, etc . I keep my backup drives in a bank box less than 3 minutes from the house and rotate them on a regular basis. The box costs only around $75 a year.
It's also not subject to any black-hat (employee or outsider) gaining access to an online service.
CODASYL Hierarchical Databases are faster
on
The NoSQL Ecosystem
·
· Score: 1
CODASYL Hierarchical Databases are faster for large complex databases. I've supported extremely large databases and user bases with 3 second or better end-to-end response times for over 300,000 real-time customer service rep users with such software. These databases allow precise physical positioning; including the ability to group related child record rows on the same physical page. One I/O can retrieve the entire set. They also support hash or other custom indexing that directly yields the physical page address instead of wading thru relational index pages to get there.
Tool support is not as good and it takes someone who understands them to get the best results. Functionality such as producing report output is more work. But they work great on large datasets.
So the CEO and Executive Board that managed to cripple their Development Tools group (Delphi, CBuilder, JBuilder, etc.) by letting it publicly twist in the wind as trade bait finally bites the dust. They trashed their company's legacy to bet their ALM offerings could directly compete with the Rationals of the world.
Goodbye and good riddance.
It's hard to imagine a greater example of tech hubris than Borland's board. By casting doubt on Delphi's future, they managed to slash the market share of a tool used by over a million developers to the point that only a fraction of the remaining control library vendors and other ecosystem remain.
Even many of the strongest, best known Delphi experts have had to largely move to.Net to keep working.
Amazing that just a few clueless men could very nearly destroy one of the strongest development tool engineering groups ever assembled.
ADA is perfect for this type of system
on
The Return of Ada
·
· Score: 1
ADA failed in use as a general purpose language only because it was never intended to be one. It was designed for the US Military as a language for aircraft autopilots. Until ADA, every new aircraft autopilot's chipset was programmed with its own proprietary assembler and compiler. There were nasty crashes because each new aircraft essentially was running version 1.0 of the autopilot.
ADA was designed from the ground-up to be for "man-rated" systems - systems where lives were on the line if the system failed. With ADA, each new autopilot's bidder merely had to provide ADA for the chipset and existing, proven autopilot code could be re-used. ADA is outstanding for that purpose and saved the military a ton of money and issues. ADA is designed such that it can handle and restart after virtually any kind of failure. And it is designed such that, if a program compiles, it will almost never fail. It may not do what you want it to, but it will almost never outright crash.
Unfortunately, the US Congress saw the success ADA had and decided that all new US code should use the same approach. But ADA is a poor language for general usage for several reasons. One is that wants to be the ultimate supervisor rather than subject to another supervisor. Another problem is that there are absolutely no standard bindings or API's for business processes like reporting, databases, sorting, etc. And a third problem is that it takes far longer to program since constructs that save time to program but might be done incorrectly do not even exist in the language.
But an air traffic control system doesn't need business API bindings, doesn't have to be just one more sub-program in a general purpose OS environment, and can endanger thousands of lives if it fails. That is a near perfect match for ADA.
I have written ADA for military projects and have professional code running in 13 other computer languages over the last 30 years, so I feel qualified to comment on this. People who compare it to dissimilar languages like C, C++, T-SQL (give me a break), either do not know ADA or never really understood it.
It really is the right language for a man-rated system.
Slashdot Mirror
This is just another euphemism for Communism. ("From each according to his ability, to each according to his need" - Karl Marx). The first fatal flaw is it effectively wipes out the incentive to succeed; since someone can be handed a living with zero risk and near zero effort. The success of capitalist nations is because people are willing to risk their savings and comfort and to work much harder if success returns them material comfort. 95% of all small businesses fail even in the best of time. So this approach says that if someone risks everything and loses, the loss is their own. But if they are part of the 5% that succeeds, the government will seize most of what they made and re-distribute it to people that risked nothing. That failed in the old Soviet Union, it failed in China (who have now introduced capitalism just to create enough GDP to feed their citizens, it failed in Cuba, in failed in North Korea, etc. The British tried 95% top tax rates to give away more free handouts and too many of their biggest and most successful risk-takers took their show to other countries. If you want to lift the country; you need to provide incentives to increase the percentage of people willing to risk their own money and work hard to succeed; not guarantee the comfort of those who aren't motivated. The second fatal flaw is that it puts the government in charge of deciding who gets virtually all wealth created by effort. And in such countries, the main beneficiaries are government officials and their accomplices.
There were lots of replies on this subject that talk about keeping backups with friends. That will work in simple cases of data corruption, but it pretty much useless in case of disaster. Just ask the folks along a hundred-mile, continuous stretch of tornado destruction of whole communities in Alabama last year. Or anywhere along hundreds of square miles near the U.S. Gulf Coast when Katrina hit. Or in North Carolina where many different hurricanes hit. Or in California when - not if - the next big earthquake hits. Or in Japan or anywhere near Thailand when their respective tsunamis hit. Etc. If your friend's house is anywhere nearby yours, any disaster that wipes out your house may well also wipe out his. Then, where are you? I strongly vote for instead keeping your backups in a safe-deposit box and in the form of multiple (at least two) fully redundant, slower but cheaper, USB hard drive backups. Modern bank vaults will survive tornadoes, hurricanes, floods, etc . I keep my backup drives in a bank box less than 3 minutes from the house and rotate them on a regular basis. The box costs only around $75 a year. It's also not subject to any black-hat (employee or outsider) gaining access to an online service.
CODASYL Hierarchical Databases are faster for large complex databases. I've supported extremely large databases and user bases with 3 second or better end-to-end response times for over 300,000 real-time customer service rep users with such software. These databases allow precise physical positioning; including the ability to group related child record rows on the same physical page. One I/O can retrieve the entire set. They also support hash or other custom indexing that directly yields the physical page address instead of wading thru relational index pages to get there. Tool support is not as good and it takes someone who understands them to get the best results. Functionality such as producing report output is more work. But they work great on large datasets.
So the CEO and Executive Board that managed to cripple their Development Tools group (Delphi, CBuilder, JBuilder, etc.) by letting it publicly twist in the wind as trade bait finally bites the dust. They trashed their company's legacy to bet their ALM offerings could directly compete with the Rationals of the world. Goodbye and good riddance. It's hard to imagine a greater example of tech hubris than Borland's board. By casting doubt on Delphi's future, they managed to slash the market share of a tool used by over a million developers to the point that only a fraction of the remaining control library vendors and other ecosystem remain. Even many of the strongest, best known Delphi experts have had to largely move to .Net to keep working.
Amazing that just a few clueless men could very nearly destroy one of the strongest development tool engineering groups ever assembled.
ADA failed in use as a general purpose language only because it was never intended to be one. It was designed for the US Military as a language for aircraft autopilots. Until ADA, every new aircraft autopilot's chipset was programmed with its own proprietary assembler and compiler. There were nasty crashes because each new aircraft essentially was running version 1.0 of the autopilot. ADA was designed from the ground-up to be for "man-rated" systems - systems where lives were on the line if the system failed. With ADA, each new autopilot's bidder merely had to provide ADA for the chipset and existing, proven autopilot code could be re-used. ADA is outstanding for that purpose and saved the military a ton of money and issues. ADA is designed such that it can handle and restart after virtually any kind of failure. And it is designed such that, if a program compiles, it will almost never fail. It may not do what you want it to, but it will almost never outright crash. Unfortunately, the US Congress saw the success ADA had and decided that all new US code should use the same approach. But ADA is a poor language for general usage for several reasons. One is that wants to be the ultimate supervisor rather than subject to another supervisor. Another problem is that there are absolutely no standard bindings or API's for business processes like reporting, databases, sorting, etc. And a third problem is that it takes far longer to program since constructs that save time to program but might be done incorrectly do not even exist in the language. But an air traffic control system doesn't need business API bindings, doesn't have to be just one more sub-program in a general purpose OS environment, and can endanger thousands of lives if it fails. That is a near perfect match for ADA. I have written ADA for military projects and have professional code running in 13 other computer languages over the last 30 years, so I feel qualified to comment on this. People who compare it to dissimilar languages like C, C++, T-SQL (give me a break), either do not know ADA or never really understood it. It really is the right language for a man-rated system.