Lambda the Ultimate

Hi, I'd like to announce our paper "SuperGlue: Component Programming with Object-Oriented Signals," which will be presented at ECOOP next month. Its related to functional-reactive programming with a more declarative and object-oriented way of manipulating signals.

Abstract:

Abstract. The assembly of components that can handle continuously changing data results in programs that are more interactive. Unfortunately, the code that glues together such components is often difficult to write because it is exposed to many complicated event-handling details. This paper introduces the SuperGlue language where components are assembled by connecting their signals, which declaratively represent state as time-varying values. To support the construction of interactive programs that require an unbounded number of signal connections, signals in SuperGlue are scaled with object-oriented abstractions. With Super-Glue’s combination of signals and objects, programmers can build large interactive programs with substantially less glue code when compared to conventional approaches. For example, the SuperGlue implementation of an email client is around half the size of an equivalent Java implementation.

Paper available here here.

Memory allocations and deallocations, threads, locking, execution control (such as loops, function calls, conditionals), etc... these are are machine specific features. Why do we not have a high level language that goes beyond these things? ALL current languages are low level even if the programming community tries to say otherwise. Handling hardware is low level.

Why do languages even touch execution which is a technique used to get around current hardware limitations? What will happen when processors can execute seemingly infinite instructions at the exact same time? Execution control will no longer exist. More to the point, mixing execution control and data manipulation all in the same statement is a hard coded custom solution. You cannot reuse components that have been welded together in this fashion. Why do languages still use this archaic form of programming that can never lead to reuse?

There is a solution, but I'm just curious why the lack of will to move forward. Haven't you ever thought it strange that you can only have unidirectional control statements within functions? Why the skew? Have you not ever noticed that sending messages between computers doesn't work well in an RPC fashion because the other machine is not required to respond? So don't you think that perhaps there might be something wrong with the entire concept of functions and procedures in programming languages? Is not the difficulty of having multiple returns values a sign that something is seriously wrong?

So my main question is: Why are ALL programming languages so low level and more generally obsolete for general purpose use when all the signs are impossible to avoid? Why the refusal from language designers to move forward? Can they really not see the solution?