>>>>>http://techupdate.zdnet.com/techupdate/stories/main/Charles_Simonyi_creates_software_intentionally.html
>>>>
>>>>I thought it was mediocre until I got to “Semiconductors didn't improve … performance by exhorting workers to do a better job, wash their hands more often or put in longer hours. It was accomplished by mechanizing a greater and greater portion of the process” – then I stopped reading.
>>>>
>>>>When we get to the first factual piece of text and it is just plain wrong I found I lost all motivation to continue reading.
>>>>
>>>>I was under the impression that increases in computing power were primarily a result of:
>>>>
>>>> - Increased number of bits being processed concurrently, which in its simplest form can be thought of as the transition from 8 bit, through 16 and 32 to 64 bit computing
>>>>
>>>> - Increases in clock frequency, which have been made possible by a combination of shortening the distances signals have to travel (by continuously reducing the size of components) and more sophisticated tools for managing component layout and interconnect.
>>>>
>>>>In short, improvements in performance have been accomplished through ever increasing degrees of sophistication and not through mechanizing – and I’m guessing he actually meant automation.
>>>
>>>I think he's discussing the production of silicon ingots/wafers. Further down he also discusses turbine blades which are "grown" using a similar process.
>>>
>>>Regardless, I think his main point is valid - that if we want to have better software we have to get error-prone humans out of the loop as much as possible. As developers, we're in the translation business - translating business or other requirements into abstractions that can be manipulated on a computer. We need to automate that translation process as much as possible.
>>
>>Hmmm... I'll wait on this one to see what he eventually comes up with, but it doesn't really sound to me like we human developers are being cut out of the loop, just that we'll all be writing application specific compilers rather than application specific applications.
>>
>>I suppose he feels he can make it a lot more generic than that, but on some level, the business process experts are going to have to be tied into a type of CAD structure that only allows them to 'draw' those processes and ideas that the software developer who sold them the CAD came up with. If it's too flexible, then the 'generator' that is supposed to turn it into code, is almost going to have to be a scientific fiction. Otherwise, we're back to application specific generator programming, and I'm not entirely convinced that's really any better than application specific software the way it's done now.
>>
>>I'm a bit unclear, I think, as to how changing the sorts of programs we write is going to solve any major problems.
>>
>>But, time will tell.
>
>Yes, it's not easy writing a code generator - often harder than writing the code it's supposed to generate. So, if you want to write a difficult app, now you have to create a code generator for that... ? I think your "science fiction" phrase is apt.
>
>One way to look at the "quality" of an application (or just about anything else, for that matter) is to split it into:
>
>- the design of the solution
>- how well that design is executed
>
>As you point out, the design portion is likely to be fertile ground for human thinking for a long time yet. But, if he or anyone else comes up with tools that help automate design in a meaningful way, I'll be happy to take a look.
>
>However, I for one would welcome anything that would automate the execution of my designs. I consider it scandalous that people are still tearing their hair out trying to get combo boxes and treeview controls to work. In an environment as standardized as Windows no-one should have to waste time over cr*p like that.

Can't argue with that.

Maybe one day we'll be able to logically justify writing all our applications by using the VFP Application Wizard.

I, for one, am looking forward to charging big bucks.

Alan