Mark Taylor's Web Pages
Mark Taylor's Web Pages > New Programming Language

New Programming Language

I am working in the design of a new programming language (as yet not named).

It is based on the concept of Unix style pipes.  Software components are connected together by pipes into a network (in the form of a directed acyclic graph) along which flow streams of data objects, which are processed by the components.  The components consist of either another network or a component written in a procedural language.  There will be a procedural language "built-in" (which will probably look like Pascal or Modula-2),  but a language API will enable components to be written in a variety of other standard languages (e.g. SQL, or even C if you insist).

It is hoped that the language will be general purpose - it will be possible to write everything from device drivers, to web-based components/applications, to compilers, and that it will eventually be able to compile itself.

The language will be both text-based and graphical/visual - i.e. there will be a direct, one-to-one unambiguous correspondence between the graphical and text forms.

The runtime system that drives the network will provide automatically (i.e. transparently or implicitly):

a) Parallelism of execution.  Pipes/streams will be defined with attributes that will describe whether the data is unordered, sorted, synchronous, asynchronous, real-time, time-coded, etc.  This will enable the run-time system to safely process the data objects in parallel, transparently.  For example, if a data stream is described as ordered, then following processing in parallel (where the original order might be disturbed), the run-time system will restore the order by a transparent sort/merge.  If a data stream is described as synchronous, then parallel processing will be limited.  If a data stream is described as real-time, then it will be given higher priority over other data streams in the network.  If a data stream is described as time-coded, then those parts of the stream that arrived late or could not be processed "in time", would be dropped.

b) Fault-tolerance. The default behaviour will be that if a component fails, it will be restarted with the next data object in the input stream, and only the failed data object would be lost from the output stream, and the remainder of the stream would be processed correctly (unlike current programming languages where typically failure is more catastrophic).

c) IO between components, and also to/from the storage repositories in the "outisde world" (e.g. databases, files, other "external" components) via library components.  The internal application program components will not know or care where the data objects originate from or go to.  Streamed data objects will transparently adhere to a standard "self-describing" format that will be understood by any program in the language (think XML but definitely not XML).

The language will include a data definition language that will enable:

a) data object definitions to be much simplified and improved, compared to existing OOP languages - e.g. no inheritance, no operator or function overloading.

b) a static, strict type system that provides most of the benefits of a dynamic type system.

c) a new data type system that both simplifies data type definitions and makes them more powerful.

An example of data type improvements include: a single number type that is limited only by the available storage.  That, is no separate integer/float and the attendant conversion problems - (think Bigint).

The data object type system, procedural language and standardised streamed object format will allow the design of components that have little or no knowledge of the data they are processing, and hence will enable genuine "black box" or component-based software construction.

If you would like to help or discuss these ideas further,  or if you would like to offer criticism or advice, please feel free to contact me.

This outline is not yet finished.

Mark Taylor.
26th April 2011.