3 ms·
> My current take on this. The "business logic" should not be written in Turing complete languages, I think this is an excellent point. I've been coming to th
by Lio 6y ago
> My current take on this. The "business logic" should not be written in Turing complete languages,
I think this is an excellent point. I've been coming to this same conclusion for some time.
For a lot of use cases a less powerful but more predictable language is probably what we need. State machines and DSLs go some way towards this but I don't think that's the full solution either.
Maybe something based on a restricted APL language, either way it sounds like a good PHD project to me.
- bantunes 6y agoThis might interest you https://alan-lang.org/alan_overview.html#parallel-computation-and-the-problem-of-turing-completeness https://alan-lang.org/alan_overview.html#parallel-computatio...
- freeqaz 6y agoGoing to give this a deep dive. Thank you. Super curious how it works after reading the intro page!
- Martinsos 6y agoI also believe in this as a promising direction! Specifically I have been trying to apply it to full-stack web app development for some time now by building a DSL (https://github.com/wasp-lang/wasp https://github.com/wasp-lang/wasp). Why do you think DSLs are not the full solution? My main thought was that having DSLs for specific areas of programming domains is the way to go. But they should have interop with Turing complete languages to implement specific sub-parts. That way DSLs can capture a lot of knowledge and best practices that we learned through years in that domain while still facilitating innovation being flexible. Such language would be very limited, more like "smart configuration languages". Some of them I have seen around are Terraform, Nextflow, Meson-build. APL still sounds too general and self-sufficient to me to be a solution to this (but I don't know much about it so maybe I am wrong, I just checked it out on the wikipedia).