![]() The JavaScript ecosystem would not have grown without garbage collection. Photoshop could hardly have been built on the basis of GOTO. ![]() Unix was possible because of the C compiler. While not all application domains benefit from all the replacement steps above, it appears as if removing some expressive power can often enable a new kind of programming, even a new kind of application altogether. Nowadays programming in React is much better with immutability. Functional programming afficionados removed side-effects and mutability in favor of pure functions and persistent data structures.OOP involved moving from arbitrary access to information hiding modularization.Manual memory management is still around in certain areas, but garbage collection made memory safety so popular that now we have borrow checkers to write memory safe code even if we can't afford the garbage collector overhead.The infamous GOTO was banished in favor of structured programming.Direct access to CPU registers and instructions gave way to higher level compilers in the ALGOL tradition.Direct entry of binary code became assembly language.Hence the history of programming language design has been a history of removing powers which were considered harmful and replacing them with tamer, more manageable and automated constructs. Which is why garbage collectors are so popular these days. Either way, nobody sets out to write segfaulting code - and yet we inevitably do so long as the language allows it. We may also encounter the opposite problem: We are faced with a complex code base that does something and we are tasked with changing it, without understanding what it really does. These discrepancies are called bugs and I'm here to get rid of them. Unfortunately human thinking is much less pedantic and we write programs which don't do what we think they should. Ceding power to gain controlĬomputers do exactly what we tell them to do. This post is an adaption of a paper and talk I gave at HATRA 2020, a workshop during the SPLASH 2020 conference. ![]() In service of more widespread adoption we shall go through some very simple dos and don'ts for Turing incomplete languages which hopefully will inspire you to build your own! While the path to getting there is not completely clear, Turing incompleteness is both promising and easy enough to warrant much more intense investigation and experimentation than we currently have. safer interaction of untrusted components.tractable automatic code generation from specification.cryptocurrency "smart contracts" less full of money-losing surprises.distriuted computing with provably less bugs.predictable "serverless" cloud functions.The goal is to leverage Turing incompleteness for: I will also tell you that Turing incompleteness is very promising to drive a true leap forward in the art of software engineering, on par with the likes of garbage collection or structured programming. Well, I have come to tell you that these matters aren't quite the way they seem: Turing incomplete languages can in fact be powerful enough to support pretty much any programming task you or I or any web developer, or data scientist, or devops engineer would be faced with today. Well - you maybe heard that SQL was Turing incomplete but not thought much of it. If you grew up like me, you probably came to believe that Turing completeness was necessary to build any serious programs and that Turing incomplete languages were either toys, parsing tools or config files. As we software engineers grow up, we are taught early on (like in kindergarten) to associate Turing (equivalent) machines with computation per se: It's the paradigm that the vast majority of programming languages aspire to and that many more which don't aspire to fall into accidentally.
0 Comments
Leave a Reply. |