Paul Rubin wrote: > "Russ P." <russ.paie...@gmail.com> writes: >> I know some researchers in software engineering who believe that the >> ultimate solution to software reliability is automatic code >> generation. The don't really care much which language is used, because >> it would only be an intermediate form that humans don't interact with >> directly. In that scenario, humans would essentially use a "higher >> level" language such as UML or some such thing. >> >> I personally have a hard time seeing how that could work, but that may >> just be due to be my own lack of understanding or vision. > > The usual idea is that you would write a specificiation, and a > constructive mathematical proof that a certain value meets that > specification. The compiler then verifies the proof and turns it into > code. Coq (http://coq.inria.fr) is an example of a language that > works like that. There is a family of jokes that go: > > Q. How many $LANGUAGE programmers does it take to change a lightbulb? > A. [funny response that illustrates some point about $LANGUAGE]. > > The instantiation for Coq goes: > > Q. How many Coq programmers does it take to change a lightbulb? > A. Are you kidding? It took two postdocs six months just to prove > that the bulb and socket are threaded in the same direction. > > Despite this, a compiler for a fairly substantial C subset has been > written mostly in Coq (http://compcert.inria.fr/doc/index.html). But, > this stuff is far far away from Python. > > I have a situation which I face almost every day, where I have some > gigabytes of data that I want to slice and dice somehow and get some > numbers out of. I spend 15 minutes writing a one-off Python program > and then several hours waiting for it to run. If I used C instead, > I'd spend several hours writing the one-off program and then 15 > minutes waiting for it to run, which is not exactly better. (Or, I > could spend several hours writing a parallel version of the Python > program and running it on multiple machines, also not an improvement). > Often, the Python program crashes halfway through, even though I > tested it on a few megabytes of data before starting the full > multi-gigabyte run, because it hit some unexpected condition in the > data that could have been prevented with more compile time checking > that made sure the structures understood by the one-off script matched > the ones in the program that generated the input data. > > I would be ecstatic with a version of Python where I might have to > spend 20 minutes instead of 15 minutes writing the program, but then > it runs in half an hour instead of several hours and doesn't crash. I > think the Python community should be aiming towards this.
RPython might help, but of course it wouldn't allow you the full language. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
