It feels like there are two distinct programming languages that PL designers habitually mix into one.
Calculating language. It's code lives inside box with explicitly specified inputs and outputs. There is no IO, nor time inside the box.
Program might be executed lazily or eagerly. Instructions might be executed sequentially, or may remind some kind of graph, in which exact path of execution is not clear. The main thing is that there are inputs and expected outputs. Reminds code in Prolog or Haskell.Managing language. It's code runs inside loop-ring, instructions always executed eagerly and sequentially. Unlike boxes, there is a time inside ring, and it flows into one direction.
Programs written in this language do all IO: receive data, process it using boxes from the first language, save state, send data outside. This language also describes components of the system and their dependencies.
Reminds Erlang with it's receive-after-end and send. Reminds supervisor config, kubernetes service config.
If we split these languages yet use them together, it may lead to something interesting. It may produce more powerful abstractions specific for tasks of each language. It may lead to something more convenient, more effective in terms of computer-human interface.
Top comments (7)
Those are called Programming paradigms:
So your guess is that both paradigms can be implemented in programming language ?
I would say you are looking for is a language that is Turing complete language that provides undeterministic state. So the column in the middle
But in fact, it seems to be that some of the modern PL are multi-paradigms trying to implement many of them in some degree.
By the way: The language that is more multi-paradigm seems to be Wolfram Language
It's not really about paradigm. You can write in Calculating Language in any paradigm: imperative, logic or functional. As long as resulting function can be used as pure by Managing Language.
The main point is to divide IO and pure calculations into two distinct worlds, different languages.
Mixing many paradigms into one language is completely different approach, it makes things complicated.
I see... You mean purpose, a DSL language specially designed for each of those two purposes that you want to define.
I still prefer to have just one multi-paradigm language, with frameworks or libraries for each purpose.
Note that, while you are trying to define "languages" you are specifying responsibilities. That's what one do when dividing the complexity of the system (given by its requirements) into components.
Object Oriented Programming and other paradigms make profit of the fact that the complexity can be divided in simpler components until a level that a programmer or team can better understand and manage.
Nevertheless, the complexity of system can be divided but never avoid it. The complexity is moved to the relationship between the components.
That means, that you can have languages such specific like DSLs, but at the end you'll need a technology / language to bind them.
That's why I prefer having a super language with frameworks or libraries to many specific ones. Even more, when the paradigm is constantly evolving.
It is not only to have a language to implement the paradigms, we need it also for the glue that connects them.
Nevertheless, I guess that when frameworks are mature enough they might profit to have a DSL language representation. They would play the role of standarization with other companies.
There must be a clear interface between those DSLs, yes.
If we create these DSLs inside super language, then there is a great
temptation of changing this inter-language interface. It also ties code to a single platform (a super language).
I would prefer to have clear interface that can be used on many platforms. Interface that is not changed easily, so people don't have to afraid that it's gonna break. Similar to C FFI that is used in many PL for library interfacing.
That's why I don't like this idea of super language.
Anyway, you might want to check Scala's DSL features.
Clarification: I don't propose to make Calculating Language multi-paradigm. I propose to have several different Calculating Languages each in their paradigm, used for different problems.
Imagine that you create a video game. You have some AI rules written in prolog-like language (a Calculating Language) and the other part that does efficient imperative math calculations for your graphics (also a Calculating Language). And finally code that manages all IO: user input, video output (a Managing Language).
So you have three languages in a single program. Each compiled and optimized separately.
This of course requires clear specification of FFI between calculating and managing languages.