Yes, double digit growth is a thing of the past, for reasons that should be obvious to anyone in this industry who takes some time to look. But it's would be a mistake to confuse the situation the article is discussing with the e-bubble boom and bust of the last few years. Think instead about the growth of the industry over the 40 or 20 years.
Twenty years ago, when microprocessor based computers first appeared on the scene, only mid-size to large companies had computers (main-frames or minis) and only a comparative few indivduals had home computers. Today, every business and most homes have computers. You would be hard pressed to find a vertical market that isn't supported by multiple software packages or in-house appplications.
It's easy to have high rates of growth in a green-field. Once a market has been saturated, you can only grow at approximately the rate of growth of the economy as a whole.
You're right -- that's hardly the end of the world. It's still a very large market for hardware and software vendors (and all their employees).
As for high rates of growth comming from new functions, it's always possible but less and less likely. It's becomming more and more difficult to find some function that can deliver provable high ROI. In fact, it is still a moot question about whether the massive investment in IT over the last decade (taken as a whole) produced any real productivity gains at all.
I'd agree that today there is little need to worry about integer size -- my point was about the historical origins of the practice.
When I first started working on Unix systems 20 years ago, there were over 80 different version of the system and being careful about integer size was a necessary defensive practice.
AT that time it was common to migrate several times a year from system to system. On one project I had to write and test on one system and then transfer the source overnight (via uucp!) to a customer's machine running a completely different verson of the OS and complier. All debugging was done at the assembler level using adb - I'm glad that's all a thing of the past.
Still, there are instances where it is necessary to be aware and clear about primitive datatype size in C and C++, -- for example, when you need to use 64bit floating point for financial math -- but using typedefs and/or classes is much preferred to #defines. Using alternate names for primitive types makes it clear to everyone on a project what use is intended. Such uses should, of course, be well documented in a project's programming standards.
The practice of using defined names for native types goes back to the early days of C compliers when the size of int varied from complier to complier. The use of defines was part of the Plum Hall C Stamdards guide.
I believe that programs should read like novels; there should be long paragraphs of text that describe what and how the code is working followed by short bursts of actual 'dialog' that is the actual source instruction to the computer.
Donald Knuth developed a programming methodolgy and tools to do exactly this. He wrote about it in
Literate Programming. It really is surprising that no one has followed up on this line of thought.
Well, we do try to do a good job of not being noticed by Americans. But for the record, we've particpated in Afganistan, Kosovo, Bosnia, Somalia, and Rwanda to name a few of the more recent conflicts.
Yes, if you take a short-term view it doesn't seem to make any sense to say this war is about oil. But, if you look at the longer term - over the rest of this century - its absolutely clear that it is and must be.
It seems that few people have paid attention to what has been referred to as the 'Hubbert Peak' debate about the longterm prospects for world oil production. In an important article, "The End of Cheap Oil", published in Scientific American in 1998, two oil industry experts, C.J. Campbell and J.H. Laherrer, reviewed the current data on world oil production, reserves and exploration and concluded that "Global production of conventional oil will begin to decline sooner than most people think, probably within 10 years". The approach they used was pionneered by Shell Oil geologist King Hubbert to predict correctly the oil production from the lower 48 American states would peak around 1969.
While there is considerable debate about the precise timing of the peak - some think it will be as early as this year, others expect it early in the next date, and the optimists (the USGS) think we may have until 2038 - it is clear that nobody thinks that world production will rise indefintely.
What makes this relevant to the current situation in Iraq is this:
* production from oil fields outside of the Persian Gulf has peaked and will continue to decline.
* Any new fields are expected to be small and will not serve to increase overall world production.
* The Persian Gulf states have the world's largest reserves of oil and will be increasingly important as other supplies decline.
* US oil consumption will continue to rise for the forseeable future: it is expected that by 2025, the US will be importing 75% of what it consumes.
* The US will be forced source an ever greater percentage of its oil needs from the Persion Gulf region, in competition with Europe, China and much the developing world.
* The US is more dependent on abundant, cheap oil than any other nation to sustain its economy and ultimately its military superiority.
* Control of Persian Gulf oil is absolutely strategic.
Yes, double digit growth is a thing of the past, for reasons that should be obvious to anyone in this industry who takes some time to look. But it's would be a mistake to confuse the situation the article is discussing with the e-bubble boom and bust of the last few years. Think instead about the growth of the industry over the 40 or 20 years.
Twenty years ago, when microprocessor based computers first appeared on the scene, only mid-size to large companies had computers (main-frames or minis) and only a comparative few indivduals had home computers. Today, every business and most homes have computers. You would be hard pressed to find a vertical market that isn't supported by multiple software packages or in-house appplications.
It's easy to have high rates of growth in a green-field. Once a market has been saturated, you can only grow at approximately the rate of growth of the economy as a whole.
You're right -- that's hardly the end of the world. It's still a very large market for hardware and software vendors (and all their employees).
As for high rates of growth comming from new functions, it's always possible but less and less likely. It's becomming more and more difficult to find some function that can deliver provable high ROI. In fact, it is still a moot question about whether the massive investment in IT over the last decade (taken as a whole) produced any real productivity gains at all.
I'd agree that today there is little need to worry about integer size -- my point was about the historical origins of the practice.
When I first started working on Unix systems 20 years ago, there were over 80 different version of the system and being careful about integer size was a necessary defensive practice. AT that time it was common to migrate several times a year from system to system. On one project I had to write and test on one system and then transfer the source overnight (via uucp!) to a customer's machine running a completely different verson of the OS and complier. All debugging was done at the assembler level using adb - I'm glad that's all a thing of the past.
Still, there are instances where it is necessary to be aware and clear about primitive datatype size in C and C++, -- for example, when you need to use 64bit floating point for financial math -- but using typedefs and/or classes is much preferred to #defines. Using alternate names for primitive types makes it clear to everyone on a project what use is intended. Such uses should, of course, be well documented in a project's programming standards.
The practice of using defined names for native types goes back to the early days of C compliers when the size of int varied from complier to complier. The use of defines was part of the Plum Hall C Stamdards guide.
I believe that programs should read like novels; there should be long paragraphs of text that describe what and how the code is working followed by short bursts of actual 'dialog' that is the actual source instruction to the computer.
Donald Knuth developed a programming methodolgy and tools to do exactly this. He wrote about it in Literate Programming. It really is surprising that no one has followed up on this line of thought.
Well, we do try to do a good job of not being noticed by Americans. But for the record, we've particpated in Afganistan, Kosovo, Bosnia, Somalia, and Rwanda to name a few of the more recent conflicts.
Yes, if you take a short-term view it doesn't seem to make any sense to say this war is about oil. But, if you look at the longer term - over the rest of this century - its absolutely clear that it is and must be.
It seems that few people have paid attention to what has been referred to as the 'Hubbert Peak' debate about the longterm prospects for world oil production. In an important article, "The End of Cheap Oil", published in Scientific American in 1998, two oil industry experts, C.J. Campbell and J.H. Laherrer, reviewed the current data on world oil production, reserves and exploration and concluded that "Global production of conventional oil will begin to decline sooner than most people think, probably within 10 years". The approach they used was pionneered by Shell Oil geologist King Hubbert to predict correctly the oil production from the lower 48 American states would peak around 1969.
While there is considerable debate about the precise timing of the peak - some think it will be as early as this year, others expect it early in the next date, and the optimists (the USGS) think we may have until 2038 - it is clear that nobody thinks that world production will rise indefintely.
What makes this relevant to the current situation in Iraq is this:
* production from oil fields outside of the Persian Gulf has peaked and will continue to decline.
* Any new fields are expected to be small and will not serve to increase overall world production.
* The Persian Gulf states have the world's largest reserves of oil and will be increasingly important as other supplies decline.
* US oil consumption will continue to rise for the forseeable future: it is expected that by 2025, the US will be importing 75% of what it consumes.
* The US will be forced source an ever greater percentage of its oil needs from the Persion Gulf region, in competition with Europe, China and much the developing world.
* The US is more dependent on abundant, cheap oil than any other nation to sustain its economy and ultimately its military superiority.
* Control of Persian Gulf oil is absolutely strategic.