Linguistic Automation of Distributed Computing
An abstract solution for distributed communicating applications is of linguistic nature. In this article the notions involved, and the process of approaching a solution are illustrated.
What is linguistic automation?
Mathematics is doomed to proving its own assertions. The programmatic demonstration of the four-color conjecture is only convincing for the most cases of practical interest. In the same vain, computer science is doomed to automating its own discoveries. Compilers and databases are concrete examples of automating discoveries within computer science.
Language is the only medium of communicating an algorithm to someone else, so he can carry out the steps. When we say that something can be done algorithmically, we mean that the algorithm can be stated in a linguistic form.
The language used for stating an algorithm is of a nature quite apart from that of mathematics. For instance, the correctness of performing multiplication of two numerals can be derived mathematically. However, the process of carrying out a multiplication is taught using a spoken language. The teacher is confident that the process she describes is in accordance to the mathematical proof.
An algorithm is considered automated when it has been stated in a programming language. The statement of an algorithm in a programming language is also called an implementation of the algorithm.
A proof that a particular notion can be done algorithmically is necessary, but not sufficient for its implementation. Furthermore, whether we can only state an algorithm in a spoken language, or we can implement it in a programming language, we can only be confident that our statement of the algorithm is in accordance to some mathematical derivation.
Linguistic automation is the process of creating a programming language for stating solutions with confidence. We have used the phrase “stating solutions” instead of “implementing algorithms” because we are interested in an abstract software development language for expressing solutions to large, complex and diverse problems.
The implementation of mathematical algorithms can be done in a small language, such as a functional or logical programming language. Thus, for a sufficiently limited scope we can make the implementation of an algorithm mirror its mathematical statement. Nevertheless, mathematical formalism is necessary for understanding and solving the theoretical problems that we face in the larger scope of contemporary distributed communicating applications.
The state of linguistic automation we are in is similar to the state of geometry somewhere between Pythagoras and Euclid. However, the span of a few centuries of that time frame translates to a few decades from now, in our time frame.
Stages of Linguistic Automation
The automation of an idea starts out at low levels because we need to interact with specific devices in order to experiment. For instance, the client-server model was automated via the concepts of sockets and ports. The socket library is low-level because it has to interact directly with the kernel.
In time we gain sufficient experience to abstract away the constituents of a model and isolate it from its implementation details. For instance, in Z++ the abstract notion of client-server has been separated from the device-level libraries supporting its implementation.
Automating away details in the form of linguistic constructs increases productivity with the pleasant by-product of reduction in the cost of maintenance phase. It is well known that the majority of activities in the maintenance phase deal with platform-related details presented as libraries and system calls.
Automation in the form of linguistic constructs has many other advantages. Among other things, the compiler can assist us in catching high-level conceptual errors in contrast to simply matching the number of arguments for a system call. Examples of this kind are structured programming and the notion of class.
Automation of Distributed Computing
The linguistic automation of distributed communicating applications running on heterogeneous platforms has been illusive for some time. The source of the difficulty has been the incorrect presumption of having to maintain compatibility with the line of products of a particular vendor. If we reduce this requirement to supporting a successful language such as C++, there is a solution.
There is no reason to maintain interoperability with dead and vanishing languages. When a language has shown to be inadequate, any further investment in enhancing products written in that language is the same as the loss of a gambler at a casino hoping for a jackpot. As it is evident, attempting to remain interoperable with such a language will result in another hack rather than a scientific solution in the form of linguistic automation.
The Z++ solution is presented in A recursive model for distributed computing. We close this article with another illustration of linguistic automation and the detail of research that it requires.
The C pointer operations provide great flexibility for the implementation of dynamic arrays. However, the reuse and maintenance is quite costly. ADA offers a simple linguistic automation alternative for dynamic arrays without the use of pointers.
C++ slightly automates the C approach, but with several problems. For instance, the type returned by the new operator is not a pointer to an array. However, instead of correcting the design problem the operator delete [] was added to the language, as it is customary with C++ extensions. Furthermore, we must accept the limitation that C++ dynamic arrays must be created using a default constructor.
For a moment assume that C++ included ADA dynamic arrays. Now suppose that you wished to create such an array in the heap, using the operator new. It should be clear that in this case the new operator must return a pointer to an array, not a pointer to a cell of that array. Now, replace the ADA array argument to the new operator with its C++ form. What is the difference? Why return a pointer to a cell and then invent “delete []”?
Z++ programming language includes ADA dynamic arrays for times that we may not wish to use pointers. As a superset of C++, it also includes the C++ dynamic arrays, however with correct design. Specifically, arrays of any type can be created using any constructor. Furthermore, the type returned by the new operator is a pointer to an array, so a simple delete will remove the entire array.
For another illustration of linguistic automation, consider the fact that an instance X of an array type is actually an object. Suppose the type of elements of array defines a method, say compute(). C++ is an object-oriented language. One should be able to say something like X.compute() and expect the compiler to send the compute message to every cell of the array X. That is precisely what Z++ automates.
Z++ is freely available from ZHMicro.
What is linguistic automation?
Mathematics is doomed to proving its own assertions. The programmatic demonstration of the four-color conjecture is only convincing for the most cases of practical interest. In the same vain, computer science is doomed to automating its own discoveries. Compilers and databases are concrete examples of automating discoveries within computer science.
Language is the only medium of communicating an algorithm to someone else, so he can carry out the steps. When we say that something can be done algorithmically, we mean that the algorithm can be stated in a linguistic form.
The language used for stating an algorithm is of a nature quite apart from that of mathematics. For instance, the correctness of performing multiplication of two numerals can be derived mathematically. However, the process of carrying out a multiplication is taught using a spoken language. The teacher is confident that the process she describes is in accordance to the mathematical proof.
An algorithm is considered automated when it has been stated in a programming language. The statement of an algorithm in a programming language is also called an implementation of the algorithm.
A proof that a particular notion can be done algorithmically is necessary, but not sufficient for its implementation. Furthermore, whether we can only state an algorithm in a spoken language, or we can implement it in a programming language, we can only be confident that our statement of the algorithm is in accordance to some mathematical derivation.
Linguistic automation is the process of creating a programming language for stating solutions with confidence. We have used the phrase “stating solutions” instead of “implementing algorithms” because we are interested in an abstract software development language for expressing solutions to large, complex and diverse problems.
The implementation of mathematical algorithms can be done in a small language, such as a functional or logical programming language. Thus, for a sufficiently limited scope we can make the implementation of an algorithm mirror its mathematical statement. Nevertheless, mathematical formalism is necessary for understanding and solving the theoretical problems that we face in the larger scope of contemporary distributed communicating applications.
The state of linguistic automation we are in is similar to the state of geometry somewhere between Pythagoras and Euclid. However, the span of a few centuries of that time frame translates to a few decades from now, in our time frame.
Stages of Linguistic Automation
The automation of an idea starts out at low levels because we need to interact with specific devices in order to experiment. For instance, the client-server model was automated via the concepts of sockets and ports. The socket library is low-level because it has to interact directly with the kernel.
In time we gain sufficient experience to abstract away the constituents of a model and isolate it from its implementation details. For instance, in Z++ the abstract notion of client-server has been separated from the device-level libraries supporting its implementation.
Automating away details in the form of linguistic constructs increases productivity with the pleasant by-product of reduction in the cost of maintenance phase. It is well known that the majority of activities in the maintenance phase deal with platform-related details presented as libraries and system calls.
Automation in the form of linguistic constructs has many other advantages. Among other things, the compiler can assist us in catching high-level conceptual errors in contrast to simply matching the number of arguments for a system call. Examples of this kind are structured programming and the notion of class.
Automation of Distributed Computing
The linguistic automation of distributed communicating applications running on heterogeneous platforms has been illusive for some time. The source of the difficulty has been the incorrect presumption of having to maintain compatibility with the line of products of a particular vendor. If we reduce this requirement to supporting a successful language such as C++, there is a solution.
There is no reason to maintain interoperability with dead and vanishing languages. When a language has shown to be inadequate, any further investment in enhancing products written in that language is the same as the loss of a gambler at a casino hoping for a jackpot. As it is evident, attempting to remain interoperable with such a language will result in another hack rather than a scientific solution in the form of linguistic automation.
The Z++ solution is presented in A recursive model for distributed computing. We close this article with another illustration of linguistic automation and the detail of research that it requires.
The C pointer operations provide great flexibility for the implementation of dynamic arrays. However, the reuse and maintenance is quite costly. ADA offers a simple linguistic automation alternative for dynamic arrays without the use of pointers.
C++ slightly automates the C approach, but with several problems. For instance, the type returned by the new operator is not a pointer to an array. However, instead of correcting the design problem the operator delete [] was added to the language, as it is customary with C++ extensions. Furthermore, we must accept the limitation that C++ dynamic arrays must be created using a default constructor.
For a moment assume that C++ included ADA dynamic arrays. Now suppose that you wished to create such an array in the heap, using the operator new. It should be clear that in this case the new operator must return a pointer to an array, not a pointer to a cell of that array. Now, replace the ADA array argument to the new operator with its C++ form. What is the difference? Why return a pointer to a cell and then invent “delete []”?
Z++ programming language includes ADA dynamic arrays for times that we may not wish to use pointers. As a superset of C++, it also includes the C++ dynamic arrays, however with correct design. Specifically, arrays of any type can be created using any constructor. Furthermore, the type returned by the new operator is a pointer to an array, so a simple delete will remove the entire array.
For another illustration of linguistic automation, consider the fact that an instance X of an array type is actually an object. Suppose the type of elements of array defines a method, say compute(). C++ is an object-oriented language. One should be able to say something like X.compute() and expect the compiler to send the compute message to every cell of the array X. That is precisely what Z++ automates.
Z++ is freely available from ZHMicro.
Labels: abstract language, algorithm, distributed applications, linguistic automation, object-oriented, Z++
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>