>Why this effort to make a language in which many programs can’t be written? Because TC is intimately tied to Godel’s incompleteness theorems & Rice’s theorem, allowing TC means that one is forfeiting all sorts of provability properties: in a non-TC language, one may be able to easily prove all sorts of useful things to know; for example, that programs terminate
Non-turing complete languages are also easier to reason about, less susceptible to bugs and less susceptible to technical debt.
For this reason minimizing as much as possible the amount of turing complete code you write will make your code cleaner.
Configuration and tests in particular are usually best described in a non-turing complete language.
Technically speaking, for each program in a TC language we can have a program in a coinductive total language with the same observable behavior.
In nutshell to those who may not be familiar with the field: total languages differ from partial TC languages in that they must always include internally a "hit the reset button" exit from potential infinite loops, and this is enforced by the type system.
Since we can't actually observe an infinite number of program steps even in TC languages, this makes total languages effectively just as powerful as TC ones, but total languages are better-behaved in the sense that we can make a statically enforced distinction between provably terminating and possibly nonterminating code, therefore having all optimization/reasoning benefits in total parts, but also infinite processes in coindutive parts.
Well, I shrug to think about how people would create a program that runs for an indeterminate time (that's most useful ones) in a coinductive total language. Yes, in practice it must be possible.
Then, total languages are just a subset of the non TC languages, and those are as prone to accumulating technical debit as TC languages. For avoiding technical debit, one needs something much less expressive.
At least in terms of configuration management, what you usually end up with have is a complex config generated by something that is Turing complete.
Better to start out and keep the core configuration representation simple (e.g. json, protobuf, ini file) and generated by something powerful like Flabbergast.org.
> Non-turing complete languages are also easier to reason about, less susceptible to bugs and less susceptible to technical debt.
Citation needed. Not my experience at all. Some well-designed total functional languages perhaps, but not non-turing complete languages in general, and not the typical alternatives for configuration and tests.
Non-turing complete languages are also easier to reason about, less susceptible to bugs and less susceptible to technical debt.
For this reason minimizing as much as possible the amount of turing complete code you write will make your code cleaner.
Configuration and tests in particular are usually best described in a non-turing complete language.