From: Chad Perrin Date: 2006-08-09T03:16:52+09:00 Subject: Re: Language chatter On Wed, Aug 09, 2006 at 03:00:51AM +0900, Francis Cianfrocca wrote: > > What I was reaching for was some insight into why full-powered > (Turing-complete) computer languages are so difficult to write automated > tools and workbenches for. The challenge is not how humans can reason > about programs (undecidability is not a big hurdle for us), but how > programs can reason about programs. And my (unproved) intuition is that > mathematically restricted DSLs (whether they are Lisp programs, Ruby > programs, graphical widgets, physical constructions, or any other such > equivalent thing) may be so much easier to tool that they can give a > vast productivity improvement. > > Low-grade example: I've been working on a component-based > web-development framework in Ruby, and most of it is DSL-driven. So far, > it's been remarkably easy to build graphical tools for it. I think object-oriented programming is just a very limited form of what we're really trying to accomplish when we do things correctly: componentized abstraction. It's easiest to solve complex problems when we create abstractions for dealing with them, and abstractions themselves are often complex problems. Thus, we build abstractions with which to build abstractions, edging closer to the actual solution to the problem. In practice, this pretty much boils down to creating a language within one's language -- a task to which Lisp is particularly suited, and to which Ruby's design devotes significant attention as well. A language like Ruby allows rather more to be done without having to create such abstractions than a "pure" Lisp, however, which makes it a lot more approachable, and it may thus be a better compromise for the programming of our time for most problems we're attempting to solve by programming. Abstractions are like levers: you use a longer lever to move a bigger problem. Something like Lisp is an incredibly efficient lever-creator. That's my take, at any rate. The way this relates to Turing completeness is in the fact that when creating abstractions specific to your problem, you don't need Turing completeness. Trying to implement it within your abstraction is a waste of time. Turing completeness might, however, be more important for the overarching framework within which you are creating these DSLs that are your abstractions. An important distinction should be made, as well, between Turing completeness and Turing equivalency. A "pure" Lisp, for instance, can be used to create a Turing complete language, but isn't precisely a Turing complete language itself. Similarly, a "pure" Turing machine can be used to create a Lisp-complete language, but isn't precisely a Lisp itself. Thus, Lisp is Turing equivalent, and a Turing machine is Lisp equivalent, but neither is "complete" within the realm of othe other. Without being a computer science PhD that knows all, I flatter myself to think I understand the relationship between the two: each is just a different way of approaching the same problem. The Turing way of doing it is like trying to ensure you have all the tools you need to solve any problem with relative ease, while the Lisp way of doing things is more like trying to ensure you have all the tools you need to create tools that provide optimal ease of accomplishing the task at hand. Please excuse the flawed oversimplification. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] Ben Franklin: "As we enjoy great Advantages from the Inventions of others we should be glad of an Opportunity to serve others by any Invention of ours, and this we should do freely and generously."