September 12, 2014
Hello
White Paper
The Distributed Language
V1.0.3 ( alpha ) White Paper
Boris Burshteyn [email protected]
V1.0.3 (alpha) One Solution September 12, 2014
Page 2
Abstract
Hello is a general-purpose, object-oriented, protocol-agnostic distributed programming language. This paper explains the ideas that guided design of Hello. It shows the spirit of Hello using two brief expressive programs and provides a summary of language features. In addition, it explores historical parallels between the binary programming of early computers and the distributed pro-gramming of modern networks. Hello documentation, translator and runtime engine are freely available at [14]. Preface “Whether oratory is a creation of rules, or of training, or of natural gifts, it is the most difficult of all things to achieve.” Cicero, “The Brutus,” 46 B.C.E.
Cicero – the most gifted orator of all times – had real-ized the extreme difficulty of communication more than two thousand years ago. Obviously, there were no computers when he made his famous speeches in the Roman Courts, Assemblies, and Senate, and wrote treatises about the orato-ry art. At that time, his talents flourished in the area of one-way human communication. Today computers exchange code and data across the networks with the help of sophisticated hardware devices, intricate networking protocols and elaborate software sys-tems. This immensely complex communication infrastruc-ture makes creation of networking software an extremely difficult and costly enterprise. Thus, the Cicero’s quote remains true when applied to modern computer networking – distributed software is one of the hardest fields of soft-ware engineering. The distributed applications orchestrate computations across the network while utilizing a multitude of collaborat-ing computers. Their development demands significant investments in labor, time, and finances. Therefore, a relent-less quest for a silver bullet that would reduce the develop-ment efforts continues. This paper presents Hello -- a general-purpose, object-oriented, imperative, protocol-agnostic programming lan-guage for writing distributed software. Its unique first-class distributed language features put Hello in an excellent posi-tion to cut the costs and ease the pain of the distributed software development. Background
The idea to create a distributed programming language emerged during the long experience of designing and im-plementing commercial-grade networking applications as diverse as a Distributed Database, High Availability Cluster Monitor, MAPI-based Email Server (via wire-level protocol discovery), and a Video-Conferencing Server. During that work, communication libraries implemented abstractions that hid the underlying network protocol. These abstractions represented interconnected servers communicating over the network between themselves and with clients. Three Problems
Although the applications were quite different, they ab-stracted the distributed hardware and software in a similar way. Still, the abstractions had to be implemented each time anew as all systems had re-invented many of the same building blocks: the re-programming involved remote ob-jects, connections, messages, queues, jobs, replies, timeouts, state changes, failures, and others. Because the language in hand had no first-class distrib-uted features, it needed help of extraneous distributed librar-ies. However, since the language knew nothing about the libraries, which offered only low level networking interface, the coding and debugging were difficult for programmers while the optimization was impossible for a translator. At the end, there were no time and project resources left to improve efficiency and reliability of the communication components. In summary, the following three problems characterized many distributed systems: Repeated re-coding of the same distributed primitives. 2)
Challenging development process due to the combina-tion of a programming language and extraneous library. 3)
Inefficient and unreliable distributed code. One Solution
Those repetitive efforts had built determination to de-velop distributed primitives for reuse in a diverse spectrum of applications. To embed them in the language was a logi-cal choice because it offered simultaneous simplicity of thought and efficiency of code . The distributed program-ming language has nicely solved all three problems men-tioned above: 1) Since the first-class distributed language features are always available, there is no need to re-implement them for every new application. 2)
These protocol-agnostic features, being higher level than the library interfaces, cut the need for extraneous tools while simplifying development and debugging. 3)
The distributed object-oriented language architecture and the optimizing translator raise the efficiency, relia-bility, and security of the distributed code. The distributed elements, implemented in both the lan-guage translator and its runtime system, become as ubiqui-tous as are the local primitives like heap, stack, method, class, variable, and object. Therefore, one does not need extraneous libraries, but can rely only on the language trans-lator, and runtime to achieve the productive software devel-opment combined with the efficient and reliable distributed code. Thus, the distributed programming language Hello was born to blend the protocol-agnostic network model into the fabric of an object-oriented paradigm. It was also natural because the author had extensive experience with parser generators and a variety of language frontends.
V1.0.3 (alpha) Hello, World! September 12, 2014
Page 3 Language Design Goals
One of the primary goals set during the Hello design was its future widespread adoption by the software engi-neering community. Therefore, it was crucial to come up with a general-purpose language, avoiding the danger of falling into a niche of specialized languages [20]. Another goal was to abstract in the language the components of the entire network and its protocols. The abstraction level should be high enough to conceal the mundane intricacies of the rigid protocol interfaces, yet not too high to make the language overly specialized. In addition, distributed primi-tives were meant to become a crucial part of the language, but not its dominant part: the language core should remain filled with general-purpose abstractions for sequential com-putations, which are running on a single host. Towards these goals, the lower-level distributed ab-stractions embedded into the language’s type system, aug-mented by a few imperative operations, had been invented.
Any particular distributed semantics can now be derived from a combination of the Hello distributed primitives -- engines, hosts, queues, partitions, groups, messages, events, and remote references -- and their operations. Language Design Principle
Historically, single-host general-purpose languages ab-stract the computer memory, memory-stored programs, and CPU from the computer hardware architecture first articu-lated in 1945 by J. von Neumann in [21]. However, distrib-uted abstractions should differ from single-host abstractions because of the following fundamental differences between the single-host and distributed architectures. As J. Backus explained in [1], imperative single-host languages are designed so that their programs reflect the linear structure of the von Neumann machine: variables and statements from the source text of a program are translated into data and CPU instructions stored in the contiguous memory of a single host. Moreover, the linear text-descending control flow (with occasional goto s and loops) in the source program corresponds to the linear address-ascending control flow (with occasional jumps and branch-es) in its translated machine code, which is stored in a single piece of memory at runtime. However, distributed software does not run in a single memory piece – its components execute on different com-puters with separate memory units. The computers connect, communicate and compute in a network of any structure: from linear – to hierarchical -- to the full graph. Network topology and connections between application’s compo-nents often change with time. Thus, the linear text-to-memory mapping idea that guided design of the imperative single-host languages fails for distributed languages. At the same time, a distributed language should abstract the net-worked components such as computers, processes, threads, objects, messages, events, and code packages. It shall pro-vide first-class language features to manage distributed operations with inevitable timeouts and failures, and to hide the underlying networking protocol.
Therefore, Hello design principle was to implement the distributed abstractions inside the language’s type system : 1)
Hello provides several built-in classes augmented with a few operations and statements, organically interwo-ven into the language’s imperative syntax and object-oriented semantics. Instances of these classes represent hosts, runtime engines, memory partitions, and execu-tion queues spread out around the network; their pur-pose is to support first-class distributed language fea-tures transparently to Hello programs. At runtime, host instances self-organize into distributed groups, which graph structures reflect dynamic network connections. 2)
The instances of user-defined classes – objects – reside in memory partitions and engine heaps around the net-work referring to each other through local and remote references. The runtime engines, with the help of the translator and the instances of the built-in classes, transparently navigate object references. The naviga-tion allows Hello programs to manipulate and transfer data, code and control flow over the network. Hello, World!
The following example shows how Hello first-class dis-tributed features and sequential core allow for a simple design. In addition, it demonstrates fast coding of the short and efficient distributed programs. This example highlights Hello advantages over the single-host languages C [4], C++ [5] and Java [18] augmented with extraneous distributed libraries. The program “Hello, World!” shows just some first-class distributed features of the Hello language, which set it apart from any single-host programming language. The whole program is a class named
HelloWorld . It contains a function main() that invokes a function print() on the hosts referred to from the built-in group hosts : package Hello_World; class HelloWorld { // Broadcast to all known hosts public static void main() { hosts.+print("Hello, World!\n" + this_host.name() + ":-)\n"); } }; The two Hello concepts illustrated by this example are a group , which is a graph-ordered collection of objects, and operator of bottom-up iteration .+ , which invokes, in the graph order, an iterator function on each of the group's objects. In particular, the built-in group named hosts , has its objects distributed across the network -- each object is a separate instance of class host_group , residing within the virtual or physical host, which this object describes. At runtime, Hello engines maintain this group automatically: two objects are connected in the group if their hosts can V1.0.3 (alpha) Distributed Architecture September 12, 2014
Page 4 communicate over the network. The definition of host_group is located in the Hello package standard ; here is its relevant abbreviated fragment: public external group class host_group { public external host current_host; public external copy host_group[] children(); public external iterator void print(copy char[] str) { current_host.print(str); } };
When main() is started on a runtime engine, it begins iterating function print() on the objects from the group hosts . Because each host object resides on a different host, print() is invoked on different hosts -- once locally on the current host referred to by current_host and once remotely on each of the remote children hosts referred to by references from the array returned by the function with the reserved name children() . During the iteration, at each invocation print() writes a greeting signed with the name of the host where main() has been started and kept waiting for the iteration to finish; this name is a character array returned by the method cur-rent_host.name() . At each invocation, print() writes to the standard output of the host where print() is invoked, local or remote. Its argument is a string combined, with the operator concatenation + , from the three portions of the greeting: two literal strings and one character array. It is copied across the network during iteration and passed to print() at each invocation. Package standard is an internal part of the Hello runtime – it contains types that support distributed architec-ture (e.g. classes host and host_group ). A programmer may want to learn a general functionality of some standard types and operations described in Hello Programming Guide [14]. However, there is no need to understand its details or even import it into any package. Hello, C++ & Java!
The simple imperative and object-oriented features coupled with the distributed abstractions distinguish gen-eral-purpose Hello architecture from the specialized distrib-uted architectures . In addition, the following code snippets present “Hello, World!” broadcasts in Java and C++ as seen at [13] and [3]. Since neither Java nor C++ has distributed features, both resort to extraneous libraries: Java to RMI, C++ to BOOST.mpi. The difference with the “Hello, World!” writ-ten in Hello is apparent – the latter has no setup while both C++ and Java use most of their code (in red) for setting up translation and runtime contexts. At the same time, Hello code is much shorter than either C++ or Java. Moreover, the Java source shows only the Like the object mobility in Emerald [11], actors in Salsa [25], or process-orientation of Erlang [9]. server part – the client portion from [13] adds even more Java code while Hello broadcast does not distinguish be-tween client and server.
Figure 1 Java broadcasting server program as seen at [13]
Figure 2 C++ broadcasting program as seen at [3] Distributed Architecture
In order to be useful, any distributed language should provide first-class features that reflect the program’s runtime distributed environment. They can manifest them-selves through particular fundamental data types and their operations, as well as through a runtime context. In order to make software development productive and programs runtime efficient, such architecture should reflect general functionality of the major components of modern networks. At the same time, it should be precise enough for the trans-lator and runtime system to be able to map that architecture on the runtime environment, and to optimize it. To be accepted among software engineers, the distribut-ed primitives should augment, but not overwhelm the se-quential language elements. These elements must remain its central part. Therefore, the Hello networking components are designed in order to blend with the main sequential core of the language, which resembles a simplified Java subset. package example.hello; import java.rmi.registry.Registry; import java.rmi.registry.LocateRegistry; import java.rmi.RemoteException; import java.rmi.server.UnicastRemoteObject; public class Server implements Hello { public Server() {} public String sayHello() { return "Hello, world!"; } public static void main(String args[]) { try { Server obj = new Server(); Hello stub = (Hello) UnicastRemoteObject. exportObject(obj, 0); // Bind the remote object stub in the registry Registry registry = LocateRegistry. getRegistry(); registry.bind("Hello", stub); System.err.println("Server ready"); } catch (Exception e) { System.err.println("Server exception: " + e.toString()); e.printStackTrace(); } } }
V1.0.3 (alpha) Translation September 12, 2014
Page 5
The following list presents the essential elements of the Hello distributed architecture: Sourcepack is a set of all source files with Hello pro-grams under a single directory that together constitute a Hello package. Sources define hierarchies of related classes and interfaces. Each class represents both data that are instantiated as objects and functions which op-erate on objects at runtime. Interface defines shared da-ta and function prototypes implemented by derived classes. Each source file must have extension .hlo , like
HelloWorld.hlo . Runpack is a shared library built from all sources of a source package by Hello translator: a sourcepack abc becomes runpack abc.so . Hello runtime engine loads and executes multiple runpacks at runtime. Engines from different computers exchange runpacks at runtime on demand, following the program control flow. Run-pack code accesses data from memory partitions locat-ed on the same or different hosts. Runpacks contain machine instructions rather than intermediary code – they are binary libraries, which execute their code di-rectly on CPU. 3)
Hello translator is an executable /usr/bin/het , this translates Hello sourcepack into a runpack. The translator also archives and installs Hello sourcepacks. 4)
Computer is a physical or virtual computing machine that may persistently store Hello packages in its direc-tories, capable of running Hello packages, translator, hosts and runtime engines. A computer may reside on a network, which is used by runtime engines in order to transfer the Hello data, control flow, and runpacks be-tween different hosts. 5)
Host is a uniquely named set of runtime engines and partitions running on a computer. Each computer may run a single primary host and a number of secondary hosts. Engines from the same host directly access data from all partitions of their host. Engines from different hosts access each other’s data through the network even if they run on the same computer. 6)
Partition is a piece of virtual memory that holds shared runtime data – objects, as well as arrays of references to objects and primitive data. Each host may contain sev-eral partitions created by its engines. The partition data is available for multiple programs executing concur-rently on either local or remote hosts. 7)
Runtime engine is an executable /usr/bin/hee , this loads and executes runpacks. Runtime engine maintains its data heap accessible only to programs executed on its behalf. In addition, engines are responsible for automatic and transparent transferring of code, data and control flow between the hosts across the network. An engine accesses partitions from its host by mapping its virtual memory onto the partitions. 8)
Network is a physical or virtual medium, which con-nects hosts from the same or different computers. Hello does not impose any particular operational characteris-tics on the network as long as the network is capable of maintaining locally unique computer addresses and of transferring code, data and control flow between the engines from the connected hosts. Hello is a protocol-agnostic language, as it imposes no requirements on the underlying network protocol; neither has it exposed any of the protocol elements to Hello programs . 9) Queue is a system object that queues up execution requests and subsequently dispatches them onto an exe-cution thread; each Hello program executes on behalf of a thread designated to a particular queue. 10)
Event is a call to a method with partially supplied ar-guments. Events accumulate on the queues, which exe-cute events when subsequent calls complete the meth-od’s argument list. Events serve for delayed method in-vocation as well as for synchronization between local and remote queue threads. 11)
SID and Privilege protect distributed data from unau-thorized access. A Security Id (SID) is a 16-byte glob-ally unique identifier that represents, via a bitmask, a set of privileges at runtime. Every queue has a set of pairs (SID, privilege) that determines operations al-lowed for the programs executed on behalf of the queue. In addition, an individual remote object may al-so have a set of such pairs to control operations allowed on the object. Finally, each host maintains a map of such pairs in order to determine the kinds of permissi-ble remote requests executed on the host. 12)
Neighborhood and
Path assist in reaching distributed code and data across the network. A host neighborhood contains connected hosts that communicate directly, without any help from intermediary hosts. A host path is a sequence of connected hosts between two discon-nected hosts; disconnected hosts communicate through the connected hosts from the path. The runtime engines build neighborhoods, accumulate host paths, and use them, transparently to Hello programs, while navigating the network between the hosts. Hello programs can control the neighborhood and paths formation as well as the path navigation policies. Translation
The following figure illustrates how Hello translator het translates a source package into a runpack: However, the current runtime engine implementation requires the network to support the TCP protocol from IPV4.
V1.0.3 (alpha) Language Features September 12, 2014
Page 6
Figure 3 Hello Translation
Note that all source files from a given package partici-pate in this operation. Although het can translate individu-al source files, it does not build the runpack unless it suc-cessfully translates all sources from the package. Another important feature of the Hello translation process is that het first translates Hello sources into C++ sources, and then automatically invokes the C++ compiler that further translates the C++ sources into a runpack – a shared binary library. Sample Code – Remote Shell
The
Appendix at the end of this paper presents a sam-ple Hello code -- Remote Shell -- a program that executes a UNIX shell command on a remote host. Its code contains extensive comments in order to assist in the detailed under-standing. In addition, here is a brief high-level explanation of its workings.
From the command line, the program accepts the name of the remote host, the number of buffers to parallelize data transfer, the UNIX command to execute on the remote host, and the arguments required for the execution. The program works in a remarkably simple way: it creates two instances of class
Shell – one on the local host and one on the re-mote host. After that, the local engine passes command arguments to the remote instance, which executes the com-mand. Then the local engine enters a loop that catches por-tions of the command’s stdout output one after another and transfers it back to the local Shell instance. That in-stance dumps the data on the stdout of the local Hello runtime engine. All three (potentially massive) data operations of reading data from the command stdout , transferring that data back to the original host, and dumping it on the stdout of the local host are performed in parallel. They involve Hello built-in asynchronous queuing operators and passing meth-od parameters by value. This program also utilizes other distributed facilities such as creating instances of external classes on remote hosts, and synchronizing local expres-sions via queues. Together, these first-class distributed language features make Hello Shell simple to design and easy to develop while the resulting binary ends up being as efficient as its C counterpart rsh . Hello, C!
It is fascinating to compare the amount of code from the Hello Shell program and the C code from the widely known UNIX remote shell rsh [24]. After deleting empty lines and all comments from the source code of both pro-grams, running word count on both C rsh.c and Hello
Shell_World/Shell.hlo produces this output: hellouser@think:~/hem$ wc rsh.c 390 1047 7606 rsh.c hellouser@think:~/hem$ wc Shell.hlo 116 427 2929 Shell.hlo hellouser@think:~/hem$
Clearly, Hello Shell code is more than two times smaller than C rsh code. Obviously, some rsh code processes au-thentication and encryption while Shell code has no such functionality (although one can still tunnel Hello traffic through an SSL [22] proxy like stunnel [26]). However, even after deleting encryption and authentication from rsh.c , the word count still shows rsh code being signifi-cantly larger than Hello code: hellouser@think:~/hem$ wc rsh.c.clear 243 680 4724 rsh.c.clear hellouser@think:~/hem$ Language Features
A full description of the Hello programming language, its translator, the runtime engine, and a number of working code examples are free and available for download from [14]. Here is the condensed digest of the language features. The Hello distributed architecture had emerged from the practical experience of programming diverse distributed applications such as databases, cluster monitors, protocol discovery, email and video servers. Because of that, Hello design pursues the following two goals: The general-purpose distributed language should pro-vide superior productivity for developing a variety of efficient and reliable distributed software. A mainstream programmer should be able to adopt this language in a short amount of time.
Achieving these goals could facilitate the widespread transition from distributed tools, packages, and libraries to this distributed language.
Therefore, Hello combines the following unique properties, which set it apart from other distributed systems: The first such property is the ability to create objects, access their data, and invoke their methods anywhere on the network, using simple Java-like syntax and se-mantics, which is also reminiscent of the RPC [23]. 2)
The second property is the language-embedded distrib-uted architecture, whose elements directly represent the graph-structured underlying networking resources. These elements augment the single-host imperative language constructs, which represent the linearly struc-tured components of a von Neumann machine.
Hello sourcepack (package in source text)
Hello Translator
C++ sources
Hello runpack (shared binary library)
C++ Compiler
V1.0.3 (alpha) Conclusion September 12, 2014
Page 7 In addition, Hello offers abstractions for distributed operations such as queued asynchronous and synchro-nous requests for remote synchronization, first-class bulk operations like group traversals and intelligent, deep copy algorithms, as well as asynchronous queued event processing. Other Hello unique properties are safe data sharing in memory partitions and automatic transfer of packages across the network. Hello offers object-level security identi-fiers and privileges. It handles distributed failures via moni-toring state label transitions, catching exceptions, and timeouts. In addition, Hello translator parallelizes distribut-ed operations for runtime efficiency. Finally, Hello packag-es do not run inside a virtual machine. Hello translator con-verts them into shared binary libraries through the interme-diary C++ invocation; the C++ translator can harness the power of its optimizer to optimize generated C++ code. Hello translator allows for embedding into Hello programs any C++ code and linking with any C++ library. Hello programs are written inside object-oriented type hierarchies organized in packages. Hello translator trans-lates Hello programs into C++ programs and then calls a C++ compiler to compile the generated C++ code into a 64-bit binary dynamic shared library. Hello runtime engine dynamically loads the libraries and executes them; it also transfers the libraries on demand across the network. En-gines manage memory in partitions where the programs share runtime data. All this happens while executing con-current threads under control of the queues. A runtime en-gine belongs to a host – a named collection of engines run-ning on a single computer; any computer can run multiple hosts. Hello programs manipulate strongly typed primitive data, arrays, strings, and class instances (objects). Local opera-tions are performed on data from a thread stack, the engine heap and host partitions; remote operations are performed by navigating references to objects from other hosts. Meth-od arguments and return values are transferred to any host by reference or value following an intelligent, deep copy algorithm. Remote and local objects assemble in groups for automated traversals. Hosts connect and engines transfer data, code, and control flow across the network transparent-ly to the Hello programs. Hello programs can build neigh-bourhoods and paths of connected hosts and use them for better reliability, efficiency and security. Currently, Hello v1.0.3 (alpha) is available on 64-bit Centos [6], Fedora [10] and Ubuntu [27] versions of the Linux OS [19] on Intel x86_64 architecture [17]. Conclusion
In conclusion, we discover a historical precedent for the emergence of the widely adopted distributed programming languages by drawing an analogy with the development of FORTRAN [12], which was the first high-level program-ming language that had alleviated the difficulties of binary programming. In addition, we rationalize the need for a widely accepted distributed language by drawing parallels between the difficulties of distributed and assembler soft-ware development [11]. Finally, we uncover the deeper currents carrying on its waves the distributed programming from the past -- through today -- into the future.
Historical Precedent
On the highest level, most general-purpose program-ming languages, in the context of a single computer, ab-stract the fundamental elements of software programs. Ex-amples of these are code modules, data types, operations, and control flow. However, these languages do not provide first-class features for another significant programming component – automatic transfer of and access to code mod-ules, data types, runtime data, operations, and control flow across the network between collaborating computers. In-stead, they delegate such networking services to tools, li-braries and packages outside the language proper. In order to realize the importance of the first-class lan-guage features (i.e. those presented by language syntax and semantics), one should recall that programming languages serve as a bridge between a human understanding and the hardware realization of the algorithm. This bridge is ex-tremely valuable: it provides a much easier path for human beings to control computers via high-level algorithmic ab-stractions rather than via low-level processor instructions. Ultimately, it saves precious time and money while devel-oping software systems. For example, the first high-level programming language FORTRAN developed in 1954--1957 at IBM [1], enjoyed tremendous success because it was able to express algo-rithms with the imperative control flow primitives, and centuries tested mathematical notation [15]. The language had freed programmers from the daunting burden of pro-gramming machine codes and auto-codes. The FORTRAN translator was able to translate program sources, check for programming errors, and compile efficient binaries from the program libraries without human intervention. At the same time, programmers, empowered with FORTRAN, were able to devote more time to solving application problems, in-stead of coding binary programs. After FORTRAN invention, a plethora of programming languages had evolved [20]. However, despite immense richness of purposes and features, most of them share a single property inherited from the first language – they provide a bridge to only a single computer. Although many traditional languages allow for developing distributed appli-cations, they still delegate network operations to extraneous tools, libraries and packages. This is simply because the
V1.0.3 (alpha) Appendix – Remote Shell Source September 12, 2014
Page 8 languages lack the features to communicate over the net-work. However, such extraneous software is complicated to use since its interface, being rich in complex low-level details, exposes the rigidity of the networking protocol to the application level. As a result, the quality of networking applications suffers because developers must spend signifi-cant efforts at a low-level coding in order to adhere to the subtleties of the networking interfaces. While the language itself has little or no knowledge of the networking opera-tions, it is hard for a language translator to optimize net-work access; this, in turn, results in reduced efficiency and higher traffic of the networking applications. As in 1950-s, today software engineers still lack an es-sential tool to address an exceptionally hard problem. While back then such problem was the low-level binary coding for a single computer, the today’s problem is the low-level networking coding for distributed applications. Therefore, as the programming language FORTRAN solved the former problem more than half a century ago by providing first-class features to simplify single-host programming, another programming language might also solve the latter problem today. The solution could provide in the language the first-class features to simplify multi-host networking operations.
Technical Parallels
Anyone who had experienced binary or assembler pro-gramming and, in addition, had been involved in a distribut-ed software project, can think of the binary coding problems facing programmers of early 1950’s being quite similar to the networking coding problems of today. The following list enumerates the exact parallels: 1)
A well-defined central processing element : a CPU ver-sus a server on the network; 2)
A program that needs service from the central element : an assembler, auto-code or binary program in memory, executing CPU instructions versus a client program on the network, submitting server requests; 3)
A hard to use interface : assembler language, auto-code or binary code versus networking interface; 4)
A pattern of failure : crash of CPU or server usually causes termination of assembler or client program; 5)
Programming, debugging, and optimization : in both cases, techniques are manual and complicated [11], [28]. Obviously, it should be of no surprise that a similar solu-tion could solve a similar problem. In other words, a dis-tributed programming language might improve networking programming today the same way FORTRAN had im-proved binary coding more than half a century ago.
Connecting Past and Future
During millennia-long mathematical development [16] and centuries-long technological progress [7], human beings performed calculations individually. When needed, they used to carry out computational and mathematical interac-tions through inter-personal collaboration, education, writ-ten correspondence, manuscripts, books and magazines. It is only recently, after the invention of the computer networks some 50 years ago [8], the automated distributed computa-tions had become possible. Therefore, it is not surprising that the area of distributed programming is less mature than the field of single-host programming, which takes its roots in the individual computational techniques evolved through thousands of years. One might speculate that it might take more centuries for human civilization to develop (yet unknown) automated paradigm for distributed computations. However, it appears that the movement towards that goal can be started today. Its first step should abandon a hodgepodge of single-host languages and distributed tools in favour of widely accepted general-purpose distributed programming languages.
Appendix – Remote Shell Source
10 // each source must begin with 11 // the package directive 12 package Shell_World; 13 14 // this class is declared external because 15 // its instances can be created on a remote host 16 // and also because once created they can 17 // be accessed from a remote host 18 external class Shell 19 { 20 // this is constructor of Shell class 21 external public Shell() {} 22 23 // entry point to the program -- must 24 // be called main; accepts command line 25 // arguments as an array of strings 26 static public int main(char [][]argv) 27 { 28 // built-in method sizear() returns 29 // the number of elements in an array 30 int argc = sizear(argv, 1); 31 32 // quit program if not enough arguments 33 if ( argc <= 1 ) 34 return 0; 35 36 // first argument must be a host 37 // name were to execute command 38 // specified on the Shell command line; 39 // the built-in method hello() returns a 40 // reference (ref for short) to a host on 41 // the network with the given name 42 host hst = hello(argv[0]); 43 44 // if host not found then quit 45 if ( hst == null ) { 46
V1.0.3 (alpha) Appendix – Remote Shell Source September 12, 2014
Page 9
64 } 65 66 // this defines the size of a buffer for data 67 // to be transferred from the stdout of the 68 // command executed on the remote host to 69 // the local host -- this data will be printed 70 // on stdout of the program main() running on 71 // the local host 72 enum { BUFSIZE = 1024 * 1024 * 4 } 73 74 // this method executes on the remote host: 75 // it accepts command and its parameters 76 // in the character array [][]argv, and a ref to 77 // the remote host 'back' -- the host from where 78 // remote Shell command has been started 79 public external void run(copy char [][]argv, 80 host back) { 81 82 // get the count of arguments 83 int argc = sizear(argv, 1); 84 85 // -the first argument is the name 86 // of this remote host; 87 // -the second argument 88 // specifies how many buffers to fill in 89 // with the stdout data in parallel: 90 // this argument is for experimentation, 91 // just to see how the speed of data 92 // transfer depends on the amount of 93 // buffers being filled in parallel 94 // -the third argument is the remote 95 // command name 96 // -the rest are the arguments for 97 // the remote command 98 // 99 // If no command is specified then quit 100 if ( argc <= 2 || back == null ) 101 return; 102 103 // set the count of buffers from 104 // command line 105 int BUFCNT; 106 char []bc = argv[1]; 107
V1.0.3 (alpha) Appendix – Remote Shell Source September 12, 2014
Page 10
262 else 263 rtq
References [1]
Andrew P. Black, Norman C. Hutchinson, Eric Jul, Henry M. Levy, “The development of the Emerald programming language”, HOPL III Proceedings of the third ACM SIGPLAN conference on History of programming languages, 2007. [3]
C (programming language), http://en.wikipedia.org/wiki/C_(programming_language). [5]
C++, http://en.wikipedia.org/wiki/C++. [6]
Computer network (History), http://en.wikipedia.org/wiki/Computer_network
Erlang (programming language), https://en.wikipedia.org/wiki/Erlang_(programming_language). [10]
Fedora, https://fedoraproject.org/. [11]
FORTRAN, http://en.wikipedia.org/wiki/FORTRAN. [13]
Getting Started Using Java RMI, http://docs.oracle.com/javase/1.5.0/docs/guide/rmi/hello/hello-world.html. [14]
History of mathematical notation, http://en.wikipedia.org/wiki/History_of_mathematical_notation. [16]
History of Mathematics, http://en.wikipedia.org/wiki/History_of_mathematics. [17]
Leo A. Meyerovich, Ariel S. Rabkin, “Empirical Analysis of Pro-gramming Language Adoption”, ACM SIGPLAN NOTICES – OOPSLA 2013, V. 48-10, 2013. [21]
John von Neumann, “First Draft of a Report on the EDVAC”, 1945, http://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC. [22]
Remote Procedure Call, https://en.wikipedia.org/wiki/Remote_procedure_call. [24]