I think you have that out of order. The most important comment is always why, followed by how. The what is expressed in the code itself, and if that's not clear, your code probably needs some refactoring.
NASA is very good at what it was intended to do. Unfortunately, that's not running a space launch business.
NASA was originally the National Advisory Committee for Aeronautics, with the purpose of "..to supervise and direct the scientific study of the problems of flight, with a view of their practical solution." (official history).
The main difference between the Moon program and the Shuttle program is that getting to the Moon was a development project - the creation of new technology - while the Shuttle program is basically running a business - doing the same thing over and over again. About 1/3 or NASA's budget goes to the shuttle, with little benefit.
Calls for NASA to "just do it" ignore the importance of the research and development. As an example, getting to Mars may cost only a fraction of what it would cost today, in about ten years time, as many of the propulsion technolgies reach maturity and can be developed into practical systems. But if those programs are abandoned to go to Mars now, then in ten years the cost will be little different. In other words, if NASA is allowed to do its job, the world may have the opportunity to get to Mars affordably, but if it's done now without adequate technology, only a few humans will ever set foot on the planet for a very long time (much like what happened with the Moon).
A comparison might be communicating across the U.S in the 19th century. One way to communicate quickly would be the Pony Express. Within a few years, the telegraph had been developed - technology produced a much more affordable solution. NASA is in a position of being the only ones developing certain types of technology, which means that directing resources away from that research will postpone its development, which would cripple space flight for the world.
You could argue that the rest of the world should spend more effort on this research themselves. It should. But since it doesn't, we're stuck with deciding how NASA can contribute most to humanity.
We currently have PLANS to invade Canada, we have for years, the Canadians have the same "Plans"
Since the U.S and Canadian militaries are so tightly integrated, how would this work? The second in command of NORAD is always a Canadian.
American General: Launch all bombers to target Ottawa!
Canadian General: Yes sir! (to American Colonel) Launch all bombers to target Washington!
American Colonel: Yes sir! (to Canadian Colonel) Launch all bombers to target Ottawa!
Canadian Colonel: Yes sir! Launch all bombers to target Washington!
Etc...
Ok, first of all--Europe is a post-modern society?? What the hell does that mean?!
The best translation of "post-modern" is "aware or its own context". Americans tend to be completely ignorant of the world around them, and because of this its politicians constantly bump into international opposition like a person stumbling around a dark room.
[...] the US didn't attack Afghanistan for any reason OTHER than the destruction of al-Qaeda.
Apparently, the war in Afghanistan was largely due to the desire for an oil pipeline to gain access to the Caspian Sea resources, and had been planned as far back as 1992:
This is why the U.S was able to go to war in Afghanistan within weeks - detailed war plans had already been finalized - while it took well over a year to get ready for war in Iraq.
Well, your "magic" is my "serious overhead that makes real-time programming esentially impossible".
There are ways to reduce the overhead, but first you should realise that garbage collection is not as expensive as it might seem, and it allows runtime optimisations that static allocate and free don't.
First, although it's not normally as efficient as explicit allocate and free, it is more efficient on average than something like reference counting. Even ignoring the fact that reference counting can allow mutually referenced objects to linger (ex. "a.next = b; b.next = a" will never reach a count of 0, and will never be freed), there is an overhead because every assignment to a pointer requires the compiler to insert extra reference counting code (or call a subroutine). That's a cost spread through the entire program.
Typically, a garbage collection system will traverse all live objects - and only the live ones. That means that it will take the same amount of time no matter how much garbage there is - only live objects are checked.
Most of the time only recently allocated objects are discarded, while older ones stick around a lot longer. The current Java system uses generational garbage collection, in that only recent objects are even looked at most of the time - objects that survive collection for several times are moved to a middle aged generation, and are looked at only incrementally (a fraction each cycle, not the complete group). The total number of live objects checked each time then becomes a very small number - in a long running program, probably less than 1% of the new objects, and maybe 0.1% of all objects.
Middle aged objects that survive enough incremental passes are moved to an old age generation - these are only checked rarely, when a decision needs to be made about expanding the heap.
The young generation garbage collection uses a copying method - this is important because it compacts the gaps between objects, defragmenting memory. A language like C or C++, which allocates using pointers, can't do this, otherwise the pointers will point to the wrong places. When there are gaps in memory (especially small ones), memory slows down because these gaps need to be checked each time, but are never large enough so the time is always wasted.
I wrote a program once which did a bunch of allocation and freeing for initialization, then a bunch of bigger allocations and frees for processing. After profiling it, it turned out that the program ran about 20% faster by just allocating the initialization objects, and leaving them there as garbage - they were too small to be allocated for the main program, so freeing them just created gaps which malloc() had to check each and every time. Good garbage collection eliminates this problem entirely as a side-effect.
In a Java program, you can give hints that it should do garbage collection at convenient times by calling the system/runtime garbage collection method gc() when it wouldn't be a problem. And there are products that give you better control over memory management (such as managing memory explicitly, as you would in C++).
In summary, garbage collection isn't nearly as expensive or scary as many people think, and can even improve performance significantly.
I notice a lot of people don't seem to understand what "design" necessarily means - as a result, it's often implemented as a crushing tome of details that are (in practice) taken from the final code that had to get written to meet a deadline, and translated to tables and diagrams to fulfill the "design requirement". In other words, it's not design, it's description after the fact.
Conversely, those who've seen that, or think of design that way, think that it's completely unnecessary and diving directly into coding, using a flexible method, is the way to go.
I think that good design is nothing more than what needs to be done anyway. You've always got to spend a few minutes thinking of what you're going to do before you hit the keyboard. A good design process should simply mean that you pause for a minute, write down those thoughts you're thinking anyway, and then continue. No more detailed than needed.
The most useful part of necessary design work is that it's higher level than code (obviously, otherwise you'd have just coded it), and lets you consider more of the system at a time. Often if you code something that's simple, and then coded something else, you'll find when you need to connect them that there's something you hadn't thought of, so you need to rework what you did ("refactoring" that's such a big XP thing). If you'd taken the time to describe what you intend to do (as if an email to someone), chances are you'll notice the problem when you get to writing that sentence. It saves time because you haven't done any work yet, and it's a lot easier to change a few sentences than rewrite working code.
If you get used to doing this, you can get comments for free - take the description, and paste it into your code editor. Take each step and break it down for more detail - at some point it's so detailed, any more detail would mean actual code. So wrap the description in comment markers, and write the code between them.
Obviously some things need more design effort than others. There's no use being dogmatic about it - a good design policy shouldn't add unnecessary work (if it's unnecessary, why the heck are you told to do it?). An added bonus, if you get good at doing this, you can farm the coding of parts off to junior programmers.
There are several things you can use a design for. First (and most important, I think) is implementation - as I said, the thinking process that has to happen anyway, and communication to others working on the program. If it's easier for you to see where parts of your own module don't fit, it's going to be a lot easier for two people to get an idea of how their modules will need to work together if they can describe it to each other before hand - everything from whiteboard notes to email, even if not a full design, is better than nothing.
Helping someone later to understand the program (for maintenance) is only secondary. This isn't a good thing to rely on, since the design usually gets a little out of date compared to the implementation, but it should be a useful guide for someone looking at the code. The important thing is, it can only be useful if it's not too detailed - the details are where the design becomes deceptive when it differs from reality.
If a design is to be used this way, it should be updated as easily as the code - possibly more, and at any point after the fact.
If people would be willing to fundamentally change the protocol used for email, there would be a pretty simple solution for Spam, and untracable email in general - sender-hosted email.
The fundamental problem is that email is sent to a receiving server immediately, which receives it without much in the way of caring where it comes from. The sender might be illegitimate, or even gone by the time the receiver checks the email. The receiver pays for the storage resources - this is receiver-hosted email.
The solution is a protocol that doesn't sent email - rather, only a header is sent, and the message itself is stored for retrieval on a host that the sender runs, or pays for. The header contains the reference to the waiting message which is retrieved when the receiver wants to read it (and marked as read so the sender can automatically delete it).
What this means for spam - the spammers pay for their own email servers - no free rides. The mail is absolutely tracable - it must be on the specified server to retrieve it. And if the spammer account goes away for abuse, so does the email - spammers can no longer shotgun a million messages from a sacrificial account.
Security issues would be more of a problem, but are fairly easily solvable.
Alas, I have no time to pursue this idea. Too bad, 'cause I'm on the verge of just giving up email entirely.
The US government has an effectively miniscule power to censor.
One example we find is that the US media is currently running story after story on how badly things are going in Iraq.
It may not be "censorship", but the U.S government has immense power to influence. At the simplest, they can simply blacklist uncooperative media from press conferences and official statements. This alone would be enough to cripple most major media which promise and depend on "timely reporting".
Another way is simply the U.S media's laziness. Investigation is nearly unheard of with rare exceptions - while "Sixty Minutes" still uncovers important stories, there are probably a hundred reporters for every news story these days, and news organizations don't have either the time ("timely reporting" again) or the money to do much else than simply print press releases with a few words switched around (the computer press at the height of the Windows-OS/2 war were at the forefront of this practice, only they reprinted Microsoft stories, not the government's).
The news media also gets entertainment value from cooperation. In this recent war in Iraq, the media took lessons from the American drug war - every few days or weeks, drug enforcement agents invite a reporter on a drug bust, resulting in spectacular ratings-boosting footage on the news. As a result, reporters cooperate with the government, completely failing to report the fact that drug use has skyrocketed at approximately the same astronomical rate as anti-drug funding, or the double reporting of drug busts to make efforts seem more effective, or the worst, the direct support given to drug providers by American organizations like the CIA and State Department (Micheal Levine, one of the top officers in the DEA until his retirement, details both media coverups and the support and protection of the drug industry by U.S foreign policy in his book The Big White Lie).
Finally, there seems to be a deep, deep American culture of simplicity. Many issues are just much too big and complicated for American's pretty little heads, and it would take much too much time and require much too much attention for the smart reporters to explain all the many important details to - damn, gas prices are up again!
This normally works very well for the government - the disappearance of inconvenient information is so complete that direct censorship is rarely needed (although recently more and more information has been classified, using the "war on terror" as an excuse).
Unfortunately when certain anti-government stories become popular among the population, it suddenly becomes more profitable for the press to oppose the government - only on particular issues though. The drug war remains profitable to support even if wild exaggerations of "Vietnam-like quagmire in Iraq" are bought up by the public. The government remains firmly in control where it counts.
As a side note, a large part of Quebec's power grid went down a few years ago due to an ice storm - literally, the weight of the ice on the power lines actually caused giant steel towers to topple, pulling each other down like dominoes.
The province took the opportunity to modernize its power system, so was unaffected this time. The power system is also publicly run, as it is in Ontario, but the Quebec government has been fairly socialist, compared to the more right-wing small-government party running Ontario, so was more willing to spend the necessary money to upgrade.
Where I work, they ship systems based on UnixWare, with custom software added in. I've asked my managers many times why the company is sticking with an outdated product (conforms to the Unix95 standard, not the Unix98 standard - how lazy are they that they can't even make Genuine Unix System V.something code "Unix compatible"?).
The answer is always "there are no plans to change". More specifically, there's no budget allocated to change.
I fear that a few months from now, we'll have a dozen very expensive boxes sitting by the door with no OS on them. And some upset customers making many upset phone calls.
I wonder what the budget will have to say about that.
The point is, I'm sure this isn't rare. It's the main reason for MS Windows being so dominant in the face of better alternatives (more so in the past). To change would mean to make an effort, and if you've stuck with UnixWare this long, you're not the type to ever make an effort to change.
I think, ideally, I would block the saving of any file on the hard drive unless it has certain extensions (.doc,.xls,.ppt if you use M$ Office), prevent running files from home, etc., that all can be done with the right software, I think Fortres Grand can do that.
Sounds like a pretty good way of shutting down all productive work in an office. You never know in advance what file formats are going to be saved. And more importantly, whether the extension really is correct, since it could be renamed with ease.
Where I work, the email server is set up to filter all "dangerous" attachments. Occasionally we need to email executables, and usually what happens is the attachment is simply removed, the recipient emails back complaining, and then the attachment is re-sent as a.zip file.
Not in a.zip file, you just rename testprog.exe to testprog.zip and email it. On the other end, they rename it back.
If filtering that stupid when it's just email, I can imagine how quickly things will grind to a halt if you did that for saving files.
BTW, they also don't equip individual PCs with CD-ROMS, apparently to prevent people from installing unauthorized software. It's so effective we have to walk all the way to the CD burner machine and put the CD in there, then go back to our own and run the installer over the network. It must add a whole minute to the time it takes to install unauthorized software - at least the kind that you don't just download from a web site (in a.zip file or similar so it's not blocked).
The relative merits of a mainly publically or mainly privately funded health care system can be debated, but one thing that any government should realize, regardless of it's political philosophy, is that whatever system it prefers, the one that exists must be fully supported even if it's counter to the party principles.
Damn, don't you hate it when people use the latest media topic to support their favorite political peeve? Note that I don't disagree (I happen to support public healthcare) but, really now...
I tried to keep it neutral. If the government preferred a privatized system, that's fine, as long as health care services don't fall through the cracks during the transition, and the new system is functional. Also politicians shouldn't be stupid, but are (stating the obvious).
But the main point I wanted to make was also one that you made:
the reason BC fared better than Ontario during the SARs crisis is they were simply better informed and reacted more efficiently. Why? Because they're the friggin' Canadian gate to the Pacific Rim! Knowing this, they keep a pretty sharp eye out on health reports coming out of the Asian continent.
Regionalism and defense of bureaucratic fifdoms are outdated concepts, and dangerous these days. BC is not the gateway to Asia, it's just a little closer - not enough to make a difference. All areas of the world are becoming vulnerable to the spread of diseases in the same way.
Basically, I'm advocating that responsibility for health care shouldn't be exclusively vested in one decision maker, because that becomes a single point of failure (see stupid politicians above), and it requires resources that may not be available at that level, while the results of inadequate resources can (and do) affect those who could (if they wanted to) do a lot towards redressing that resource shortfall.
Policy issues
on
SARS Contained
·
· Score: 4, Interesting
One thing mentioned in the article but glossed over is the fact that a SARS patient was in Vancouver about the same time as in Toronto, but the information on this newly identified disease wasn't passed down to Toronto workers as it was in Vancouver.
In Canada, as in the U.S, health care in general is a provincial responsibility (with parts delegated to the county or municipal level), with federal assistance. The government of Ontario is currently conservative, small-govermnent (i.e. pro-cutbacks) one for the past decade or so. One of the things that were cut back were the disease researchers whose job it was to identify new diseases, develop tests and diagnostic procedures for them, and distribute this information. A typical politician, the Health Car Minister justified this by asking "what, is a brand new disease going to magically appear?".
Conversely, the past decade in BC has been a big-government (i.e. pro-spending) one, until recently (when a large fraction of the public sector was amputated). However, it has a more fully funded health care system, and was able to quickly react to the news of a new disease.
With Ontario's "immune system" essentially crippled, it fell on other provinces (including BC, where the responsible corona virus DNA was first sequenced) and the federal government to pick up the slack.
The relative merits of a mainly publically or mainly privately funded health care system can be debated, but one thing that any government should realize, regardless of it's political philosophy, is that whatever system it prefers, the one that exists must be fully supported even if it's counter to the party principles.
Another lesson to be learned is that the world is becoming too mobile to leave health care as a purely local responsibility. In the case of Canada, Ontario might have been helpless except for the federal research facilities near Winnipeg, Manitoba, because of its health and safety negligence (the same negligence was responsible for water safety problems in Walkerton which led to a similar number of deaths). Without effective research, the outbreak could have spread country-wide.
National governments may not be accountable enough either. China's government was downright deceitful over the spread of SARS in that country, and without international pressure and some wistle-blowers risking their jobs, the disease could still be spreading there.
The fallout from these problems would not have been limited to single nations. If SARS had spread across Canada, the U.S would have had to choose between closing the border (which is the single largest flow of imports and exports for both countries), seriously crippling the U.S economy in the middle of trying to recover from a recession (maybe enough to make it a depression, and killing G.W.Bush's chances of re-election for good), or risking the spread into a wider population (and crippling the economy in another way).
The World Health Organization is important, but it is only an advisory body - it has no authority to influence policy or implement operational changes in health care delivery. As a result, government from countries (China and others) to local (Ontario and others) have become holes in a global system, purely due to their own short-sightedness. These holes threaten world health these days.
Further, there are entire regions where health care is inadequate simply because of economic poverty. Wealthy countries find it convenient to ignore the conditions in places like these, but it should be clear by now that those conditions can cost the wealthy countries billions or trillions of dollars of their own wealth due to the spread of diseases which are controllable. SARS (limited to countries with fairly well-developed health care systems) was a few pennies compared to the economic costs of AIDS (originating in countries with crumbling hospitals able to care for only a handful of their populations, most of whom never see a hospital in their entire lives).
I'm replying to this instead of the one above it because I think more people should read it, but I have no mod points.
In the article I want to respond to:
And the ~300,000 Iraqis Saddam's dictatorship murdered? No mass destruction there, no sir.
Many of those were starved by the sanctions (directly or indirectly), but that's beside the point. It's true the government killed a lot . Exactly how many is hard to say - less than the U.S did in Vietnam, but more than Russia did in Chechnya.
The intent is important. The society of the area is volatile and violent, and most of the area's leaders (who live in that environment) believe that it's basically a choice between using both the threat and application of cruelty against the people to control them, or allowing the people to kill each other (even escalating to civil warfare).
In other words, the Iraqi governmnet killed enough people to prevent an even greater loss of life if people weren't controlled.
I don't think that's true in absolute terms - but I never lived there. The only two true democracies in the region aren't really part of the Arabic culture - Turkey and Israel, and Turkey has a lot of trouble staying democratic. Factions have deep, almost irrational beliefs in their tribes/political factions/races/religions, and have certainly shown no reluctance to kill in response to a nasty look. It's entirely possible that such a society would degenerate into something like Somalia without an iron rule.
In Iraq, life was pretty good for anyone not opposed to Saddam Hussein - they had more religious and gender freedom than almost any other country in the region, and before the sanctions, consistantly decent medical care and even recently a top-notch education system. The price for this was political obedience, and a high price for the disobedient.
You'd think that the U.S government would have learned how hard it is to manage such an "act first (and violently), think later - if you absolutely have to" culture after the hidious mess in Lebanon. But American politicians aren't known for their ability to learn anything. The mess in Iraq has just started and seems to be getting worse - I wouldn't be surprised if within a few years, the death toll of American soldiers will be higher from the peace than the war.
One positive thing about the common hatred of Americans in Iraq, it might unite the different factions as long as they continue to occupy the country. They might hold off massacring each other until the shared American threat is driven out.
A that point we'll see if they can kill more of each other than the Iraqi government did.
This type of thing has been thought of before, such as Intentional Programming at Microsoft Research (now at intentsoft.com) or aspect programming at PARC
I don't know much about intentional programming, but how is aspect oriented programming related to this? At its most basic, AOP is mostly just a form of semantic-aware macros (though you can do it without the language support, much like you can to object oriented programming without language support).
One of the reasons Microsoft Windows is so dominant is because Microsoft provides more than just an OS kernel, or a few packages that do a few specific tasks. Microsoft provides a complete infrastructure from the OS kernel, to one of the most complete development environments in the world, database and management software, office software, including (and this is forgotten by many people who compare MS Office to other products) a set of technologies which are actually used to integrate the different components into a giant, interacting whole - you can embed Excel spreadsheets or Visio diagrams into a MS Word document, or make IIS read data from SQL Server fairly simply (with those complex, remarkeble development tools).
This is what Microsoft offers that nobody else provides. Not OS/2, not Macintosh (though the iApplications feature a similar sort of integration - Steve Jobs "gets it").
Microsoft didn't do this all at once, but Bill Gates did know Microsoft had to get there (and first, he felt). The company was able to afford to because they started with a monopoly in one area (MS-DOS), and used the profits to fund the development of failed products until they weren't failures any more. They grew one monopoly into a handful (Windows, Office), and are using those to fund more monopolies (SQL server, Xbox, whatever else).
Sun is doing the same thing. It's starting with Unix, which is a handicap because, as a commercial entity, it was being pulled by commercial interests who still had the "proprietary mindset" in which they wanted Unix to be a lowest common denominator, but wanted to keep the best improvements to themselves to compete with the other Unix providers. Much of Unix's advances were from non-commercial University or research lab development (TCP/IP, X windows), and the occasional corporate gift (NFS being the main). Common development tended to focus on extremely limited results (Motif, CDE) which really only gave the impression that Unix was incapable of being used for anything very good, desktop-wise.
Much of Sun's development has been aimed at filling in the vast gaps in things Unix can be used for. It funds this with hardware sales, much like Microsoft funded its development effort from previous monopolies (to be fair, some were legitimately acquired).
This is why Sun has invested and promoted such a wide range of software. They attempted to fill the GUI gap with NeWS, the networking gap with NFS, the portability gap with Java, the development and office gap by buying Forte and StarOffice, web servers with Netscape, and so on. Some have been successful, some haven't, but one thing has always been clear to Scott McNealy - a computer is useless unless you can do what you want with it. The stated goal of Sun is to provide a complete infrastructure for anything you want to do with computers - from cell phones to mainframes, you'll find Sun software.
That's Sun's strategy - be the next Microsoft, the same way that Microsoft did it (well, maybe more legally).
Of course, Sun doesn't have the resources to do it on its own, and Linux has been an indirect blessing - since Linux is so similar to Unix, and Sun has the most popular Unix, the vast growth of software created for Linux (as programmers create their own infrastructure independently of the choking control of Microsoft's non-technical influence) can be easily used by Sun to fill in more of its own gaps.
But Sun's strategy is clear, and the only other companies in a position to do the same thing are Microsoft (done already), and IBM (selling manpower to hook together existing products from itself and others). Everyone else seems to see hardware as just hardware - that's like selling an audio/video player that can't play existing CDs or DVDs because it has a vastly superior, but incompatible medium - shades of the Digital Alpha.
This is why Sun's outlook is so much better than people who only look at numbers and charts would ever dream of. Sun is investing in a very large, very significant future, while almost nobody else is. That investment has the potential to pay of massively, if they choose correctly, or recover from their incorrect choices quickly enough (Solaris vs. Linux - maybe, maybe not).
It's aimed at corporate desktops, not home users - places where companies want to have more control over what users install, but want a complete user-friendly software suite for normal office work. It's also aimed at places where users are likely to move around, and have a need to be able to access their own files on other machines (trying to do that with Windows NT is nearly impossible - while users can have a networked home directory, any applications they installed on their machine are unavailable if they log in elsewhere).
Sun has been working on this area for a long time with different technologies (Java Station, Sun Ray, low cost SPARC systems), but the main obstacle has been the software - Linux and Unix software is now approaching the same completeness as Windows and Macintosh software, so they might have better luck now. If employees can now do the same work with non-Windows computers (the primary advantage of Windows), the advantages of a better fundamental design and central administration will start to influence IT decision-making.
Multics didn't operate in today's environment, however. How would it have done if it was attached to the Internet?
Probably very well.
Here's an example of the kind of thinking that went into Multics - stacks went up from 0, not down from the high end of memory. That was so that the return address and important stack information was stored below any local buffers. If some poorly written application overwrote a local buffer, the excess data would flow harmlessly upward into unallocated memory land. It might screw up local variables, but it would not, ever, allow the return address to be overwritten, and could not, ever, be used to execute arbitrary code.
Solaris and other secure operating systems do things like non-executable stacks, which patch the problem, but don't solve it completely. I don't think Linux does even that.
There was a lot of OS know-how of the past that seems to have been lost like the mytical Atlantis.
The fundamental problem with Microsoft software, as far as bugs (and thus security) go is something that Steve Balmer bragged about, in comparing Windows to open source as far as innovation.
He pointed out that if Microsoft wants to add a feature, they have control of the whole code from kernel to Excel, and can make all the changed needed for that new feature directly, and quickly, where with open source (or suppliers who don't have a complete software solution), you need to get different project groups/companies together to agree on whether they want this feature, how to implement it, how the components should interact, and so on.
This, he says, is why Microsoft can "innovate" (add features, whether they're actually innovative or not) more quickly than open source software.
This is also the weakness, because when a bug appears, there is no easy way to tell where in the entire massive Microsoft code base the problem lies. The entire structure is so interrelated that, while you can add things easily, removing even a small thing may break things massively - so they don't, leading to bloat - and tracing things is like a needle in a haystack, and getting worse.
You can see the Microsoft way in the.NET vs. Java EE "pet shop" demonstration application. The Java version, created by Sun, was intended to be a "best practices" demonstration of modular, easily modifyable design, and wasn't intended to perform well. Microsoft's.NET version has often been called a living "anti-pattern" - an example of how not to create an enterprise application, although its faster.
By comparison, open source (and most smaller proprietary software systems) are small modules which interface to each other with simple, well-defined interfaces - largely because defining interfaces is so much trouble that nobody likes to do it, so they're only added with careful forethought and design to make them as general as reasonable, so you don't have to change it later or add another.
This means that generally, when there's a bug, it's well defined, easily tracable, and more importantly, its damage is limited. It is inherently more secure than an integrated, unstructured approach. It is also much slower to advance.
One of the reasons that customers in the software industry accept such hideous software as is available now is simply that it's a new industry - computers are still finding new uses, and at this point it's more important to get computers to do these new things at all, than to get them to do them well. Microsoft's success has been partly because it's development model is based on getting computers to do new things first, thus defining the market.
There is a limit to the new things that can be done with computers. Or at least, certain fields which have become well defined as far as what features are needed and useful. Office applications are an example - Microsoft has not been able to introduce a single genuinely useful feature to Word, Excel, or most of its other desktop software in a long time.
This will affect the entire computer industry. My guess is that we've figured out about a third of all the things computers are useful for. When that upper limit is finally approached, then competing software will all be able to catch up feature-wise, and all do basically the same thing. At that point, software quality will be the main way of differentiating products, and any company that's not able to switch development models away from feature-expansion to quality improvement will be in big trouble.
My guess is that will start to happen in about 40 years, but I may be wrong. There are some signs of it happening in some areas already (servers, for example).
Actually, large scale Japanese aerospace and military projects tend to go badly, as far a cost and schedule in particular. As an example, look at the H-2 rocket, which is both more expensive and less capable than similar U.S, European, Russian, or even Chinese rockets. Plus a longer development time.
Also check out their current indiginous fighter project - even given the basic F-16 design to copy, it's still not finished (it's not an exact copy, but it's taken longer than some of from-scratch designs).
Japanese companies are very good at using mature technology, and at making technology mature. They are fairly bad at using immature technology for end products. Rocket technology is still a long way from being mature.
Although a lot can be done with the technology that is mature. An example was the McDonnel Douglass Delta Clipper X, which was almost all off-the-shelf technology on a small budget. The rocket engines weren't reusable, but they were just driven at a much lower thrust, eliminating most of the wear allowing them to be reused anyway.
Sadly, after being sold to NASA, the DC-X fell victim to its budget - it was so cheap to operate, it was run mostly in a seat-of-the-pants fashion. During its last flight, a technician forgot to plug in the hydrolic hose to extend one landing gear (it had four), so when it landed, it simply toppled over.
Still, when NASA was looking for its last "replace the shuttle" program, it (or the larger Delta Clipper Y version) was one of three proposals - the other two were the Lockheed VentuStar, and a re-worked Space Shuttle. Although the two that lost were based on working technology, the main goal at NASA was for new technology development, not product development, so the riskiest project was funded (Lockheed's).
It didn't fail, in NASA's view - the innovative engines were developed, and aerodynamic studies performed. They just ran out of money and decided to stop it (the composite fuel tank technology was not completed). An end product wasn't really the goal for them - in the end of the program, Lockheed would have been responsible for building the actual vehicle, operating it, and marketing launch services - NASA would just be another customer. It was Lockheed's choice not to without the NASA funded prototype complete to show investors.
In my opinion, the DC-Y was the best choice - no new technology, just build the prototype and go. But it the program had succeeded, I would have been wrong, so blame doesn't work unless you know the future ahead of time.
Slashdot Mirror
Some grains of sand sre still on direct dialup.
I think you have that out of order. The most important comment is always why, followed by how. The what is expressed in the code itself, and if that's not clear, your code probably needs some refactoring.
NASA is very good at what it was intended to do. Unfortunately, that's not running a space launch business.
NASA was originally the National Advisory Committee for Aeronautics, with the purpose of "..to supervise and direct the scientific study of the problems of flight, with a view of their practical solution." (official history).
The main difference between the Moon program and the Shuttle program is that getting to the Moon was a development project - the creation of new technology - while the Shuttle program is basically running a business - doing the same thing over and over again. About 1/3 or NASA's budget goes to the shuttle, with little benefit.
Calls for NASA to "just do it" ignore the importance of the research and development. As an example, getting to Mars may cost only a fraction of what it would cost today, in about ten years time, as many of the propulsion technolgies reach maturity and can be developed into practical systems. But if those programs are abandoned to go to Mars now, then in ten years the cost will be little different. In other words, if NASA is allowed to do its job, the world may have the opportunity to get to Mars affordably, but if it's done now without adequate technology, only a few humans will ever set foot on the planet for a very long time (much like what happened with the Moon).
A comparison might be communicating across the U.S in the 19th century. One way to communicate quickly would be the Pony Express. Within a few years, the telegraph had been developed - technology produced a much more affordable solution. NASA is in a position of being the only ones developing certain types of technology, which means that directing resources away from that research will postpone its development, which would cripple space flight for the world.
You could argue that the rest of the world should spend more effort on this research themselves. It should. But since it doesn't, we're stuck with deciding how NASA can contribute most to humanity.
What's worse - now I hear that you can get the same make and model of car, in different colours!
What's with that?
We currently have PLANS to invade Canada, we have for years, the Canadians have the same "Plans"
Since the U.S and Canadian militaries are so tightly integrated, how would this work? The second in command of NORAD is always a Canadian.
American General: Launch all bombers to target Ottawa!
Canadian General: Yes sir! (to American Colonel) Launch all bombers to target Washington!
American Colonel: Yes sir! (to Canadian Colonel) Launch all bombers to target Ottawa!
Canadian Colonel: Yes sir! Launch all bombers to target Washington!
Etc...
Ok, first of all--Europe is a post-modern society?? What the hell does that mean?!
The best translation of "post-modern" is "aware or its own context". Americans tend to be completely ignorant of the world around them, and because of this its politicians constantly bump into international opposition like a person stumbling around a dark room.
[...] the US didn't attack Afghanistan for any reason OTHER than the destruction of al-Qaeda.
Apparently, the war in Afghanistan was largely due to the desire for an oil pipeline to gain access to the Caspian Sea resources, and had been planned as far back as 1992:
This is why the U.S was able to go to war in Afghanistan within weeks - detailed war plans had already been finalized - while it took well over a year to get ready for war in Iraq.First, although it's not normally as efficient as explicit allocate and free, it is more efficient on average than something like reference counting. Even ignoring the fact that reference counting can allow mutually referenced objects to linger (ex. "a.next = b; b.next = a" will never reach a count of 0, and will never be freed), there is an overhead because every assignment to a pointer requires the compiler to insert extra reference counting code (or call a subroutine). That's a cost spread through the entire program.
Typically, a garbage collection system will traverse all live objects - and only the live ones. That means that it will take the same amount of time no matter how much garbage there is - only live objects are checked.
Most of the time only recently allocated objects are discarded, while older ones stick around a lot longer. The current Java system uses generational garbage collection, in that only recent objects are even looked at most of the time - objects that survive collection for several times are moved to a middle aged generation, and are looked at only incrementally (a fraction each cycle, not the complete group). The total number of live objects checked each time then becomes a very small number - in a long running program, probably less than 1% of the new objects, and maybe 0.1% of all objects.
Middle aged objects that survive enough incremental passes are moved to an old age generation - these are only checked rarely, when a decision needs to be made about expanding the heap.
The young generation garbage collection uses a copying method - this is important because it compacts the gaps between objects, defragmenting memory. A language like C or C++, which allocates using pointers, can't do this, otherwise the pointers will point to the wrong places. When there are gaps in memory (especially small ones), memory slows down because these gaps need to be checked each time, but are never large enough so the time is always wasted.
I wrote a program once which did a bunch of allocation and freeing for initialization, then a bunch of bigger allocations and frees for processing. After profiling it, it turned out that the program ran about 20% faster by just allocating the initialization objects, and leaving them there as garbage - they were too small to be allocated for the main program, so freeing them just created gaps which malloc() had to check each and every time. Good garbage collection eliminates this problem entirely as a side-effect.
In a Java program, you can give hints that it should do garbage collection at convenient times by calling the system/runtime garbage collection method gc() when it wouldn't be a problem. And there are products that give you better control over memory management (such as managing memory explicitly, as you would in C++).
In summary, garbage collection isn't nearly as expensive or scary as many people think, and can even improve performance significantly.
Conversely, those who've seen that, or think of design that way, think that it's completely unnecessary and diving directly into coding, using a flexible method, is the way to go.
I think that good design is nothing more than what needs to be done anyway. You've always got to spend a few minutes thinking of what you're going to do before you hit the keyboard. A good design process should simply mean that you pause for a minute, write down those thoughts you're thinking anyway, and then continue. No more detailed than needed.
The most useful part of necessary design work is that it's higher level than code (obviously, otherwise you'd have just coded it), and lets you consider more of the system at a time. Often if you code something that's simple, and then coded something else, you'll find when you need to connect them that there's something you hadn't thought of, so you need to rework what you did ("refactoring" that's such a big XP thing). If you'd taken the time to describe what you intend to do (as if an email to someone), chances are you'll notice the problem when you get to writing that sentence. It saves time because you haven't done any work yet, and it's a lot easier to change a few sentences than rewrite working code.
If you get used to doing this, you can get comments for free - take the description, and paste it into your code editor. Take each step and break it down for more detail - at some point it's so detailed, any more detail would mean actual code. So wrap the description in comment markers, and write the code between them.
Obviously some things need more design effort than others. There's no use being dogmatic about it - a good design policy shouldn't add unnecessary work (if it's unnecessary, why the heck are you told to do it?). An added bonus, if you get good at doing this, you can farm the coding of parts off to junior programmers.
There are several things you can use a design for. First (and most important, I think) is implementation - as I said, the thinking process that has to happen anyway, and communication to others working on the program. If it's easier for you to see where parts of your own module don't fit, it's going to be a lot easier for two people to get an idea of how their modules will need to work together if they can describe it to each other before hand - everything from whiteboard notes to email, even if not a full design, is better than nothing.
Helping someone later to understand the program (for maintenance) is only secondary. This isn't a good thing to rely on, since the design usually gets a little out of date compared to the implementation, but it should be a useful guide for someone looking at the code. The important thing is, it can only be useful if it's not too detailed - the details are where the design becomes deceptive when it differs from reality.
If a design is to be used this way, it should be updated as easily as the code - possibly more, and at any point after the fact.
If people would be willing to fundamentally change the protocol used for email, there would be a pretty simple solution for Spam, and untracable email in general - sender-hosted email.
The fundamental problem is that email is sent to a receiving server immediately, which receives it without much in the way of caring where it comes from. The sender might be illegitimate, or even gone by the time the receiver checks the email. The receiver pays for the storage resources - this is receiver-hosted email.
The solution is a protocol that doesn't sent email - rather, only a header is sent, and the message itself is stored for retrieval on a host that the sender runs, or pays for. The header contains the reference to the waiting message which is retrieved when the receiver wants to read it (and marked as read so the sender can automatically delete it).
What this means for spam - the spammers pay for their own email servers - no free rides. The mail is absolutely tracable - it must be on the specified server to retrieve it. And if the spammer account goes away for abuse, so does the email - spammers can no longer shotgun a million messages from a sacrificial account.
Security issues would be more of a problem, but are fairly easily solvable.
Alas, I have no time to pursue this idea. Too bad, 'cause I'm on the verge of just giving up email entirely.
Another way is simply the U.S media's laziness. Investigation is nearly unheard of with rare exceptions - while "Sixty Minutes" still uncovers important stories, there are probably a hundred reporters for every news story these days, and news organizations don't have either the time ("timely reporting" again) or the money to do much else than simply print press releases with a few words switched around (the computer press at the height of the Windows-OS/2 war were at the forefront of this practice, only they reprinted Microsoft stories, not the government's).
The news media also gets entertainment value from cooperation. In this recent war in Iraq, the media took lessons from the American drug war - every few days or weeks, drug enforcement agents invite a reporter on a drug bust, resulting in spectacular ratings-boosting footage on the news. As a result, reporters cooperate with the government, completely failing to report the fact that drug use has skyrocketed at approximately the same astronomical rate as anti-drug funding, or the double reporting of drug busts to make efforts seem more effective, or the worst, the direct support given to drug providers by American organizations like the CIA and State Department (Micheal Levine, one of the top officers in the DEA until his retirement, details both media coverups and the support and protection of the drug industry by U.S foreign policy in his book The Big White Lie).
Finally, there seems to be a deep, deep American culture of simplicity. Many issues are just much too big and complicated for American's pretty little heads, and it would take much too much time and require much too much attention for the smart reporters to explain all the many important details to - damn, gas prices are up again!
This normally works very well for the government - the disappearance of inconvenient information is so complete that direct censorship is rarely needed (although recently more and more information has been classified, using the "war on terror" as an excuse).
Unfortunately when certain anti-government stories become popular among the population, it suddenly becomes more profitable for the press to oppose the government - only on particular issues though. The drug war remains profitable to support even if wild exaggerations of "Vietnam-like quagmire in Iraq" are bought up by the public. The government remains firmly in control where it counts.
The province took the opportunity to modernize its power system, so was unaffected this time. The power system is also publicly run, as it is in Ontario, but the Quebec government has been fairly socialist, compared to the more right-wing small-government party running Ontario, so was more willing to spend the necessary money to upgrade.
Where I work, they ship systems based on UnixWare, with custom software added in. I've asked my managers many times why the company is sticking with an outdated product (conforms to the Unix95 standard, not the Unix98 standard - how lazy are they that they can't even make Genuine Unix System V.something code "Unix compatible"?).
The answer is always "there are no plans to change". More specifically, there's no budget allocated to change.
I fear that a few months from now, we'll have a dozen very expensive boxes sitting by the door with no OS on them. And some upset customers making many upset phone calls.
I wonder what the budget will have to say about that.
The point is, I'm sure this isn't rare. It's the main reason for MS Windows being so dominant in the face of better alternatives (more so in the past). To change would mean to make an effort, and if you've stuck with UnixWare this long, you're not the type to ever make an effort to change.
Where I work, the email server is set up to filter all "dangerous" attachments. Occasionally we need to email executables, and usually what happens is the attachment is simply removed, the recipient emails back complaining, and then the attachment is re-sent as a .zip file.
Not in a .zip file, you just rename testprog.exe to testprog.zip and email it. On the other end, they rename it back.
If filtering that stupid when it's just email, I can imagine how quickly things will grind to a halt if you did that for saving files.
BTW, they also don't equip individual PCs with CD-ROMS, apparently to prevent people from installing unauthorized software. It's so effective we have to walk all the way to the CD burner machine and put the CD in there, then go back to our own and run the installer over the network. It must add a whole minute to the time it takes to install unauthorized software - at least the kind that you don't just download from a web site (in a .zip file or similar so it's not blocked).
But the main point I wanted to make was also one that you made:
Regionalism and defense of bureaucratic fifdoms are outdated concepts, and dangerous these days. BC is not the gateway to Asia, it's just a little closer - not enough to make a difference. All areas of the world are becoming vulnerable to the spread of diseases in the same way.Basically, I'm advocating that responsibility for health care shouldn't be exclusively vested in one decision maker, because that becomes a single point of failure (see stupid politicians above), and it requires resources that may not be available at that level, while the results of inadequate resources can (and do) affect those who could (if they wanted to) do a lot towards redressing that resource shortfall.
In Canada, as in the U.S, health care in general is a provincial responsibility (with parts delegated to the county or municipal level), with federal assistance. The government of Ontario is currently conservative, small-govermnent (i.e. pro-cutbacks) one for the past decade or so. One of the things that were cut back were the disease researchers whose job it was to identify new diseases, develop tests and diagnostic procedures for them, and distribute this information. A typical politician, the Health Car Minister justified this by asking "what, is a brand new disease going to magically appear?".
Conversely, the past decade in BC has been a big-government (i.e. pro-spending) one, until recently (when a large fraction of the public sector was amputated). However, it has a more fully funded health care system, and was able to quickly react to the news of a new disease.
With Ontario's "immune system" essentially crippled, it fell on other provinces (including BC, where the responsible corona virus DNA was first sequenced) and the federal government to pick up the slack.
The relative merits of a mainly publically or mainly privately funded health care system can be debated, but one thing that any government should realize, regardless of it's political philosophy, is that whatever system it prefers, the one that exists must be fully supported even if it's counter to the party principles.
Another lesson to be learned is that the world is becoming too mobile to leave health care as a purely local responsibility. In the case of Canada, Ontario might have been helpless except for the federal research facilities near Winnipeg, Manitoba, because of its health and safety negligence (the same negligence was responsible for water safety problems in Walkerton which led to a similar number of deaths). Without effective research, the outbreak could have spread country-wide.
National governments may not be accountable enough either. China's government was downright deceitful over the spread of SARS in that country, and without international pressure and some wistle-blowers risking their jobs, the disease could still be spreading there.
The fallout from these problems would not have been limited to single nations. If SARS had spread across Canada, the U.S would have had to choose between closing the border (which is the single largest flow of imports and exports for both countries), seriously crippling the U.S economy in the middle of trying to recover from a recession (maybe enough to make it a depression, and killing G.W.Bush's chances of re-election for good), or risking the spread into a wider population (and crippling the economy in another way).
The World Health Organization is important, but it is only an advisory body - it has no authority to influence policy or implement operational changes in health care delivery. As a result, government from countries (China and others) to local (Ontario and others) have become holes in a global system, purely due to their own short-sightedness. These holes threaten world health these days.
Further, there are entire regions where health care is inadequate simply because of economic poverty. Wealthy countries find it convenient to ignore the conditions in places like these, but it should be clear by now that those conditions can cost the wealthy countries billions or trillions of dollars of their own wealth due to the spread of diseases which are controllable. SARS (limited to countries with fairly well-developed health care systems) was a few pennies compared to the economic costs of AIDS (originating in countries with crumbling hospitals able to care for only a handful of their populations, most of whom never see a hospital in their entire lives).
Obviously, it's in everyo
Here's another:
If he announced that the sky was blue, that would be enough of a reason for me to head to the nearest window to see what colour it had changed to...In the article I want to respond to:
Many of those were starved by the sanctions (directly or indirectly), but that's beside the point. It's true the government killed a lot . Exactly how many is hard to say - less than the U.S did in Vietnam, but more than Russia did in Chechnya.The intent is important. The society of the area is volatile and violent, and most of the area's leaders (who live in that environment) believe that it's basically a choice between using both the threat and application of cruelty against the people to control them, or allowing the people to kill each other (even escalating to civil warfare).
In other words, the Iraqi governmnet killed enough people to prevent an even greater loss of life if people weren't controlled.
I don't think that's true in absolute terms - but I never lived there. The only two true democracies in the region aren't really part of the Arabic culture - Turkey and Israel, and Turkey has a lot of trouble staying democratic. Factions have deep, almost irrational beliefs in their tribes/political factions/races/religions, and have certainly shown no reluctance to kill in response to a nasty look. It's entirely possible that such a society would degenerate into something like Somalia without an iron rule.
In Iraq, life was pretty good for anyone not opposed to Saddam Hussein - they had more religious and gender freedom than almost any other country in the region, and before the sanctions, consistantly decent medical care and even recently a top-notch education system. The price for this was political obedience, and a high price for the disobedient.
You'd think that the U.S government would have learned how hard it is to manage such an "act first (and violently), think later - if you absolutely have to" culture after the hidious mess in Lebanon. But American politicians aren't known for their ability to learn anything. The mess in Iraq has just started and seems to be getting worse - I wouldn't be surprised if within a few years, the death toll of American soldiers will be higher from the peace than the war.
One positive thing about the common hatred of Americans in Iraq, it might unite the different factions as long as they continue to occupy the country. They might hold off massacring each other until the shared American threat is driven out.
A that point we'll see if they can kill more of each other than the Iraqi government did.
This is what Microsoft offers that nobody else provides. Not OS/2, not Macintosh (though the iApplications feature a similar sort of integration - Steve Jobs "gets it").
Microsoft didn't do this all at once, but Bill Gates did know Microsoft had to get there (and first, he felt). The company was able to afford to because they started with a monopoly in one area (MS-DOS), and used the profits to fund the development of failed products until they weren't failures any more. They grew one monopoly into a handful (Windows, Office), and are using those to fund more monopolies (SQL server, Xbox, whatever else).
Sun is doing the same thing. It's starting with Unix, which is a handicap because, as a commercial entity, it was being pulled by commercial interests who still had the "proprietary mindset" in which they wanted Unix to be a lowest common denominator, but wanted to keep the best improvements to themselves to compete with the other Unix providers. Much of Unix's advances were from non-commercial University or research lab development (TCP/IP, X windows), and the occasional corporate gift (NFS being the main). Common development tended to focus on extremely limited results (Motif, CDE) which really only gave the impression that Unix was incapable of being used for anything very good, desktop-wise.
Much of Sun's development has been aimed at filling in the vast gaps in things Unix can be used for. It funds this with hardware sales, much like Microsoft funded its development effort from previous monopolies (to be fair, some were legitimately acquired).
This is why Sun has invested and promoted such a wide range of software. They attempted to fill the GUI gap with NeWS, the networking gap with NFS, the portability gap with Java, the development and office gap by buying Forte and StarOffice, web servers with Netscape, and so on. Some have been successful, some haven't, but one thing has always been clear to Scott McNealy - a computer is useless unless you can do what you want with it. The stated goal of Sun is to provide a complete infrastructure for anything you want to do with computers - from cell phones to mainframes, you'll find Sun software.
That's Sun's strategy - be the next Microsoft, the same way that Microsoft did it (well, maybe more legally).
Of course, Sun doesn't have the resources to do it on its own, and Linux has been an indirect blessing - since Linux is so similar to Unix, and Sun has the most popular Unix, the vast growth of software created for Linux (as programmers create their own infrastructure independently of the choking control of Microsoft's non-technical influence) can be easily used by Sun to fill in more of its own gaps.
But Sun's strategy is clear, and the only other companies in a position to do the same thing are Microsoft (done already), and IBM (selling manpower to hook together existing products from itself and others). Everyone else seems to see hardware as just hardware - that's like selling an audio/video player that can't play existing CDs or DVDs because it has a vastly superior, but incompatible medium - shades of the Digital Alpha.
This is why Sun's outlook is so much better than people who only look at numbers and charts would ever dream of. Sun is investing in a very large, very significant future, while almost nobody else is. That investment has the potential to pay of massively, if they choose correctly, or recover from their incorrect choices quickly enough (Solaris vs. Linux - maybe, maybe not).
http://www.eweek.com/article2/0,3959,541297,00.asp
It's aimed at corporate desktops, not home users - places where companies want to have more control over what users install, but want a complete user-friendly software suite for normal office work. It's also aimed at places where users are likely to move around, and have a need to be able to access their own files on other machines (trying to do that with Windows NT is nearly impossible - while users can have a networked home directory, any applications they installed on their machine are unavailable if they log in elsewhere).
Sun has been working on this area for a long time with different technologies (Java Station, Sun Ray, low cost SPARC systems), but the main obstacle has been the software - Linux and Unix software is now approaching the same completeness as Windows and Macintosh software, so they might have better luck now. If employees can now do the same work with non-Windows computers (the primary advantage of Windows), the advantages of a better fundamental design and central administration will start to influence IT decision-making.
Probably very well.
Here's an example of the kind of thinking that went into Multics - stacks went up from 0, not down from the high end of memory. That was so that the return address and important stack information was stored below any local buffers. If some poorly written application overwrote a local buffer, the excess data would flow harmlessly upward into unallocated memory land. It might screw up local variables, but it would not, ever, allow the return address to be overwritten, and could not, ever, be used to execute arbitrary code.
Solaris and other secure operating systems do things like non-executable stacks, which patch the problem, but don't solve it completely. I don't think Linux does even that.
There was a lot of OS know-how of the past that seems to have been lost like the mytical Atlantis.
He pointed out that if Microsoft wants to add a feature, they have control of the whole code from kernel to Excel, and can make all the changed needed for that new feature directly, and quickly, where with open source (or suppliers who don't have a complete software solution), you need to get different project groups/companies together to agree on whether they want this feature, how to implement it, how the components should interact, and so on.
This, he says, is why Microsoft can "innovate" (add features, whether they're actually innovative or not) more quickly than open source software.
This is also the weakness, because when a bug appears, there is no easy way to tell where in the entire massive Microsoft code base the problem lies. The entire structure is so interrelated that, while you can add things easily, removing even a small thing may break things massively - so they don't, leading to bloat - and tracing things is like a needle in a haystack, and getting worse.
You can see the Microsoft way in the .NET vs. Java EE "pet shop" demonstration application. The Java version, created by Sun, was intended to be a "best practices" demonstration of modular, easily modifyable design, and wasn't intended to perform well. Microsoft's .NET version has often been called a living "anti-pattern" - an example of how not to create an enterprise application, although its faster.
By comparison, open source (and most smaller proprietary software systems) are small modules which interface to each other with simple, well-defined interfaces - largely because defining interfaces is so much trouble that nobody likes to do it, so they're only added with careful forethought and design to make them as general as reasonable, so you don't have to change it later or add another.
This means that generally, when there's a bug, it's well defined, easily tracable, and more importantly, its damage is limited. It is inherently more secure than an integrated, unstructured approach. It is also much slower to advance.
One of the reasons that customers in the software industry accept such hideous software as is available now is simply that it's a new industry - computers are still finding new uses, and at this point it's more important to get computers to do these new things at all, than to get them to do them well. Microsoft's success has been partly because it's development model is based on getting computers to do new things first, thus defining the market.
There is a limit to the new things that can be done with computers. Or at least, certain fields which have become well defined as far as what features are needed and useful. Office applications are an example - Microsoft has not been able to introduce a single genuinely useful feature to Word, Excel, or most of its other desktop software in a long time.
This will affect the entire computer industry. My guess is that we've figured out about a third of all the things computers are useful for. When that upper limit is finally approached, then competing software will all be able to catch up feature-wise, and all do basically the same thing. At that point, software quality will be the main way of differentiating products, and any company that's not able to switch development models away from feature-expansion to quality improvement will be in big trouble.
My guess is that will start to happen in about 40 years, but I may be wrong. There are some signs of it happening in some areas already (servers, for example).
Also check out their current indiginous fighter project - even given the basic F-16 design to copy, it's still not finished (it's not an exact copy, but it's taken longer than some of from-scratch designs).
Japanese companies are very good at using mature technology, and at making technology mature. They are fairly bad at using immature technology for end products. Rocket technology is still a long way from being mature.
Although a lot can be done with the technology that is mature. An example was the McDonnel Douglass Delta Clipper X, which was almost all off-the-shelf technology on a small budget. The rocket engines weren't reusable, but they were just driven at a much lower thrust, eliminating most of the wear allowing them to be reused anyway.
Sadly, after being sold to NASA, the DC-X fell victim to its budget - it was so cheap to operate, it was run mostly in a seat-of-the-pants fashion. During its last flight, a technician forgot to plug in the hydrolic hose to extend one landing gear (it had four), so when it landed, it simply toppled over.
Still, when NASA was looking for its last "replace the shuttle" program, it (or the larger Delta Clipper Y version) was one of three proposals - the other two were the Lockheed VentuStar, and a re-worked Space Shuttle. Although the two that lost were based on working technology, the main goal at NASA was for new technology development, not product development, so the riskiest project was funded (Lockheed's).
It didn't fail, in NASA's view - the innovative engines were developed, and aerodynamic studies performed. They just ran out of money and decided to stop it (the composite fuel tank technology was not completed). An end product wasn't really the goal for them - in the end of the program, Lockheed would have been responsible for building the actual vehicle, operating it, and marketing launch services - NASA would just be another customer. It was Lockheed's choice not to without the NASA funded prototype complete to show investors.
In my opinion, the DC-Y was the best choice - no new technology, just build the prototype and go. But it the program had succeeded, I would have been wrong, so blame doesn't work unless you know the future ahead of time.