Unplugged: Charles Simonyi creates software intentionally

ZDNet ^ | Feb 15, 2004 | Dan Farber

[mikegi]

Simonyi's notion of pushing programming upstream is a PowerPoint-like design tool that allows stakeholders to describe an application in their own terms and then hand it off to the programmers to write a "generator" to produce the machine-readable code. His company will develop tools, taking advantage of recent innovations in aspect-oriented development, design patterns, model-integrated computing and other programming methods. In our interview, Simonyi explains some of the concepts behind intentional software development and how it will pave the way for more adaptable, reliable programs.

[mikegi]

Interesting interview with Simonyi. I've thought about this problem for years. I've written in Asm, C, C++, Modula2, Fortran, Basic, etc. I've written my own application specific language to use on projects on top of those traditional languages. They all fail in simplifying the overall task. We need a more descriptive language where variables are defined by their acceptable ranges, not just implied as with a float.

The problem Simonyi faces is that there are wildly differing requirements for various tasks. Making a tool that could cover them, without making it so general that defining each task becomes too tedious, is difficult. Of course, there's also the problem that ultra-high level languages are slow in execution.

[Dialup Llama]

I've noting this sort of thing lacking in normal design documents. I've always a little note that describes the intent of the programmer. Something that says, "What were you thinking when you did this? What is the purpose behind this? What is the reasoning in choosing this?"

[babyface00]

So if Simonyi's creation puts Indian software programmers out of work, who supposedly put American software programmers out of work, will it be a good thing or a bad thing?

Will we need the government to "do something" about this software?

[Tax Government]

If you think Microsoft Word is a cutting-edge piece of software and has evolved adequately over the last decade, then keep an eye on this.

[alnitak]

But where's the real hard work in software development? It's not in writing the code, that's easy for any competent engineer.

No, it's figuring out the requirements in the first place, getting business process change, ensuring all stakeholders are aligned, project scheduling, resource balancing, communicating the plan etc. You need to deal with difficult people and the politics. At a trivial level, it's a question of making sure people answer their emails! Any interesting project is more a question of management than writing code.

The subject of program generators comes up about every 5 years in IT. And then the companies proposing them disappear without trace....Isn't Simonyi aware that most people don't even know how to use PowerPoint?

We are making progress in the software world, if you think about it, but it's in specific, specialist domains. By controlling the scope of what you want to achieve, you can get reuse. Examples: window toolkits, graphics toolkits, image processing toolkits, scientific toolkits. Add to this design patterns etc and we are successfully writing ever more complex programs. It's just that user's requirements are also expanding as we meet their current needs. One of the problems with trying to do this all encompassing programming automation he is talking about is that the level of detail required to model "the real world of the subject matter expert" is colossal.

For example, in business software in which I work, it is easy for a software company to come up with a model for say, managing stock in shops for a company. Now try and apply it to another company. You will suddenly discover a bazillion new requirements

"we deal with our suppliers differently..."
"payment terms are different for these customers...."
"in these states, the laws mean we have to do X, unless Y is true OR.."
"well, this is how it works now, but it could change during the lifetime of the project - can you do it both ways for the same cost...."
"I dunno how that works, the guy who understood it has left"
"well, the accounting dept have that information but they won't tell you because they are afraid of losing their jobs"
"can we make this thing run 5 times a day instead of 1?"
"we needle to handle timezones differently"

And the specs for these matters can be incomplete, imprecise and just plain contradictory. It's a fuzzy problem! There is no perfect solution. Modelling tools aren't good at dealing with ambiguity. That's where the humans come in, and why I still have a job :-)

Of course, you can try and capture EVERYTHING for EVERYBODY. That's called "SAP". But companies still spend hundreds of millions of dollars customising it for themselves :-)

[Constantine XIII]

I (heart) Labview. :p

[dfwgator]

If you had one business expert who knows everything, they could probably make this work. The problem is that business domain knowledge is distributed, and getting all the parties to collaborate is extremely difficult. On paper, Intentional Programming, Model-Driven Architecture seems like a good idea. But in the end, it will always be "Peopleware" that drive whether or not a project will be successful or not.

[babyface00]

I think the biggest problem with Word is that MS kept trying to evolve it after Word 97. That product did everything 99% of its users needed.

OTOH, I doubt the software referenced in this article would be all that much use developing what I would characterize as "utility software" (word processors, spreadsheets, graphic software, etc.). I believe it is designed more for creating application software, especially that built around a database.

I could be wrong though.

[Wolfie]

I worked with a similarly functioning product 6 to 8 years ago. Didn't cut the mustard.

[dfwgator]

These situations you describe are why I believe that Aspect-Oriented Programming will be huge. Many developers don't understand the difference between business logic and business rules. Business logic is stable, whereas business rules are more volatile as they are more dependent on outside factors (regulation, market conditions etc.) The key is to separate business logic code from code that implements business rules. And this is precisely what AOP is good at. In fact, I think Simonyi is working with Gregor Kiczales, who started AspectJ when he was still at Xerox.

The situations you enumerated basically all deal with implementing business rules, not business logic. The idea is that you can use business rule engines (like JESS) to implement that logic instead of embedding the rules logic in the core business classes, which makes maitenance a pain in the "you know what." Thus now the business experts can do their modelling indepedent of the software developers and simply have their logic "weaved" in via the aspects.

[Cobra Scott]

"They all fail in simplifying the overall task. We need a more descriptive language where variables are defined by their acceptable ranges, not just implied as with a float. " I heard about that once. It was rumored to read like a book, to handle floating point math as accurately as Fortran, ran fine on a thin client network, and was easily learned in a matter of weeks. I think they called it COBOL ;P

[balrog666]

The idea has been around for a long time. This package generates its own C++-code from flowcharts and equations: VISSIM