Lambda the Ultimate

I am now convinced that a new programming language is needed in order to get the most benefit from the data-flow programming model.

Until a reasonably good uncluttered dataflow language implementation exists, then no-one is going to be convinced to jump on board. Implementations based-on control-flow/imperitive languages and written as libraries require that programmers write dataflow programs in an entirely non-intuitive way, which negates many of the benefits of the new way of thinking & working.

I believe that a new language could have enormous benefits that are currently difficultto imagine in control-flow ways of thinking - e.g. parallel/distributed processing for free, fault tolerance for free, IO almost free, exception handling almost free, authentication/security for free, and a the massive reduction in application code that would result from freeing the programmer to have to code this functionality.

I am thinking about starting work on the design of new language - is there anyone here interested in this idea?

Some of my ideas about the language features include:

1. The language would be modular, e.g. a dataflow "network" could be "encapsulated" into a "module", which could then be used as a module/process in other dataflow networks. Such modules could also alternatively contain traditional control-flow code,
for those cases where that is the best way to implement the function/algorithm. Modularisation would mean that the language could implement both coarse-grained & fine-grained dataflow networks.

2. The language would be object-oriented, but not in the usual way as a syntactic source-code device. Objects would be the primary (only?) data flowing along the pipes between modules/processes, and the dedicated hidden executable code associated with
those objects would delivered transparently along the pipe with the data. this would allow (e.g.) a truly generic sort module to be written that could work with any data/object type without knowing anything about it.

3. A type system that defines higher-level types (e.g. time, hours, seconds, kilometers, mile, etc), which would also be extensible. It would also implement higher-level basic data types that are no longer dependent upon the underlying architecture of the CPU (e.g. the most important example of which would be a "number" type that is unlimited in size, and can contain unlimited amounts of decimal precision). This would enable us to get away from the endless problems caused by tying number types too closely to underlying hardware implementations of 32-bit vs 64-bit versions of integer vs floating-point types. I'm still thinking this through, but have decided to go for strong typing.

4. An extensible pipe type system which defines characteristics of a pipe, e.g. priority, push vs pull, serial vs parallel, ordered vs unordered. Pipe type definitions would alllow the dataflow runtime engine to make sensible decisions automatically about the behaviour of the pipes & processes/modules. One example of such a decision would be whether all the objects in a data stream can be processed in parallel or whether they must be processed one-at-a-time in sequence. Another example would be to define pipes to be "time-critical" which would allow the dataflow language to be used in real-time applications, audio/video applications, device drivers, etc.

5. A text-based syntax, that translates unambiguously into a diagrammatic form, so that programming can be done either "visually" in diagrammtical form or traditionally using text editors. The new syntax would get rid of the "clutter" that comes with dataflow implemenations based on control-flow/imperitive languages. The language would need to have syntaxes
for: a) dataflow network definition, b) data object definition, c) pipe definition, and d) a minimal control flow language that would probably look similar to Pascal/Modula2.

A new dataflow programming language, if it was as successful as I hope, might also have the benefit of killing off C and its horde of mutant offspring, which I sincerely believe have held back the progress of software engineering for the last 20 years.

If you find any of this interesting, please feel to contact me to discuss it in more detail.

Although I have been reading as much as I can find, I am still relatively new to idea of programming language design, and would welcome references to existing work. I have no interest in re-inventing any wheels just for the fun of it.

Regards,
Mark Taylor.

[Minor edits for clarification and to correct some mistakes]

in the department of yet-another-take-on-reining-in-concurrency-for-mere-mortals, the FunLoft programming language ("Functional Language over Fair Threads") from those braininacs at inria:

FunLoft is an experimental language for concurrent programming, designed with the following objectives:

* make concurrent programming simpler by providing a framework with a clear and sound semantics.
* provide a safe language, in which, for example, data-races are impossible.
* control the use of resources (CPU and memory); for example, memory leaks cannot occur in FunLoft programs, which always react in finite time.
* have an efficient implementation which can deal with large numbers of concurrent components.
* benefit from the real parallelism offered by multicore machines.

FunLoft is safe. In particular, a static analysis ensures that programs are free from data-races and from memory leaks. More specifically, there always exists a bound on the memory used by any program: if the available memory is larger than the bound, no out-of-memory error can occur. The system does not compute the actual value of the bound, but only test for its existence.