>I've heard it said that every language is 'doomed' to creep towards being turing complete.

Usually that happens for DSLs for tools which probably should have just been ordinary libraries in existing languages (e.g. ant).

It's often tricky knowing where architecturally to draw the line between turing completeness and non-turing completeness and the technology landscape is littered with examples of tools which put it in the wrong place and later tried to hack around it.

Turing completeness where it isn't necessary IMHO isn't really a problem because of the halting problem per se - it's a problem because turing complete code has a higher maintenance cost at the best of times and attracts a ton of technical debt at the worst.

Old school frameworkless PHP was the clearest example of this IMHO - the lack of a clear separation between business (should be TC) logic and presentation logic (should be low powered templating language) caused messes all over the place.

It's also tricky because it's so easy to make a Turing complete system by accident. You may not even realize that you've crossed that line.

It really shouldn't be hard to tell for the designer. If you're considering implementing loops, conditionals or variables in your DSL then you should kind of realize what direction you're headed in.

The hard part is realizing from the get go (before backwards compatibility concerns kick in), that your problem space is not conducive to non-turing complete languages in the first place, and that instead of inventing an exciting new DSL, maybe you should just write a library.

When CSS+HTML5 became Turing complete, do you think the designers knew it?

Or the designers of page fault handling in X86?

As I understand it, C++ templates were not supposed to be Turing complete, but they are.

These examples and more come from http://beza1e1.tuxen.de/articles/accidentally_turing_complet... .