The role of language in software development
The capability to visualize a problem and its solution is fundamental. Visualization may be in the form of geometrical figures, algebraic formulas or musical notes. Taking geometry for an example, we can solve many problems entirely in our heads. However, when the number of lines and circles continues to grow, we use pencil and paper as an aid to our visualization mechanism in support of our imagination for arriving at a solution.
Visualization takes place in a language containing the abstractions of a particular domain. In software development the abstractions are notions such as loop, thread, class or file. Let us take C++ as the language. Now, let us take a look at some hypothetical application written for a few platforms, say Windows using MFC, Linux using GTK and say Palm using Metrowerks. After a short comparison we realize that C++ is essentially a shell. Perhaps more than half of each of these programs contains statements specific to their respective platforms. Indeed, engineers must visualize certain portions of each of these solutions quite differently.
Superficially, I think of the above situation as the Hugo Impedance Factor. Since Latin is the common shell for French and Italian, one would expect Hugo to be able to create a work similar to that of Dante in redoing his work in Italian.
The language C is indispensable in crafting anyone of the above operating systems. Similarly, C++ is indispensable in creating an initial set of sophisticated system tools for developing end-user applications. However, applications are of a different category in that their goal is to provide specific services to end-users. These services are well-understood notions independent of any particular system. The works of Hugo and Dante are masterpieces in their respective languages. On the other hand, Lobachevsky’s creation could be presented in Russian or French, just as he did.
Recapitulating, we need a language in order to visualize our solutions for end-user applications. Eventually, we will express our solution in that language for a machine. Nonetheless, we want other engineers to be able to understand our solution without the Hugo Impedance Factor. An application is similar to the work of Lobachevsky in that it is independent of the shell language used in expressing it. Therefore, we are able to take the next step, as Hilbert did, and present our solution in a universal language.
System tools are relatively small programs that facilitate the development of applications similar to the way that children build sophisticated toys from Lego pieces. The point here is that, end-user applications are generally large and complex. Indeed, modern enterprise applications are distributed and ideally should be able to utilize computing devices of all types and sizes. This ideal can only be achieved by, following Hilbert’s path and designing a universal abstract language.
Linguistic expressiveness should not be confused with library extensions. The language C is so close to the assembly language that allows the implementation of the notions of class, invariants and templates etc. However, the C compiler deals with the language C. A linguistic concept is orthogonal to the expressiveness of a language when an engineer can use the notion through a linguistic construct recognizable to its compiler. Basically, we have to differentiate between what can be implemented (computed), and how we express solutions. Libraries written in any given language do not introduce orthogonal extensions to its expressiveness (do not add a new dimension).
Considering the fact that applications, especially enterprise solutions, are complex, Java has little to offer beyond a class construct. For instance, there are no mechanisms similar to Eiffel’s invariants and constraints, nor C++ templates, just to mention a few. Solutions to modern applications require an expressive language providing a much richer set of linguistic abstractions. Simply adding more functions to an already huge library does not enhance the language.
The universal abstract programming language Z++ and its distributed operating system Z47 processor provide the most expressive medium for visualizing and developing complex solutions for modern demanding applications.
Visualization takes place in a language containing the abstractions of a particular domain. In software development the abstractions are notions such as loop, thread, class or file. Let us take C++ as the language. Now, let us take a look at some hypothetical application written for a few platforms, say Windows using MFC, Linux using GTK and say Palm using Metrowerks. After a short comparison we realize that C++ is essentially a shell. Perhaps more than half of each of these programs contains statements specific to their respective platforms. Indeed, engineers must visualize certain portions of each of these solutions quite differently.
Superficially, I think of the above situation as the Hugo Impedance Factor. Since Latin is the common shell for French and Italian, one would expect Hugo to be able to create a work similar to that of Dante in redoing his work in Italian.
The language C is indispensable in crafting anyone of the above operating systems. Similarly, C++ is indispensable in creating an initial set of sophisticated system tools for developing end-user applications. However, applications are of a different category in that their goal is to provide specific services to end-users. These services are well-understood notions independent of any particular system. The works of Hugo and Dante are masterpieces in their respective languages. On the other hand, Lobachevsky’s creation could be presented in Russian or French, just as he did.
Recapitulating, we need a language in order to visualize our solutions for end-user applications. Eventually, we will express our solution in that language for a machine. Nonetheless, we want other engineers to be able to understand our solution without the Hugo Impedance Factor. An application is similar to the work of Lobachevsky in that it is independent of the shell language used in expressing it. Therefore, we are able to take the next step, as Hilbert did, and present our solution in a universal language.
System tools are relatively small programs that facilitate the development of applications similar to the way that children build sophisticated toys from Lego pieces. The point here is that, end-user applications are generally large and complex. Indeed, modern enterprise applications are distributed and ideally should be able to utilize computing devices of all types and sizes. This ideal can only be achieved by, following Hilbert’s path and designing a universal abstract language.
Linguistic expressiveness should not be confused with library extensions. The language C is so close to the assembly language that allows the implementation of the notions of class, invariants and templates etc. However, the C compiler deals with the language C. A linguistic concept is orthogonal to the expressiveness of a language when an engineer can use the notion through a linguistic construct recognizable to its compiler. Basically, we have to differentiate between what can be implemented (computed), and how we express solutions. Libraries written in any given language do not introduce orthogonal extensions to its expressiveness (do not add a new dimension).
Considering the fact that applications, especially enterprise solutions, are complex, Java has little to offer beyond a class construct. For instance, there are no mechanisms similar to Eiffel’s invariants and constraints, nor C++ templates, just to mention a few. Solutions to modern applications require an expressive language providing a much richer set of linguistic abstractions. Simply adding more functions to an already huge library does not enhance the language.
The universal abstract programming language Z++ and its distributed operating system Z47 processor provide the most expressive medium for visualizing and developing complex solutions for modern demanding applications.
Labels: abstract language, distributed applications, language, Z++, Z47
posted by Dr.Z. at 10:25 AM
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>