4 ms·
* Checking some condition before building something in a particular way. * Retrying something if it fails. * A hundred other different scenarios which crop up
by crdoconnor 9y ago
* Checking some condition before building something in a particular way.
* Retrying something if it fails.
* A hundred other different scenarios which crop up occasionally, require about 4 lines of turing complete code, and are an absolute bitch to handle in a language deliberately designed not to make it possible.
- Someone 9y agoAbility to do if…else doesn’t imply being Turing complete. Neither does the ability to retry operations. An easy way to see that is that “Turing complete” implies “can be used to simulate any Turing machine”, which in turn implies “suffers from the halting problem”. Consequently, any language that doesn’t suffer from the halting problem cannot be Turing complete. So, for example, any language that doesn’t allow backwards jumps, or only uses loops with numbers of iterations that are provably finite at compile time isn’t Turing complete.
- crdoconnor 9y agoIt actually does imply turing completeness, it just doesn't guarantee it. I know of no build language that builds in the ability to do conditionals and loops that isn't turing complete. At that point... why bother? Why not just use a good turing complete language and give it some libraries that make building software easier? There's a lot of times and places where removing turing completeness makes complete sense - configuration, user stories, translation files and simple DSLs that operate in a very restricted problem space, etc. Building software isn't a restricted problem space.
- Someone 9y agoBecause those complete languages are Turing complete. That means, for example, that the build system cannot guarantee that a build will finish, even ignoring that individual steps may run forever. Some argue Dtrace’s scripting language and PDF (and, IIRC, various packet filter languages) are popular because they aren’t Turing complete.
- crdoconnor 9y ago>That means, for example, that the build system cannot guarantee that a build will finish That's impossible anyway because one of the plugins or the core build code may never halt. Abandoning turing completeness shouldn't be about that anyway. It should be done because it's demonstrably not needed to solve a problem.