I'd say that the reason C eclipsed Pascal was the popularity of Unix. There was an explosion of Unix systems in the mid 80's (including Sun workstations but many, many others) that were fairly inexpensive but with a lot of power and they were all programmed in C. Pascal had a lot of popularity on PC's with Turbo Pascal and a lot of stuff written of the Macintosh was Pascal back then (if you look at the old Mac API's you'll see an abundance of "pstrings" or Pascal strings) but C was "cooler" because it was coming out of the Unix world.

This is very true. Another issue is not that there's anything embarrassing or bad, but the sheer work of producing documents for a lawsuit can be be very expensive. If you do keep emails or other records beyond the legal retention limits they can still be subpoenaed, but if you destroy them on a regular schedule, well, can't produce what you don't have.

Developed countries don't need to promote population control - it happens by itself. Every developed nation except for the United States (which has large amounts of immigration) has a declining birth rate. And, yes, it is a problem for retirement schemes.

As far as I can tell the "washing" of the granules is part of the automatic cycle.

How do you think /dev/null is implemented?

Real didn't remove the Apple DRM, though, they added it. That's not DRM circumvention. Real had the rights to distribute the music. If there was some legal issue with creating the FairPlay (gotta love them names) compatible files, Apple would have sued Real rather than just adding code to reject their files.

I think there may be some merit to this.

First, it makes the tax structure for companies a lot simpler. The amount of paperwork for tracking all of your expenses is silly (I _hate_ saving and tracking receipts) and you don't know how much your tax will be until you know how much your profit is. If it's a percentage of revenues you can just figure it in to your costs and be done.

Second, the tax on income penalized businesses saving. So, if you need to make a big investment that you can't finance out of revenues in a single tax year it makes more sense to borrow for it than it does to save profits for a few years. When times are good, borrowing is fairly easy. However, as soon as a recession hits, banks start to trim credit lines and refuse to make new loans. This decreases investment and makes the recession worse. If more businesses were financing themselves out saved profits the business cycle would probably not be as much of a boom/bust as it.

The difference is that for a corporation almost everything is a business expense whereas for an individual you can't deduct things like food, clothing and other things not directly related to the business.

I remember hearing that back in the mid-80's. May I introduce you to bubble memory?

Hmmm...here in Tokyo a lot of the power is coming in through overhead lines. Our building gets fed off a pole and we haven't had an outage in years. That includes during the multiple typhoons that come through every year. They tend to insulate the wires and wrap them with steel cable here, though, so maybe that's a big difference.

Skynet begins to learn at a geometric rate. At 1:35 A.M. Eastern time it runs out of disk space and crashes horribly

Most of the answers to your questions are "it depends" I don't understand what you mean by a "software shop" - is this a consulting company, a company that produces a large scale product, a company that produces a small product, an online service or what?

Your ratio of junior to senior developers depends on the kind of product you're producing. If you have an application that has a big, overarching architecture and then lots of relatively simple modules for specific cases, you want many junior developers to pound out those simple modules (e.g. different types of data entry screens).

Coding standards and standardization are always good. For a small shop you're best off looking around for one that you like and adopting it rather than trying to make your own from scratch because it is not a revenue producer and you can burn endless hours in meetings arguing about spacing, comment style, etc. Make an executive decision and move forward.

Tools and languages, again, it depends. Use the right tool for the job.

Since you don't know any of these things or how to make the tradeoffs, what you need is to hire a director of engineering who does because if you try to hire some developers and apply the vast depth of wisdom that you've acquired from this thread on Slashdot you're probably going to fail miserably.

And there's nothing in North America except trees and savages. What a short-sighted view you have.

There's a lot of value in having humans along. Currently, launch costs are so high that the costs of bringing along the life support for humans is prohibitive, but if it got cheaper many things would work better.

Consider Philae - if it had landed a few meters in another direction it would still be working. If it had been a manned expedition, that wouldn't have been an issue.

Or look at the Mars rovers. Great stuff, but there's little ability to improvise. Think up a different experiment you want done? Well, it'll have to wait for the next rover because that one can't do it.

That's such bullshit. We didn't understand the atom until a little over a century ago. Quantum mechanics even later. Just because it's been thousands of years and we haven't figured something out doesn't mean that it's unknowable.