Submitted by After helping develop the Xerox Alto’s Bravo word processor and leading Microsoft Office development for years, Charles Simonyi left Microsoft in 2002 to found his own company, Intentional Software. His company’s novel goal: to ease software-development headaches by abstracting the software’s requirements away from the code itself, similar to the way that WYSIWYG word processors abstract the document from the formatting tags that underlie it. “Software as we know it is the bottleneck on the digital horn of plenty,” he says. “It takes up tremendous resources in talent and time. It’s disappointing and hard to change. It blocks innovation in many organizations.” Code should be abstracted into models that are easier for end customers to visualize and to modify, he argues. This article, written by Dreaming in Code author Scott Rosenberg, provides an overview of Simonyi’s life, ideas, and current initiatives.
I do believe this is the man who created apps Hungarian notation and gets the quote that titles this article. I’m still trying to find one decent article explaining his design and coding philosophies, most seem obsessed with him going into space (who cares about that anyway?).
The original Excel team is, at least according to Spolsky, revered and was brilliant.
The original Excel team is, at least according to Spolsky, revered and was brilliant
Actually, he said the were Excel-lent!
[Music from Bill and Ted’s Excellent Adventure starts playing]
According to the Mythical Man-Month, the software always will be hard to write, no matter the improvements on technology or methodology used.
Is there some actual code or some real product that speaks about his current initiatives?
The closest thing I can think of are Apple’s programming environments (like QuartzCompositor or the data visualization in CoreData). He had nothing to do with either, but his description would fit those. I don’t know of Windows or Linux equivalent per se, except for certain third-party toolkits.
Actually, there is one proven method for defeating the dilemma presented in the Mythical Man-Month. The key is to structure the project so that interdependencies between programmers and their code are minimized. One may argue (if one doesn’t mind a good flame war), that project management was the key to Linux surpassing existing UNIX-like open-source operating system projects. Its loosely-coupled structure and hierarchy of subsystem maintainers abstracts the interdependencies from individual contributors, allowing the development community to produce at a rate much closer to the sum of its parts.
Contrast that to more typical commercial development projects, where often you can’t commit code because someone else has checked-out something that you depend on. You really see the myth of the man-month in these settings.
I think that you can only get so far with smart and fancy development tools. At a certain point, they get in the way of what you’re trying to do. IMHO the problem with software development is that programmers typically don’t care enough. They don’t introduce enough structure where the development tools don’t require it, and they find ways to defeat structure when they do require it. They produce sprawling 3000-line functions with 7 levels of nesting. The idea of stepping through the code line-by-line in a debugger is a thought that never crossed their mind. And if test cases aren’t “automatically generated” or written by some intern or contractor in India, then they don’t exist.
Software should be represented by models that the customer can visualize? People don’t understand models. They have problems grasping anything that isn’t tangible or imperative. If more people understood abstract concepts, then we would have more competent programmers.
>>IMHO the problem with software development is that programmers typically don’t care enough. They don’t introduce enough structure where the development tools don’t require it, and they find ways to defeat structure when they do require it.<<
Have you worked as a programmer? I have. Often the job involves having to manage constant impossible deadlines, and other impossible demands. Often, if the program doesn’t crash instantly, you *have* to push it out the door.
Don’t get me wrong: there certainly are sloppy programmers, who just don’t care. But I wouldn’t blame it all on the programmers.
Open source projects, at least larger ones tend to have much less interdependencies than closed source projects.
One guy found out about that, when Netscape became Mozilla and open source.
The Netscape code had somewhat of 23 dependencies per module on average, two years later that number dropped to 5 or 6.
The Linux Kernel also has an average interdependency near 5, wheras most proprietary kernels are much more interdependent.
Maybe this low interdependency is the reason why Linus did not yet have to open a 2.7 source tree, which is surprizing even to him.
As a low interdependency is advantageous for programmers only in the long run, it is clear why open source software is written so cleanly – it is finished whenever it is finished. Whereas closed source programmers mostly have to keep impossible deadlines for impossible feature lists, which probably makes them take as many dirty shortcuts as possible close to the deadline instead of rethinking the structure again for another week.
And also, interesting is that the Mythical Man-Month is suggested a good read by Microsoft for SDE candidates to prepare for interviews !
The day this becomes the standard will be the day I’ll quit the computer industry.
If someone takes all the fun involved at software development, all that’s gonna left of computer fun is games… and I don’t like them that much.
Gee… I hope this guy never gets to that point.
“Code should be … easier for end customers to visualize and to modify.”
I’m not so sure that’s a good idea.
See Stroustrup’s comments:
“The idea of programming as a semiskilled task, practiced by people with a few months’ training, is dangerous. We wouldn’t tolerate plumbers or accountants that poorly educated. We don’t have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.”
http://www.techreview.com/Infotech/17868/page2/
While Stroustrup’s comments are consistent with the high barriers of his baroque creation, C++, in the big picture programming is too important to be reserved for a narrow elite. The diversity of programming languages, the fun that people of all ages can experience programming, and the unique notion of manipulating a universal tool that is a computer — these are but a few points at odds with his vision.
The danger that Stroustrup claims varies wildly across the enormous and growing variety of contexts involving programming. E.g., if so many office workers are allowed to do word processing, why should they not be allowed to program in the appropriate context? I recall that spreadsheet manipulation may be considered to be most prevalent form of programming. Of course, we can imagine far more than these trivial scenarios, especially given a more progressive education system.
Edited 2007-02-14 01:23
“The danger that Stroustrup claims varies wildly across the enormous variety of contexts to which it may be applied. E.g., if so many office workers are allowed to do word processing, why should they not be allowed to program?”
Well, believe it or not even that seemingly harmless programing can become a huge problem.
I know far to many business that handle a lot of task with “hacked” Excel spreadsheets, with poorly put together macros done by employees with zero prior programming experience (and who didn’t want the responsibility but didn’t have a choice).
The result? Hundreds of hours lost each year because of a combination of macros failing in edge cases, “minor” modifications done “just for this month’s report” that become permanent, incomplete workflows involving several manual steps that can easily be done wrong, and a long number of etc.
The result? Hundreds of hours lost each year because of a combination of macros failing in edge cases, “minor” modifications done “just for this month’s report” that become permanent, incomplete workflows involving several manual steps that can easily be done wrong, and a long number of etc.
Poor skills need not be the only or even the most important cause of this danger, however. The type of bad management notorious for using the wrong tool for the job or in the wrong way might better explain it. Given the proper constraints, programming at any skill level need not involve much danger. Admittedly, I may be unrealistic in how often the proper constraints are applied and that may be what Stroustrup is really saying, but I maintain that the skills and the system must both be considered. There is enough of such confidence of relatively little danger that poor skills will continue to be in demand, as R&D into verification of properties of diverse kinds of programs will continue to rise.
Edited 2007-02-14 02:51
Well ‘porcleain’ could very well be developed and modified by end users, as long as the actual plumbing is produced by real engineers, and the pipe designs by real scientists, and everyting orchestrated by real system architects.
There’s room for all.
Simonyi’s idea doesn’t call for throwing out the programmer with the bathwater
… It would just make it easier for that programmer to modify their software on the spot and show the customer the results.
Here’s another response to Stroustrup, written by “ssargent” in the comments section of the Stroustrup article:
BS has answered many criticisms of C++ simply by saying that most people shouldn’t use it. It designed for maximum freedom and expression and requires specialized skill to operate. I agree, we need languages that offer specialized abilities for special programmers. But where I take issue is where BS claims that we have highly specialized and skilled people as bankers and lawyers and what not. Likewise, we need skilled programmers and that amateurs should not program. Seems like a bad idea according to his own principle and argument:
For someone who is most specialized at finance or law, time spent learning how to be a specialist at programming trades off with their ability to learn how to be specialist in finance or law. Likewise, the specialist in programming may not know all the nuances of finance and may not create the perfect program for the financial specialist. If the laity could program, so could those overspecialized in other areas. They could create applications custom tailored to their specialized knowledge in the field that goes beyond the functions of a multi-purpose one size fits all program. But this would be vision of the user knowing best what the user wants instead of the specialist programmer…seems like there should be some room for both. Hopefully Simonyi in “anything you can do, I can do meta” will help create that meeting place.
Couldn’t have said it better myself.
Howdy all
Every decade there seems to be a ‘visionary’ leading the way to the future of programming and oh look here is one right here! but there is just one small thing getting in the way of this ‘automation’ of software engineering it`s a thing called complexity, there is no way a simplified model can encapsulate all of the tiny details that seperates software engineering from say solving a 30 peice puzzle.
They said it with UML tools(which I do love btw), they said it with visual programming tools and we`re in basically the same place as 20 years ago.
Have a look at the MS visual tools, yes their nice and easy but have you seen the code they produce? imagine a kernel built like this!
This is my favorite exmple imagine padding a sequence of ‘things’ (no such thing as primitives etc) out with zeros to fill a cache line, now abstract that in a non-machine dependant way
the number of combinations of this alone would be HUGE.
ease software-development headaches by abstracting the software’s requirements away from the code itself, similar to the way that WYSIWYG word processors abstract the document from the formatting tags that underlie it.
This is massively, massively wrong.
Compare two documents, one written with MS Word, and one with LaTeX (where the user explicitly has to input all the tags). I guarantee that the LaTeX version will be more logically and consistently laid out, and will be the better looking of the two. WYSIWYG word processors a very good for firing off the odd quick letter, but if you’re writing a book then TeX is your friend.
It’s perfectly possible to create a consistent, logically organized document in a traditional word processor (either by hand or, in more LaTeX-y fashion, by using styles). The fact that people don’t do this usually means that they don’t have the necessary level of proficiency. In which case, what makes you think they would ever be able to get the hang of LaTeX?
Of course, even in the context of WYSIWYG I like to be able to get at tags directly when needed, as is possible with WordPerfect.
Compare two documents, one written with MS Word, and one with LaTeX (where the user explicitly has to input all the tags). I guarantee that the LaTeX version will be more logically and consistently laid out, and will be the better looking of the two. WYSIWYG word processors a very good for firing off the odd quick letter, but if you’re writing a book then TeX is your friend.
You’ve either never seen bad LaTex or good use of styles in modern versions of word.
It’s a pity framemaker died. 10 years ago it was pretty good WYSIWYG for writing books. I’ve written a lot using LaTeX and given the choice I’d much rather do a book using what framemaker should have become.
You should probably take a look at KOffice. I haven’t tried it yet, but from what I hear KWord is supposed to be frame-based.
Similar to graphic/visual programming.
Wysiwyg.
I really don’t think he invented this.
Many people have attacked this problem
I like the idea. Handcoding is antiquated for mundane stuff.
Although this is only tangential to the topic of the article, I want to use the opportunity to bring in a issue that is very close to my heart. Please bear with me while I keep standing on my soapbox, thank you.
As a FOSS developer and supporter, I lift my hat to everybody that helps to lower the barrier for newbies to start coding. Fighting the computational illiteracy is an often overlooked aspect of promoting FOSS software, and this illiteracy is not only limited to the art of coding, since most users have a (sometimes frightening) ignorance about the inner workings of computers and other electronic devices (the saying, that every sufficiantly developed technology can’t be distinguished from magic, comes to mind).
Currently, this noble goal is achieved by dropping the electronic equivalent of several large dead-tree-edition-libraries in front of users and allow them to start coding/learning. The amazing thing is, that some users indeed start to code or get interested in the process of writing/debugging/testing (FOSS) software this way, but most of the time this is preaching to the choir.
We (as the FOSS community, as diverse as we are) may have succeeded in developing several competing implementations for (desktop-ready) operating systems, and we have lowered the technological barrier to enter such a development process for individuals, that have at least rudimentary skills, but we have – for my taste – not worked hard enough to win large portions of the mere-users crowd over by showing them how much fun coding can be. Given, that developers are more or less the determining and limiting resource in the FOSS world (well, besides hardware, electricity and time, but you get my point) we should really try to get this message out.
OTOH, I’m not sure if fighting computer illiteracy with a mild form of computational dyslexia (or even functional analphabetism, when we speak of VBA macros) is the way to go. Projects, that work along the ideas presented by Simonyi are a good starting point to show users, that they can also be coders and developers. But we better provide them ways to gain a deeper understanding of this field in an accessible way as soon as possible after they start to express themselv in code (something like the alt.lang.language lists, but with less of the my-language-is-better-than-your-language, your-coding-style-sux, read-the-freaking-manual-first attitude, that is visible in some of the unmoderated channels, and with perhaps more “appeal” to the non-techies)
DISCLAIMER: I’m a C++ and Fortran programmer by trade and I don’t find both languages to be overly complicated. OTOH, I don’t seem to have much of this social-life-thingie everybody else is always talking about, so maybe that is somehow correlated to my preferances when it comes to programming languages 🙂
Edited 2007-02-14 08:12
The Japanese programming industry (hearsay from my profs) supposedly is super componentized to the point where there’s very little customization. I’m not sure about the cost savings from this, but they have had several high profile failures because of this philosophy.
One of which I believe was the stock market problem when someone placed a wrong order and couldn’t retract it.
“…help clients define their precise hopes for their bench…”
Gave me a good laugh! The average guy could not define _anything_ precisely even if his life depended on it!
The article was interesting in places but wayyy too long. Actually I don’t care about this guy’s childhood or standard of living…
Also the author likes to pretend Wysiwyg is abstraction – no, it’s very clearly not!
If anything I’d call it an “anti-abstraction” because you bother with the actual layout while writing the document.
Not to say this is necessarily the wrong way of writing texts but it’s not an abstraction.
Next, Hungarian notation – ouch!
It is by no means an abstraction because it puts implementation details (like type information) into the variable name.
“A year ago, inspired by a new insight into how to present multiple views of heterogeneous types of data, they threw out a lot of their code and began again.”
Now that’s a bold move, makes me a bit critical about his other concepts, though 😉
All in all he seems to be describing some advanced form of IDE but that’s certainly not revolutionary.
Parsing “1/(x^2+1)” in a readable way is a nice feature but no completely new way of programming.
It should, for example, be pretty easy to convert a language from “if(cond){expr}” to “if cond then expr endif” or even python style, provided the functionality itself remains unchanged.
While all this features are certainly nice, they seem to indicate that modern programming languages are missing some important feature in how they describe information.
I don’t know what this feature is but everything I’ve heard of so far to solve the programming crisis sounds like a hack.
It feels like there is a big wall in our way and instead of removing it we are trying to make running against it less painful.
What this guy offers is more RAD (rapid application development): instead of writing the code, draw it.
Ok, drawing the code might have a few advantages, but everyone with a degree of CS knows that requirements specifications are programs themselves, and since they are programs, they can only be proven partially correct.
I imagine that a truly live development system would be much better for the clients, especially in a web environment where I can go to the client site and start developing the application there, using a web app.
But this is not going to solve the problem of correctness, testing, debugging etc.
I remember articles from 20 years ago, claiming that there is some new technology to fix this bottleneck.
And I’ll bet there were similar claims that go back 30 or even 40 years.
I’ll believe it when I see it.
I do not see any way around the demand for even the poorly skilled in programming. The complexity and bugs of systems are inevitable regardless, hence the continuing R&D in notions of redundant and self-healing systems to increase robustness. While it is unclear that Simonyi is going to get far, DSLs (domain specific languages) will continue to have promise for getting novices to benefit from programming.
The notion of keeping programming away from the amateurs also sounds eerily similar to early and continuing attempts to dismiss FOSS.
Sorry, but I couldn’t disagree more.
Let me say one thing in advance: I’m by no stretch of imagination an expert programmer, it’s just my hobby.
But:
“The complexity and bugs of systems are inevitable regardless, hence the continuing R&D in notions of redundant and self-healing systems to increase robustness.”
Ok, car accidents are inevitable so I might as well drive mine straight into that wall?
Redundancy and self-healing systems mean sh*t if the algorithm is just plain wrong. They allow the system to fail gracefully, granted.
“The notion of keeping programming away from the amateurs…”
This is not about amateurs. I’m an amateur myself and judging from my experience it’s very easy to learn a programming language – the general language constructs, that is. But you can always just look weird stuff up. And I’m talking about C(++) here, Python is even more like pseudocode.
I mean, come on, you’ve got to learn 100 syntactic constructs at most, it’s a joke compared with real languages!
Imo the real problem is that some people just don’t grasp logic. You don’t have to know by heart how to write an if-then-else statement but if you see one explained in a book it should ring a bell. It’s like giving a very old and well known concept a new name.
However, some people don’t seem to have this way of thinking. For example I tried to explain to a friend of mine that (a –> b) means (not b –> not a). I struggled half an hour and failed miserably. It’s the same when we discuss something: all we can do is agree to disagree.
Making these people programmers is a BAD idea. About as bad an idea as trying to turn me into a great singer. See, I like music a whole lot but I just can’t tell if I get the melody right
I believe it’s the same with some people who like software but don’t grasp programming languages.
Adjusting software development to the logic impaired is _not_ a good idea.
But I welcome attempts to improve the communication between programmers and experts of the particular domain.
What we need are programming concepts and tools that allow the good programmers to write even better software. Short term I’d say we are more likely to see the tools improve (even better integration of the compiler/interpreter into the IDE).
First, beware of car analogies. You know that programming environments can be extremely constrained, some with worst-case consequences amounting to nothing worse than time wasted. If you must use an analogy, pick something closer than cars.
The notions of reading, writing, and mathematical literacy just happen to predate computers and programming. Just because efforts at computer literacy have been misguided does not at all preclude enlightened approaches that lead to better programming skills. Having trained hundreds of computer novices from many different walks of life and occupations, I am confident that people have far more inate programming potential than what is implied in many of the posts I read here. On the other hand, I know of mathematically talented people who hate programming because of what they see as questionable hoops to jump through such as the arcane syntax of C++. Indeed, many talented computer scientists dislike programming, at least what passes for the mainstream kind.
Although you may disagree about the degree to which the poorly skilled should be served, they form an increasingly important area. Economic demand ensures it. We should not just get used to this fact but should find some good in it. E.g., perhaps in a few decades, there may be a society with enough appreciation of programming, that they might have a clue enough to be free of stupidities such as the DMCA, etc. Software will only be much more important then, so I do not find this far-fetched.
Edited 2007-02-14 20:26
I chose the car analogy not to imply damage. Anyway, I’m not sure you got what I was trying to say so I’ll choose a different analogy:
Let’s say someone is too fat, would it be smarter to
a)Sit in front of the tv all the time, eat fatty foods, do no exercise and just sigh “I’m fat anyway!”
or
b)Get off ones lazy a** get a balanced diet and start doing exercises?
What I’m trying to say is that this “The situation is already bad so it does not matter if it gets worse”-attitude only makes sense if you believe the situation can’t get much worse – which I don’t.
I see this kind of fatalism all too often!
Regarding the consequences of a failing algorithm:
Well, there are those that might work if you just restart them, there are those that implement some functionality that’s not all that important.
In those two cases redundant and self healing stuff makes sense to me.
But then again, there are a whole lot of routines that are absolutely critical and need to work or otherwise render the whole app useless.
You see, it doesn’t make much of a difference for me if a program crashes or just some part of it stops working if I need that part.
Then, of course there are errors that might not be obvious – a routine might return a number that’s not NAN and not INF but is still the wrong result!
Finally, since you have more experience in educating programmers, could you please explain what exactly is hard about current programming languages like python? I just don’t get it…
I mean, if the first thing they see is assembly code or some freaking templates of templates of templates in C++ I could understand that they’re a little upset, but otherwise…
If somebody cannot be bothered to learn about 100 different symbols, how could he possibly survive highschool? Learning English was often like “Here is a list of ~100 words, prepare for the test in 1-2 weeks” and English was one of many subjects. Or how come he didn’t choke on weird expressions in math classes?
Seriously, I can’t understand how somebody with even half a brain could find programming difficult. Please enlighten me 😉
I see where you are coming from and am aware of the fatalism. I know how easy it is to become cynical around “lusers”. While some people may see that as an insult, it really does describe a certain helpless state of mind. Luserdom need not prevail, however, and you will grant that any trainer should work against it. More generally, we must work our way out of these inevitable phases of cynicism, although I admit that non-educators are not so used to this. Doing it anyway shows special leadership, IMO.
Yes, redundancy and self-healing need far more R&D, but it is happening, along with R&D into various forms of limited verification during development. Who is to say that investment here is anywhere it should be? I hardly think it is.
Why is programming, or anything, difficult? Simple: motivation. Motivation is multifaceted and subtle, and three excacerbating factors immediately come to mind in the case of programming instruction. First, students nearly always come to it with a serious debt in the form of logical and mathematical skills, and managers are often reluctant to invest here in their haste. Second, it’s too easy for a skilled programmer to forget the problems along the way to mastery. Third, I have noticed that many technical people such as myself can be unusually impatient and it can come off quite nastily.
Too many times have I wrote off people at first, only for them to surprise me later with enlightenment. This must humble us — at least in regards to the potential of people and the complex nature of motivation.
One objection to my optimism is the slim prospect of enough educators with a handle on motivation, but I do feel that programming is special here. What other subject matter is reinvented all of the time and in such varying implementations?
I admire what Simonyi is trying to do, but I will note something closer to my experience. Whatever Lisp and its dialects may lack in technical merit versus certain more modern languages (Haskell, *ML, etc.), no other tradition has been as rich in the educational context. Even today, I would note the Scheme dialect in its various implementations as involving the most progressive thinking in the area we are discussing — a good starting point for further inspiration, IMHO.
Great reply! I’m convinced. Good luck to you in educating more people!
Seriously, I can’t understand how somebody with even half a brain could find programming difficult. Please enlighten me 😉
Learning the syntax is a little first step to be able to program. One should be able to translate the problem to real algorithm what could be written in desired programming language.
A lot of people doesn’t even feel the difference between left and right mouse button (thats why Apple use one button), but it doesn’t mean they are stupid.
Edited 2007-02-15 15:35