4 ms·
I would argue similarly, we need more languages like Dhaal or SQL or systemd, which are explicitly not Turing-complete. Most of the so-called "business logic"
by js8 4y ago
I would argue similarly, we need more languages like Dhaal or SQL or systemd, which are explicitly not Turing-complete.
Most of the so-called "business logic" can be written in non-TC language.
Lately, I was thinking about about a kind of pentagon of things:
(1) Algorithms are primitives of data transformation, and they are written/debugged in TC languages.
(2) Data transformations (like ETL process or DB transaction) are written in non-TC language (like SQL), are composable, and use algorithms (1) as primitives.
(3) Platforms are primitives of execution resources, things like databases, application servers, client UI loops, etc. These are also implemented in TC languages.
(4) Computational resources (like I have this many application servers of this type that provide this much CPU and this much memory) are written in non-TC language that doesn't compose in terms of functions, but in terms of resource additivity. In other words, these languages can describe global constraints on platforms (3). Something like systemd comes to mind, but perhaps more expressive.
(5) Then there is a system-description language (composable but not TC) which marries the data transformations (2) and computational resources (4). It does say how data move through the system, and where each transformation gets executed. However, this language is not concerned with how each transformation gets executed (that's the job of (2) and (1)) nor with at which exactly piece of infrastructure they get executed on (that's the job of (4) and (3)).
The goal would be then to take language descriptions (5),(2) and (4) and compile it in terms of (1) and (3), i.e. what actual algorithms are executing on which actual platforms. (Hence the pentagon with nodes (1)-(2)-(5)-(4)-(3).)
- FridgeSeal 4y ago> we need more languages like Dhaal or SQL or systemd, which are explicitly not Turing-complete. Agreed 100%. First time I used Dhall a similar thought crossed my mind about it being an ideal specification language for most ETL pipelines and similar “business logic” work. I feel like Spark was (in intent) an initial foray into this kind of solution with the data frames and SQL interface, but it falls short in number of ways and is way too attached to a single implementation (warts and all). The idea of a “resource descriptor language” (4) is a very cool concept, and not one I’d thought of before. Would this be granular compute resources (x % of CPU and memory, a la Kubernetes resource limits) or more like terraform? Maybe I’m misunderstanding, but isn’t (5) less of a language, and more some kind of constraint-solver based on (2) and (4). That is, it attempts to find the “layout” and allocation of resources for the requirements (optimise for minimum hardware, optimise for maximum throughput, etc). Again, this could be me misunderstanding this stage though.
- js8 4y agoIt was just a quick, rather undeveloped idea. Regarding (2), I think categorical database schemas might be an answer. But it still pretty much theoretical. I am not really sure about (4). I think it would be a mix of both, although the actual Terraform operations would be treated as primitives. I think (5) doesn't have to be a constraint solver, it might be just a language where you marry the resources (and the way they scale, also described in (4)) with the actual computation, even if it was all explicitly specified. (Constraint solving it is another level.) Basically, (5) describes the final architecture of the system, while (2) specifies what needs to be computed and (4) specifies what resources are available to do any computation.
- adrianN 4y agoSQL is Turing complete thanks to recursive common table expressions.