Software engineering and the future of mankind
This article is somewhat philosophical in nature. It intends to demonstrate the enormous potential of software in the future of humanity, and to indicate the required infrastructure for harnessing this potential. It also presents a view of software engineering. We begin with a brief observation of our biological software.
The hardware comprising modern man is the same as its original form of 40,000 years ago. Though brain seems to adjust itself at various stages of a person’s life, there is no evidence that our brain’s processing power has increased since then. Quite to the contrary, there is all the evidence pointing to the abundance of idiots among us.
Indeed, the less intelligent a person, the more likely to achieve positions of power. There are animal-level smartness and human-level intelligence. These are not to be measured by the same standard. Even a monkey has sufficient brain to steal another monkey’s food, whether or not it is actually hungry. Exactly where is the evidence of human intelligence versus animal smartness in recent absurd oil profits?
Returning to our topic, human hardware did little to manipulate nature for better lives for mankind, until mental software equipped the brain with more sophisticated processing capabilities. A baby’s hardware processing power is the same as a baby born 40,000 years ago. The difference is the better mental software that a modern baby picks up through education.
Obviously, our computer hardware will continue to evolve providing more processing power, better input/output interface and so on. However, hardware is only necessary but not sufficient for boosting our technological achievements. The real breakthroughs will come from advancements in (intelligent) software, especially the tools, methods and theories for developing complex and highly sophisticated software.
Software is not limited to applications running on a desktop computer. In fact, the country with greater number of properly educated software engineers will eventually surpass other countries filled with programmers and coders. One reason for this is the fact that educated engineers have better insight and make observations that are invisible to ordinary programmers. Presently, none-practicing scientists are making observations from erroneous practices of programmers. Practicing engineers will be able to make observations against their own performance, thereby accelerating progress in software development.
Consider a country equipped with intelligent missiles that can bring planes down and avoid crashing into an anti-missile defense system. I only mentioned this example so those seeking wars will understand the significance of future intelligent software. Nevertheless, it stands to reason that rudimentary hardware under the control of sophisticated software can easily outperform advanced hardware equipped with weaker software.
The argument here is that apart from tremendous potential in software, it is the most significant means of our future achievements. However, the infrastructure to harness this potential is still in bronze age. The needed infrastructure is a large number of properly educated software engineers. Professional programmers who write code for a living are assets, but not major players of this infrastructure.
The difference between software engineers and programmers is quite similar to the difference between physicians and lab technicians. Presently, we have an overflow of technicians, mostly self-trained, with very few engineers. As a result hardware variations are skirting existing software technologies that do not work well. For instance, consider the variety of cell-phones and the quality of service they provide, in particular the regularity of dropped-calls.
Engineers in areas other than software engineering study a lot of theory while learning a technician’s skills. These training branches are combined into one at later stages of an engineer’s education. Nonetheless, an engineer can also perform as a skillful technician just as a doctor can confidently act as a nurse. This, however, is not the case in software engineering. Indeed, a university curriculum cannot devote some 100 credit hours for covering all the languages, libraries and platforms, nor the student will be able to use such scattered information.
The reality is that we are in a bigger mess than Y2K, which only involved one single language. Eventually, the chaos will be confronted by software developing companies rather than universities or so-called technology leaders. The overburdened software developers will recognize the value of an abstract language, which in turn will provide the necessary incentive for universities to react to the tidal wave.
Some claim that software engineering is distinct from programming in that an engineer deals with software characteristics, such as reliability, availability etc. The fallacy here is that, relevant software characteristics are not easily quantifiable and the easily quantified factors are not practically useful. In fact, without being involved in the development of software an engineer has few useful criteria for measuring any of its characteristics.
Another way of looking at software engineering is through the eyes of a mathematician. Furthermore, avoid confining software engineering to the work of a web designer. It is hard to imagine a mathematician who can prove theorems without the ability to manipulate symbols, though certainly a mathematician is not a biological calculator. In the same vain it is hard to imagine an engineer who can solve programming problems without the ability to program, though an engineer is not a GUI developer on a particular platform.
An abstract language, such as Z++ programming language, does not change the nature of software engineering. However, it does solve a major problem by reducing the distance between an engineer and a developer. In particular an extensible formalism facilitates future abstractions in the hands of software engineers.
The following list provides further reading on the subject of this article.
Z++ and Academic Research
Research requires Abstract Language
An abstract language is indispensable for educating engineers
The hardware comprising modern man is the same as its original form of 40,000 years ago. Though brain seems to adjust itself at various stages of a person’s life, there is no evidence that our brain’s processing power has increased since then. Quite to the contrary, there is all the evidence pointing to the abundance of idiots among us.
Indeed, the less intelligent a person, the more likely to achieve positions of power. There are animal-level smartness and human-level intelligence. These are not to be measured by the same standard. Even a monkey has sufficient brain to steal another monkey’s food, whether or not it is actually hungry. Exactly where is the evidence of human intelligence versus animal smartness in recent absurd oil profits?
Returning to our topic, human hardware did little to manipulate nature for better lives for mankind, until mental software equipped the brain with more sophisticated processing capabilities. A baby’s hardware processing power is the same as a baby born 40,000 years ago. The difference is the better mental software that a modern baby picks up through education.
Obviously, our computer hardware will continue to evolve providing more processing power, better input/output interface and so on. However, hardware is only necessary but not sufficient for boosting our technological achievements. The real breakthroughs will come from advancements in (intelligent) software, especially the tools, methods and theories for developing complex and highly sophisticated software.
Software is not limited to applications running on a desktop computer. In fact, the country with greater number of properly educated software engineers will eventually surpass other countries filled with programmers and coders. One reason for this is the fact that educated engineers have better insight and make observations that are invisible to ordinary programmers. Presently, none-practicing scientists are making observations from erroneous practices of programmers. Practicing engineers will be able to make observations against their own performance, thereby accelerating progress in software development.
Consider a country equipped with intelligent missiles that can bring planes down and avoid crashing into an anti-missile defense system. I only mentioned this example so those seeking wars will understand the significance of future intelligent software. Nevertheless, it stands to reason that rudimentary hardware under the control of sophisticated software can easily outperform advanced hardware equipped with weaker software.
The argument here is that apart from tremendous potential in software, it is the most significant means of our future achievements. However, the infrastructure to harness this potential is still in bronze age. The needed infrastructure is a large number of properly educated software engineers. Professional programmers who write code for a living are assets, but not major players of this infrastructure.
The difference between software engineers and programmers is quite similar to the difference between physicians and lab technicians. Presently, we have an overflow of technicians, mostly self-trained, with very few engineers. As a result hardware variations are skirting existing software technologies that do not work well. For instance, consider the variety of cell-phones and the quality of service they provide, in particular the regularity of dropped-calls.
Engineers in areas other than software engineering study a lot of theory while learning a technician’s skills. These training branches are combined into one at later stages of an engineer’s education. Nonetheless, an engineer can also perform as a skillful technician just as a doctor can confidently act as a nurse. This, however, is not the case in software engineering. Indeed, a university curriculum cannot devote some 100 credit hours for covering all the languages, libraries and platforms, nor the student will be able to use such scattered information.
The reality is that we are in a bigger mess than Y2K, which only involved one single language. Eventually, the chaos will be confronted by software developing companies rather than universities or so-called technology leaders. The overburdened software developers will recognize the value of an abstract language, which in turn will provide the necessary incentive for universities to react to the tidal wave.
Some claim that software engineering is distinct from programming in that an engineer deals with software characteristics, such as reliability, availability etc. The fallacy here is that, relevant software characteristics are not easily quantifiable and the easily quantified factors are not practically useful. In fact, without being involved in the development of software an engineer has few useful criteria for measuring any of its characteristics.
Another way of looking at software engineering is through the eyes of a mathematician. Furthermore, avoid confining software engineering to the work of a web designer. It is hard to imagine a mathematician who can prove theorems without the ability to manipulate symbols, though certainly a mathematician is not a biological calculator. In the same vain it is hard to imagine an engineer who can solve programming problems without the ability to program, though an engineer is not a GUI developer on a particular platform.
An abstract language, such as Z++ programming language, does not change the nature of software engineering. However, it does solve a major problem by reducing the distance between an engineer and a developer. In particular an extensible formalism facilitates future abstractions in the hands of software engineers.
The following list provides further reading on the subject of this article.
Z++ and Academic Research
Research requires Abstract Language
An abstract language is indispensable for educating engineers
posted by Dr.Z. at 9:24 AM
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>