4 ms·
Yes, I have personally designed several guaranteed-to-halt DSLs for the exact reason that allowing Turing completeness where it's not needed is a bad idea. If y
by Grue3 8y ago
Yes, I have personally designed several guaranteed-to-halt DSLs for the exact reason that allowing Turing completeness where it's not needed is a bad idea. If you have a scripting language in another software, you don't want to allow the scripts to go into indefinite loops, that's just bad UI. You can't guarantee the user will write bug free code that halts.
One of my non-Turing complete languages is Animstack [1]. It's a script within GIMP image editing software. Imagine accidentally creating an infinite loop while you're working on an image and having your image editor freeze forever. Well, you can't create an infinite loop in Animstack. It's guaranteed to finish in linear time (of the number of layers). That's intentional and I was careful to preserve this guarantee.
[1] http://tshatrov.github.io/animstack.html http://tshatrov.github.io/animstack.html
- dahart 8y agoYour project looks really cool, but I’m unconvinced by your take on Turing completeness. It’s a mistake to conflate UI with computability, and a mistake to confuse computability with the ability to make programming mistakes or to write bugs. The academic idea of the halting problem is not to make good UI or save people from themselves or from bugs, it’s just a theoretical math problem, and it doesn’t mean anything useful in practice. You can write an infinite loop in C, and still hit Ctrl-C to kill it. You can screw up JavaScript and still close the tab. Turing completeness is not a problem in practice. If GIMP’s scripting or plugin environment doesn’t support killing a runaway script, then the bad UI is GIMP, not Turing completeness. Plus, lack of Turing completeness is no guarantee that a script will be fast and that it won’t be bad UI. The halting guarantee is not a user guarantee on responsiveness or on run time at all. Lack of Turing completeness might, on the other hand, severely limit real functionality, it might keep users of your language from being able to do cool things. You’re taking at least some kinds of higher level function composition off the table. Anyway, that said, I will try to check out your project, I’m a big fan of image generation DSLs (having written a couple myself for CG film production) as well as compositing and animation projects.
- Grue3 8y agoI'm not convinced that Turing completeness is needed for real functionality. Can you name a "practical" function that is computable but not primitive recursive? Just because you can theoretically compute Ackermann function doesn't mean it has anything but academic interest.
- dahart 8y agoAre you kidding? All you need for TC is conditional repetition, you don't need recursion. Loops & variables are the two things that make a language Turing complete. Almost everything interesting in the computing world is done using conditional loops. To use your Animstack project as an example, you're not allowing your users to write things like Perlin turbulence (multiple octaves of noise) without a loop, or custom convolutions, or a Mandelbrot fractal, or 2d fluid flow. There are all kinds of practical and fun things you're artificially restricting yourself from. Some of those things can be technically done without TC, but none typically are because it's inconvenient, and because TC doesn't cause any practical problems. Other examples that use Turing completeness in practice: UI event loops (all videogames, all of robotics, all servers of any kind), string replacement, sorting a list of arbitrary size, searching a list of arbitrary size, path tracing renderers, file i/o, regression and any non-linear optimization, I could go on for a very long time, the list is really long. I'd like to know what interesting things you think you can do without conditional loops in a convenient way. Not what's theoretically possible if you bend over backwards, but what's practical and easy. I feel like the list is pretty short. You also didn't answer the question. What is a real problem with TC? Killing runaway programs & infinite loops is not a problem in practice, and therefore neither is preventing people from writing infinite loops. So what's a problem with TC that I should care about? You can never guarantee people won't make mistakes, unless you make all their decisions for them. That's what non-TC languages normally feel like; a recipe book for pre-decided outcomes, not very powerful, not very interesting. Nor did you address the fact that a decidable non-TC language doesn't guarantee halting in any reasonable amount of time. So how is it actually helping you to prevent TC? It doesn't seem like it is. Here's a question- how many conditional loops did you use in the implementation of Animstack, under the hood?