Removing Software Complexity 178
t482 writes "Charles Simonyi (ex Xerox Parc & Microsoft ) says that Software "has become a field where we focus on incremental improvements in processes. That course is futile, because it can never solve the problem of human imperfection."
Even as software collapses under the weight of its own complexity, we've barely begun to exploit its potential to solve problems. The challenge, Simonyi believes, is to find a way to write programs that both programmers and users can actually read and comprehend. Simonyi's solution? To create programming tools that are so simple and powerful that the software nearly writes itself.
"Software should be as easy to edit as a PowerPoint presentation," Simonyi asserts."
But I like complexity (Score:3, Interesting)
Sounds familiar... (Score:2, Interesting)
Re:m_lpstrnzCharlesSimonyi (Score:5, Interesting)
Re:nothing new (Score:3, Interesting)
Procedural programming runs into complexity limits much more quickly, because the programmer is responsible for all of the interactions explicitly. Excel allows business people to work in their domain, using ideas that make sense because they were extracted from the domain. With the excessive computing power found on modern computers, the inefficiencies of declarative syntax can be accepted. A good example is SQL - a very small query can produce a very complex query plan and execute in a timely manner with today's databases. Because the core language is declarative, I can write a very complex query which would require pages of code to be written in a procedural language. Of course, there are limitations, and so you don't normally find SQL alone. Instead, you find it wrapped in a procedural language.
Similarly, you often find Excel spreadsheets with macros, with the macros performing the role of the procedural wrapper language for SQL. I believe the current ultimate expression of "ease of programming" is when you can create a custom declarative language in a domain (financial calculations, data access, etc) and then add some simple tools for sequencing the declarative actions.
Programs could then be written by domain specific users, and glued together with some high level interface code. In some ways, this is what Microsoft is trying to achive with Office for Developers tools: you build databases in SQL Server, do data entry and simple reporting via Access (which makes banging up an interface to data cake) or web forms, use analytical services for complex reporting, Excel for simple financial presentations (particularly for graphing), crystal reports for end user reporting, word for mail merge and formatting, IIS for web presentation of documents (either created on the fly in ASP or via SharePoint), etc.
In a preverse way, this is the old Unix "small tools, chained together" philosophy, except each tool is a swiss army knife with a chain saw attached. However, the correctness of the observation that chaining special purpose tools still remains valid, and valuable.
However, there are also major problems with this approach as described above. Especially when Office is updated: all your hard work scripting needs to be reviewed and revised because nearly every program will break something, somewhere.
Meta complexity? (Score:5, Interesting)
I don't know if that necessarily has to be the case. Back in the old 8 bit CP/M days I got my introduction to Forth through an application named KAMAS, which stood for Knowledge And Mind Amplification System. Lofty sounding name aside, KAMAS was really an outlining tool. A very good one at that. A few years later after the PC and DOS had taken over a whole slew of these outlining tool programs appeared and all claimed the ability to revolutionize the way you worked with information. For the most part, this was all bunk but in a way KAMAS almost stood up to its self-aggrandized promotion.
What made KAMAS different, IMHO, was that it was based on a FORTH like language that was at the core of the product and its author (Adam Trent) left that programmability exposed. Yet, he was able to organize the program in such a way that the average user didn't have to interact with the language at all or even know it was there if they didn't want to. Heck, you didn't even have to use it as an outliner -- if you wanted it could just act as a simple To Do list.
As the owners' manual stated, KAMAS was arranged in rings,like a Venn diagram, with the outliner at the outermost ring. However, if the user wanted they could issue a command that would expose the next inner layer ofr complexity and do simple programming tasks on their outlines. Because of its' Forth heritage, the programming was interactive and could easily be undone? Screw up a word definition? Just tell the interpreter to FORGET it.
For the true geek crowd, another word could be issued (only while inside the programming layer) that would then expose the inner-most layer and open up access to the all the words defined. At this point, the user/prorammer would have access to basically a full Forth programming environment and actually change or extend the outliner tool by rewriting it! At this point, if one wished to devote the time to learning how to program in a stack based threaded interpreted environment, your computer was wide open to you. It was like have the keys to the gates of heaven laid at your feet.
Later on, when I started playing around with Forth proper, I was still impressed with what KAMAS's author (whatever became of Adam Trent anyway?) had done and felt that this managing of complexity was the true power of Forth based systems. However, even I have to admit that Forth is far from ideal given its' RPN and stack based roots -- at least for Joe Everyuser. More time passed and I discovered Smalltalk and Alan Kay and his idedas for Dynabook and lately, Squeak [squeak.org].
Smalltalk, Squeak and OOP share with KAMAS the idea of bringing the power of the computer to leverage the mind to the everyday user. And, as with KAMAS and Forth too, they are able to prevent a useful, simplified environment at the surface, but still making the power and complexity available to those who want to use it.
So, in short, I think you're wrong here. One does not have to lose the ability to gain low level access in order to mask complexity from the average user. What I do question after all these years is how many users will actually want access to the power hidden at the core of systems such as Squeak and KAMAS before it? I mean, come on, I live in a country (US) where a sizeable portion of the population can't identify the Pacific ocean on a map! I think its likely that in the end we'll end up with just about the same mix of truly technical users to clueless lusers that we have now.
As depressing as that may be, and the thought does depress me, I still think it's important to implement Charles Simonyi's ideas (as well as Alan Kay's and Doug Englebart's and Steve Wozniak's and all the others who believe that the computer can serve as a tool to liberate people). If only for the sake of providing a migration path for people to make that crossing from clueless luser to someone who is able to effectively use the computer as a "Knowledge and Mind Amplification Tool."
Compexity misunderstood (Score:3, Interesting)
When's the last time you saw a quality PowerPoint presentation? I've seen them, but they're rare. Presentations from people who don't know how to communicate effectively are lame as Visual Basic programs from people who don't know how to program. The style takes precedence over the actual substance.
Complexity is not something that needs to be hidden away. Software is complex. Using software is a complex activity. Writing software is more complex still. You cannot manage that complexity by imagining that it is not there. The way to manage it is to recognize that it exists.
It doesn't matter if you use C, Java, VB or Ruby, the complexity is still there. The advantages of high level languages is not that they hide away the complexity, but rather that they enable you to manage the complexity by taking care of the details.
Take any book on software development. Not programming, but development. How much time is spent on implementation? Not much. For a good project, 90% or more of the time is spent analyzing, specifying, designing and testing. This is the HARD part of developing. Give me complete specs, a valid design, and a top-notch QA group, and I could code just about anything. All that other stuff is there to MANAGE the complexity.
I've seen what Microsoft offers to make things easy. They're solutions to complexity is to ignore it, which is the wrong approach. And thus we end up with crap presentations, crap documents, and crap VB programs. It's not because these tools are crap in-and-of-themselves, but simply because they lead the user to disregard the existing complexity.
NakedObjects? (Score:3, Interesting)
NYTimes: Powerpoint and the shuttle disaster (Score:3, Interesting)
The Level of Discourse Continues to Slide
By JOHN SCHWARTZ
Is there anything so deadening to the soul as a PowerPoint presentation?
Critics have complained about the computerized slide shows, produced with the ubiquitous software from Microsoft, since the technology was first introduced 10 years ago. Last week, The New Yorker magazine included a cartoon showing a job interview in hell: "I need someone well versed in the art of torture," the interviewer says. "Do you know PowerPoint?"
Once upon a time, a party host could send dread through the room by saying, "Let me show you the slides from our trip!" Now, that dread has spread to every corner of the culture, with schoolchildren using the program to write book reports, and corporate managers blinking mindlessly at PowerPoint charts and bullet lists projected onto giant screens as a disembodied voice reads
every
word
on
every
slide.
When the bullets are flying, no one is safe.
But there is a new crescendo of criticism that goes beyond the objection to PowerPoint's tendency to turn any information into a dull recitation of look-alike factoids. Based on nearly a decade of experience with the software and its effects, detractors argue that PowerPoint-muffled messages have real consequences, perhaps even of life or death.
Before the fatal end of the shuttle Columbia's mission last January, with the craft still orbiting the earth, NASA engineers used a PowerPoint presentation to describe their investigation into whether a piece of foam that struck the shuttle's wing during launching had caused serious damage. Edward Tufte, a Yale professor who is an influential expert on the presentation of visual information, published a critique of that presentation on the World Wide Web last March. A key slide, he said, was "a PowerPoint festival of bureaucratic hyper-rationalism."
Among other problems, Mr. Tufte said, a crucial piece of information -- that the chunk of foam was hundreds of times larger than anything that had ever been tested -- was relegated to the last point on the slide, squeezed into insignificance on a frame that suggested damage to the wing was minor.
The independent board that investigated the Columbia disaster devoted an entire page of its final report last month to Mr. Tufte's analysis. The board wrote that "it is easy to understand how a senior manager might read this PowerPoint slide and not realize that it addresses a life-threatening situation."
In fact, the board said: "During its investigation, the board was surprised to receive similar presentation slides from NASA officials in place of technical reports. The board views the endemic use of PowerPoint briefing slides instead of technical papers as an illustration of the problematic methods of technical communication at NASA."
The board echoed a message that Mr. Tufte and other critics have been trying to disseminate for years. "I would refer to it as a virus, rather than a narrative form," said Jamie McKenzie, an educational consultant. "It's done more damage to the culture."
These are strong words for a program that traces its pedagogical heritage to the blackboard or overhead projector. But the relentless and, some critics would say, lazy use of the program as a replacement for real discourse -- as with the NASA case -- continues to inspire attacks.
It has also become so much a part of our culture that, like Kleenex and Xerox, PowerPoint has become a generic term for any bullet-ridden presentation.
Dan Leach, Microsoft's chief product manager for the Office software, which includes PowerPoint, said that the package had 400 million users around the world, and that his customers loved PowerPoint. When early versions of Office for small business did not include PowerPoint, customers protested, he said, and new versions
Re:m_lpstrnzCharlesSimonyi (Score:4, Interesting)
But Hungarian notation doesn't fix that flaw. It's only as reliable as the programmer who writes the code. In most cases, that means not reliable at all.
I have been bitten before by relying on the Hungarian junk at the start, only to discover an hour later that it was completely unrelated to the actual type.
Hungarian notation gives the illusion of improved type safety. It achieves nothing. If you want type safety then use a language that supports type safety.
Re:COBOL (Score:2, Interesting)
This has been my observaion as well. I used to teach beginning programming at a local University and I have to say that it was amaizing how many people had problems thinking through what needed to be done to accomplish a thing as simple as swapping two integers. I'd try and get them to talk about the steps that would need to be taken. I'd have them transfer two objects between two hands. They'd do that fine. I'd then ask them to break it down into steps and they were at a loss. Problem decomposition was something that many individuals simply had no experience with.