Evolution ends at unattainable perfection
In our brief existence as a species it seems like we have only adapted but not evolved. We are simply ignoring the many years that our children spend in school, and the many devices that they learn to use, such as phones and cars. Of course our main physical evolution takes place during the nine months that the genes format our organism for output to the phase of being.
The shift of our evolution to advancement of science has affected our ideologies in positive directions, at least for the most part. Anymore we consider our differences in the color of skin as no more than cosmetic features of evolution. Perhaps we can do something about our historical feuds as well. Passing such feuds on to our children is in the opposite direction from our evolution. Let us live with the assumption that we are the intent of creation, and not just some transient random anomaly in the universe. I wish to see the end of terrorism before the infinite loop of my brain terminates.
In the universe of programming languages many species have appeared and vanished. It seems that C has passed the test of survival of the fit for programming all kinds of devices, all the way up to the complex and sophisticated operating systems.
Our initial understanding of the principles of evolution for programming languages was limited to increasing the size of libraries for a successful language. Indeed, it is agonizingly annoying to have to change code as a result of fluctuations in the programming language. In most cases the code change infects well-written software with obscure and irrecoverable defects ending in the retirement of the products.
Following the above observation, we added libraries to C for templates (generic programming) and exception handling. Those of us who used these libraries remember the agony of trying to avoid creating bugs. Those of us who moved up to C++ remember the relief that came with using linguistic constructs that put the burden of details on the compiler. This was a distinct case of the second principle of evolution for programming languages.
The second principle is not about the move from C to C++. Templates and exceptions were added much later to C++, around the end of eighties. The principle is about extending a language without causing any code change to previously written software. A linguistic extension is evolved out of extensive use of libraries and after a proper understanding of the nature of the abstraction underlying the extension. Otherwise put, a linguistic extension is a natural evolution for the language as opposed to some ad hoc marketing addition.
It is a contradiction to assume that perfection is attainable. C++ will inevitably borrow many features from its superset Z++, such as patterns for template specification, class invariants and method constraints, to name a few. C++ greatly facilitates the writing of large system programs and middleware. However, threading, client-server communication running on different platforms and graphical user interface are not within the spectrum of software for C++. Third party libraries and SDK are complications rather than solution.
The points we have made so far are as follows. A (programming) language evolves faster via libraries, and considerably slower through linguistic extensions. Evolution in the context of languages implies leaving previously written software undisturbed.
We also mentioned that C++ will necessarily continue to evolve by way of introducing new linguistic constructs. However, C++ is a system programming language in that it must be able to make direct system calls. Thus, the abstract language for the category of application software must be approached through a platform independent superset of C++. Languages that support subsets of C++ and have entirely different model, such as Java and C#, are merely transient marketing nuisances, which will vanish after punishing their adopters with huge maintenance losses.
Applications are inherently independent of platform details and system calls. The introduction of Smalltalk, Java and C# demonstrates the need for some form of infrastructure for freedom from platform. However, any fluctuation in these languages affects their virtual machine, which in turn requires costly maintenance for updating pre-existing programs.
We must separate the design of the language for developing application software from its virtual processor. It will be the responsibility of the compiler to generate code for the virtual processor, just as a C++ compiler generates code for real processors. In other words, just as the language must be upward extensible, so must be the virtual processor.
Once we achieve the above technology, our abstract language will continue to evolve without affecting previously written programs, the same way as the addition of templates and exceptions to C++ did. However, the starting point for our abstract language is quite significant. Reducing the expressiveness of C++ distorts its computational model. The proper approach is to make scientific corrections to C++ features, and then extend it based on research and the experience gained from the past.
It is high time to introduce Z++. The Z47 processor manages its own threads, exceptions, and inter-thread signals and events. With its tiny size of about 500 K the processor supports the entire language Z++ uniformly on all platforms. Thus, the language Z++ is the same on a small wireless device as it is on a pc, or a mainframe for that matter. The processor uses system calls for drawing graphical user interface elements. However, at language level the constructs related to the GUI are identical for all platforms.
The language Z++ is a superset of C++. That is in sharp contrast to the recent platform-free languages that provide a minimal and distorted model of C++. Furthermore, Z++ supports programs written in its subset C++ by linking with dynamic libraries such as DLLs. Thus, moving up to Z++ does not mean leaving behind programs written in C++.
The scientific principles behind the implementation of the processor shall not be disclosed. Those principles are for the scientifically designed abstract language Z++ for developing distributed, platform-free applications. Marketing attempts for maximizing profit will directly interfere with the evolution of the future abstract software development language.
Z++ is the inevitable eventual abstract language of the future.
The shift of our evolution to advancement of science has affected our ideologies in positive directions, at least for the most part. Anymore we consider our differences in the color of skin as no more than cosmetic features of evolution. Perhaps we can do something about our historical feuds as well. Passing such feuds on to our children is in the opposite direction from our evolution. Let us live with the assumption that we are the intent of creation, and not just some transient random anomaly in the universe. I wish to see the end of terrorism before the infinite loop of my brain terminates.
In the universe of programming languages many species have appeared and vanished. It seems that C has passed the test of survival of the fit for programming all kinds of devices, all the way up to the complex and sophisticated operating systems.
Our initial understanding of the principles of evolution for programming languages was limited to increasing the size of libraries for a successful language. Indeed, it is agonizingly annoying to have to change code as a result of fluctuations in the programming language. In most cases the code change infects well-written software with obscure and irrecoverable defects ending in the retirement of the products.
Following the above observation, we added libraries to C for templates (generic programming) and exception handling. Those of us who used these libraries remember the agony of trying to avoid creating bugs. Those of us who moved up to C++ remember the relief that came with using linguistic constructs that put the burden of details on the compiler. This was a distinct case of the second principle of evolution for programming languages.
The second principle is not about the move from C to C++. Templates and exceptions were added much later to C++, around the end of eighties. The principle is about extending a language without causing any code change to previously written software. A linguistic extension is evolved out of extensive use of libraries and after a proper understanding of the nature of the abstraction underlying the extension. Otherwise put, a linguistic extension is a natural evolution for the language as opposed to some ad hoc marketing addition.
It is a contradiction to assume that perfection is attainable. C++ will inevitably borrow many features from its superset Z++, such as patterns for template specification, class invariants and method constraints, to name a few. C++ greatly facilitates the writing of large system programs and middleware. However, threading, client-server communication running on different platforms and graphical user interface are not within the spectrum of software for C++. Third party libraries and SDK are complications rather than solution.
The points we have made so far are as follows. A (programming) language evolves faster via libraries, and considerably slower through linguistic extensions. Evolution in the context of languages implies leaving previously written software undisturbed.
We also mentioned that C++ will necessarily continue to evolve by way of introducing new linguistic constructs. However, C++ is a system programming language in that it must be able to make direct system calls. Thus, the abstract language for the category of application software must be approached through a platform independent superset of C++. Languages that support subsets of C++ and have entirely different model, such as Java and C#, are merely transient marketing nuisances, which will vanish after punishing their adopters with huge maintenance losses.
Applications are inherently independent of platform details and system calls. The introduction of Smalltalk, Java and C# demonstrates the need for some form of infrastructure for freedom from platform. However, any fluctuation in these languages affects their virtual machine, which in turn requires costly maintenance for updating pre-existing programs.
We must separate the design of the language for developing application software from its virtual processor. It will be the responsibility of the compiler to generate code for the virtual processor, just as a C++ compiler generates code for real processors. In other words, just as the language must be upward extensible, so must be the virtual processor.
Once we achieve the above technology, our abstract language will continue to evolve without affecting previously written programs, the same way as the addition of templates and exceptions to C++ did. However, the starting point for our abstract language is quite significant. Reducing the expressiveness of C++ distorts its computational model. The proper approach is to make scientific corrections to C++ features, and then extend it based on research and the experience gained from the past.
It is high time to introduce Z++. The Z47 processor manages its own threads, exceptions, and inter-thread signals and events. With its tiny size of about 500 K the processor supports the entire language Z++ uniformly on all platforms. Thus, the language Z++ is the same on a small wireless device as it is on a pc, or a mainframe for that matter. The processor uses system calls for drawing graphical user interface elements. However, at language level the constructs related to the GUI are identical for all platforms.
The language Z++ is a superset of C++. That is in sharp contrast to the recent platform-free languages that provide a minimal and distorted model of C++. Furthermore, Z++ supports programs written in its subset C++ by linking with dynamic libraries such as DLLs. Thus, moving up to Z++ does not mean leaving behind programs written in C++.
The scientific principles behind the implementation of the processor shall not be disclosed. Those principles are for the scientifically designed abstract language Z++ for developing distributed, platform-free applications. Marketing attempts for maximizing profit will directly interfere with the evolution of the future abstract software development language.
Z++ is the inevitable eventual abstract language of the future.
Labels: distributed applications, platform free, Z++
posted by Dr.Z. at 11:59 PM
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>