New Dataflow Programming Language
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,
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
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
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.
[Minor edits for clarification and to correct some mistakes]
Active forum topics
New forum topics