Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Removing Software Complexity

Hemos posted more than 10 years ago | from the breaking-it-out dept.

Programming 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."

cancel ×


Sorry! There are no comments related to the filter you selected.

But I like complexity (3, Interesting)

extrasolar (28341) | more than 10 years ago | (#7378358)

If everyone could do it, I wouldn't be doing it.

Re:But I like complexity (1)

daviddennis (10926) | more than 10 years ago | (#7378586)

You will still have to create rulesets for this system. I don't think they'll be all that simple.

I think his intention is that a programmer creates the initial ruleset, and then the programmer's clients/customers can create incremental changes, such as change the sales tax rate from 8% to 8.25%, or modifying income tax tables.

That eliminates a lot of work for programmers, but by no means all.

Visual Basic made it possible for untrained people to write software, and Access made it possible for untrained people to write database applications, but neither of those applications has reduced or eliminated the need for people to create software.

As it becomes possible for more programs to be written, because these tools are cheaper to use, more programs get created, and as a general rule, more programmers are needed.

There are two serious career limitations for programmers. One is reliability; if this helps with that, it's good. The other is offshoring. If we can become more efficient, and reduce the cost of projects, then we can do more with less, and make it less of an issue than it is now. So it's very possible that this could be a boon for programmers, not a bust.

IT needs, as far as I can tell, are almost unlimited; they are not being met because we don't have the right tools. If we can get the right tools, I feel that we can empower our customers and wind up stronger than ever.


Re:But I like complexity (1)

Paradise Pete (33184) | more than 10 years ago | (#7379102)

Visual Basic made it possible for untrained people to write software, and Access made it possible for untrained people to write database applications, but neither of those applications has reduced or eliminated the need for people to create software.

Your argument is basically "it hasn't happened yet, so it isn't going to." Using that same argument, I could conclude that if I don't die the first time, then Russian roulette is safe.

VB/Access/Cobol/Simonyi: No silver bullet! (4, Insightful)

Doug Merritt (3550) | more than 10 years ago | (#7383375)

Visual Basic made it possible for untrained people to write software, and Access made it possible for untrained people to write database applications,

No, VB and Access made it possible for untrained people (and naive managers) to THINK (quite incorrectly) that they could write software and DB apps.

but neither of those applications has reduced or eliminated the need for people to create software.


There is no silver bullet for making software easy, and this has been known for decades.

Cobol, for instance, was supposed to be English-like, and hence understandable and programmable by non-programmers. Other English-like programming languages have made the same claim. Wrong every time on all counts.

The problem is that specifying arbitrary algorithms requires extreme precision, unambiguity, and tedious detail far beyond anything the average person is even interested in attempting, let alone capable of. It doesn't particularly matter which language or tool is offered, what matters most is the person's abilities (and willingness!) to be excruciatingly detailed and logical and patient.

This has been studied to death, but hope springs eternal...

Another kind of lack of silver bullet are declarative's vastly easier to declare what is needed than it is to specify procedurally how to achieve the goal. However, no one has ever invented a Turing complete declarative language, and there is good reason to think that such a thing is impossible (infinite potential problem domains).

Simonyi is a very intelligent and experienced guy, so he likely knows this. I hope he does; he should. So I like to interpret what he's saying as a grandiose way to say that he's hoping to make a big improvement in the art of programming -- there certainly is huge room for improvement.

But if he literally means he hopes to make all programming as easy as making powerpoint slides, then he is a fool or a liar (but he might still produce some cool tools).

(Making really cool graphics for the backgrounds of powerpoint slides is an art, BTW ;-)

Re:But I like complexity (0)

Anonymous Coward | more than 10 years ago | (#7378970)

The End of the World As We Know It has been rescheduled for next Thursday. Sorry for the inconveniance

In the book Wiseguy (basis for the movie Good Fellas), there's a guy who "always scheduled his appointments for later." It's required you read the book, the line didnt make it into the movie.

Re:But I like complexity (1)

gl4ss (559668) | more than 10 years ago | (#7379136)

well, you could be creating really really REALLY complex systems with this then(and that's what they would end up being used for.. and we would be at point zero).

it doesn't sound bad, but all in all it does sound a bit like basic, and no matter what way the program is done you still have to know what you're trying to do(what this seems to imply is that there would be some super ai figuring out what exactly the program was supposed to be doing in the first place so that it would do "not what i told it but what i really meant").

this challange he mentions is quite a big feat.
the (selected)tools themselfs are quite simple already, but there's things that keep (normal)users from ever understanding how the program is built, you could abstract it more but that wouldn't be much of a use(you would end up with better ui's maybe, but ui's we have already).

of course it would be rather easy to make an environment for building really simple programs, but that's what powerpoint already is! (power point being c64 basic, some fancy video editing tool being more modern software development environment)

and an user is an user, not an architecht or a builder.

cars are quite complex nowadays too.. nobodys bothered about that(well, somebody must). so are big buildings and bridges. the plus side in living in a civilization is that you don't have to know how to do everything.

An interesting read... (1)

baylorhawk (650925) | more than 10 years ago | (#7379309)

I read this article recently, and it pertains to this topic. (By pertains, I mean proves this guy wrong :) Check it out here [] . It was written in 1987, but it still rings very true today.

Re:But I like complexity (1)

His name cannot be s (16831) | more than 10 years ago | (#7381774)

Me too.

But seriously, Every once in a while someone comes up with the idea that software should be easy enough to create that anyone could do it.

It never ceases to amaze me that people think they want that. What you will get is 5 million shitty apps. A great software developer doesn't simply code the solution, but can provide insight into the solution.

I, for one am not worried in the slightest.

Sounds familiar... (2, Interesting)

MopOfJustice (300784) | more than 10 years ago | (#7378371)

Didn't Apple have some QuickCard thingy for a while. I recall them touting it as programming for the everyman...

Re:Sounds familiar... (1)

jpkunst (612360) | more than 10 years ago | (#7379516)

HyperCard [] . I believe it is officially cancelled by Apple, but it is still for sale [] at the Apple Store.


Re:Sounds familiar... (2, Insightful)

jmccay (70985) | more than 10 years ago | (#7383059)

Another company tried something like this in the mid 90s (1996 to 1998). Their product was called Icon Author (glorified flow chart using icons and flowchart symbols) it was simpler, but the logic still perplexed some of the temps we hired at the company where I was working during that time. They even tried to make it cross-platform, but they failed because they used MFC (and MFC on the Mac sucked {on purpose probably}). They might have succeed today if they use wxWindows.

The problem with this idea will be getting around the complexities of programming--like the logic. Some people just aren't logical thinkers. Icon author made programming somewhat easier but it didn't make the logic easier. Some people have problems with concepts such as loops and data structures. They may get around this problem, but it will have be done by making sacrifies.

Next on Slashdot (1, Funny)

kabocox (199019) | more than 10 years ago | (#7378380)

The self writing book report.

m_lpstrnzCharlesSimonyi (3, Insightful)

WasterDave (20047) | more than 10 years ago | (#7378415)

Little known fact: This is the same Simonyi who invented hungarian notation.

Google for "the tactical nuclear weapon of code obfuscation" to receive further enlightenment []


Re:m_lpstrnzCharlesSimonyi (4, Interesting)

darkov (261309) | more than 10 years ago | (#7378500)

That little invention really reflects how stupid this guy is. So much for abstraction when all your variables have their name encoded with their concrete representation. God help you if you want to change the type of your var. It global search and replace for you.

Re:m_lpstrnzCharlesSimonyi (0, Flamebait)

Ender Ryan (79406) | more than 10 years ago | (#7378674)

No kidding. Not the worst idea in the world, but 5 minutes of experimentation should have revealed to him (and all the fools who fucking fell for it) that its minor benefits were so completely outweighed by its flaws that it wasn't worth exploration.

Sheesh, ri-goddam-diculous :)

Re:m_lpstrnzCharlesSimonyi (0)

Anonymous Coward | more than 10 years ago | (#7379653)

Sticking feathers up your butt does not make you a chicken

That's for sure. I'd even say you're a little bit brave.

Re:m_lpstrnzCharlesSimonyi (2, Insightful)

Paradise Pete (33184) | more than 10 years ago | (#7379607)

That little invention really reflects how stupid this guy is.

Calling Simonyi stupid, is, well, stupid. Or at the very least ignorant. He's brilliant. And he invented his notation while writing in C, a language not known for its abstraction.

Re:m_lpstrnzCharlesSimonyi (0, Flamebait)

DAldredge (2353) | more than 10 years ago | (#7380084)

How brillant are you if your ideas do not work in the REAL WORLD?

Re: m_lpstrnzCharlesSimonyi (1)

Black Parrot (19622) | more than 10 years ago | (#7382299)

> Calling Simonyi stupid, is, well, stupid. Or at the very least ignorant. He's brilliant. And he invented his notation while writing in C, a language not known for its abstraction.

If he's so smart, why didn't he just use a language that already did what he wanted?

Re:m_lpstrnzCharlesSimonyi (3, Informative)

GCP (122438) | more than 10 years ago | (#7380509)

I don't know who you are, but the chance that you're qualified to call Simonyi "stupid" is statistically insignificant.

Hungarian notation is a means for overcoming a critical flaw in the C language: the lack of type safety. There are about a million different "abstractions" that look to your C compiler like just a sequence of bytes. C code collects bugs like a porch light every time you try to evolve your code by changing abstractions. Hungarian notation, macros, other coding conventions, special "lint" tools, etc., are pretty much all designed to reduce the problems caused by the poor design of C itself.

Simonyi contributed a workaround that's useful to those who know when and how much to use it.

Re:m_lpstrnzCharlesSimonyi (2, Insightful)

adamy (78406) | more than 10 years ago | (#7381683)

Disagree. C problems are in no way improved by making code less readable.

Including data type in variable names is bad. If your functions are so long that you can't even see where your variables are declared, you need to break them into smaller pieces. And with C inlining, you don't even have the performance argument from Java.

Hungarian notation bad.

Code generation bad.

Simple readable code good.

Re:m_lpstrnzCharlesSimonyi (0)

Anonymous Coward | more than 10 years ago | (#7382388)

Hungarian notation is a means for overcoming a critical flaw in the C language: the lack of type safety.

That's not why Charles invented Hungarian Notation! If you read his original two papers on the subject you will see that he invented it to "avoid thinking up meaningful names for variables". English not being his first language, creating variable names was a difficult problem that he felt he could solve by essentially randomly creating names. Eck.

What's also so interesting about his papers is that he heavily advocated not getting type information into the prefix, however when he went to Microsoft, that's exactly what happened. The jump to Win32 clearly showed why it was an idea bound to fail...

Re:m_lpstrnzCharlesSimonyi (1)

daviddennis (10926) | more than 10 years ago | (#7380704)

I don't think anyone can accuse Simonyi of being dumb, but even smart guys have poor ideas.

I don't like Hungarian notation just because it makes my code look ugly. I spend a lot of time making things look clean and simple, and Hungarian notation ... well, let's just say it doesn't exactly advance that goal.


Simonyi (2, Insightful)

4of12 (97621) | more than 10 years ago | (#7378430)

I take it that Hungarian notation has been left by the waysideon the road to less complexity:)

I agree wholeheartedly with the complexity issue.

I measure my success as a programmer by whether or not another programmer (or myself far in the future) can throw my work onto the screen and understand very quickly what the code is trying to do.

Bugs can be fixed, features can be added and performance can be enhanced later. But not very easily if the code is too complex or, equivalently, has too much abstraction.

And just who (4, Insightful)

kalidasa (577403) | more than 10 years ago | (#7378433)

Will write the programming tools? Seems to me Simonyi's not talking about a replacement for modern programming, but an incremental advancement over say AppleScript or Hypercard. More powerful userland tools will not completely replace programming: someone will need to write the components. Or is he thinking that all the components will be in the OS, and thus third party programmers could be eliminated and the OS vendor and the user would be the only parts of the transaction?

Re:And just who (1)

Oddly_Drac (625066) | more than 10 years ago | (#7378569)

"Or is he thinking that all the components will be in the OS, and thus third party programmers could be eliminated and the OS vendor and the user would be the only parts of the transaction?"

.NET? Having the base classes as part of the operating system so you can truthfully tell the judge that the programming language is 'Part of the Operating System'?

Re:And just who (1)

borgboy (218060) | more than 10 years ago | (#7379415)

fprintf was in ntdll.dll long before C# was but a gleam in Anders Hejlsberg's eye.

Re:AppleScript (1)

dbirchall (191839) | more than 10 years ago | (#7378746)

How to write a program in AppleScript:

  1. Write your prototype in English pseudocode.
  2. There is no second step.

(Okay, okay, well, Mac users will get the joke.)

Correction (2, Funny)

Haeleth (414428) | more than 10 years ago | (#7380438)

I thought AppleScript was basically Visual Cobol...

Real programmers will still have jobs (3, Insightful)

GCP (122438) | more than 10 years ago | (#7380925)

I think it's great for them to pursue tools that make it easier for non-programmers to do more useful things for themselves.

I'm not too concerned that this will replace the current type of programming, though. The biggest problem is that the real-world problem being solved is almost always more complicated than the domain experts themselves realize.

When I sit down with a client domain expert to write a program for them, they are invariably surprised by what I uncover. I gradually tease out a huge variety of scenarios that they've never thought through or decisions that they make on the basis of "experience" whose rules they can't possibly express explicitly, comprehensively, unambiguously, and without contradiction -- on their own.

It just doesn't matter how easy it is to explain the rules to a computer if you don't have the skill that experienced programmers have: to completely specify the problem. Fully explaining how to solve a problem to something other than another intelligent and experienced human is harder than most non-programmers realize. (Of course Simonyi knows this, but the journalists who cover his work probably don't.)

Head in hands.... (3, Funny)

Oddly_Drac (625066) | more than 10 years ago | (#7378437)

...just for saying;

"Software should be as easy to edit as a PowerPoint presentation,"

Powerpoint is _evil_ and should be destroyed, and the ground that it rested on salted.

Re:Head in hands.... (1)

Acidic_Diarrhea (641390) | more than 10 years ago | (#7378508)

I'm not agreeing with the quote but what is your problem with Powerpoint? It is a tool and therefore I don't see how it can be called "evil." Typically inanimate objects don't have moral affiliations. And the fact that people misuse Powerpoint and create awful presentations does not mean that Powerpoint should be abandoned - it means that people need to learn how to give a presentation. Overhead transparencies can yield just as bad presentations as Powerpoint.

Re:Head in hands.... (1)

Oddly_Drac (625066) | more than 10 years ago | (#7378639)

"Typically inanimate objects don't have moral affiliations."

Occasionally they do, if there is comedic value to be had from it.

"And the fact that people misuse Powerpoint and create awful presentations does not mean that Powerpoint should be abandoned"

I'd point to it being a really good reason for it to be abandoned; I've never attended a presentation where the powerpoint 'slideshow' wasn't a tacked on visual representation of what was being said, usually in a 'bulletpoint' fashion that only echoes what's being said. If you get chance to see the Royal Institute Christmas lectures, then take a look at their powerpoint presentations; they're conspicuous by their absence.

Which brings me to one major and almost on-topic point; if you create tools that allow people to produce dross, then they'll produce dross. Usually in staggering amounts; check out what the desktop publishing 'revolution' produced, or what the current fashion for blogging has wrought upon the English language. We should be able to run a significant portion of the grid from the rapidly spinning incumbents of graves around the world.

Re:Head in hands.... (1)

Acidic_Diarrhea (641390) | more than 10 years ago | (#7378744)

Well, by your "logic" the mouse and keyboard are also tools which allow a person to produce something that you consider to be of poor value. Using them with any piece of text editing software can produce complete garbage. Should we destroy your mouse and keyboard?

And if you've never been to a presentation where the only thing Powerpoint was used for was to display the major bulletpoints of a talk, then you've been going to some very poor conferences and lectures. Furthermore, what you're describing could just as easily be produced using overhead transparencies or a word processing program. There's no reason to abandon Powerpoint because the alternatives can just as easily be used to give the same type of bulletpoint displays. Can't you see that Powerpoint can be useful to display figures or charts? It's sad that you're so ready to blame the technology when the finger should be pointed at the user.

Re:Head in hands.... (2, Insightful)

DAldredge (2353) | more than 10 years ago | (#7380114)

All keyboards that are not IBM Model M keyboards are evil.

Don't you know anything?

Re:Head in hands.... (0)

Anonymous Coward | more than 10 years ago | (#7383543)

uh oh! disagree at all with oddly drac and he'll mark you as a foe, even if you're polite about the fact that he's irrational! oh no!! whatever will i do now! LOL!!1!1!!11

Re: Head in hands.... (1)

Black Parrot (19622) | more than 10 years ago | (#7382264)

> I'm not agreeing with the quote but what is your problem with Powerpoint? It is a tool and therefore I don't see how it can be called "evil." Typically inanimate objects don't have moral affiliations.

Typically, yes. But PowerPoint is one of those rare exceptions!

> And the fact that people misuse Powerpoint and create awful presentations does not mean that Powerpoint should be abandoned

No, for it's the evil incarnate in in PowerPoint that causes them to do so.

> Overhead transparencies can yield just as bad presentations as Powerpoint.

Yes, but they are the result of bad slide design rather than metaphysical compulsion.

Re:Head in hands.... (1)

BorgCopyeditor (590345) | more than 10 years ago | (#7383203)

It is a tool and therefore I don't see how it can be called "evil." Typically inanimate objects don't have moral affiliations.

Mr. Saturday Night Special
Got a barrel that's blue and cold
Ain't good for nothin'
But put a man six feet in a hole.

PowerPoint evil (1)

ka9dgx (72702) | more than 10 years ago | (#7378517)

While PowerPoint is evil in terms of the boiling down of the nice Red Meat of content into a Grey Goo worthy of an Army chef.... it's better than the truely evil of ... FLASH.

At least you can print a PowerPoint, look at the slides, and the notes. PowerPoint forces a nice, easy to deal with, linear structure on a Presentation.

A Flash presentation is too programmable, you never know how to advance to the next slide... and you often can't go back!


crap... (1)

josepha48 (13953) | more than 10 years ago | (#7378443)

.. there goes my job ;-)

Problem is that does anyone want to write an operating system in such a high level language, where the optimization is questionable?

Oh, and what the hell does he think MS macros are? They write themselves almost.

Operating system in high-level language? Easy... (2, Funny)

Black Parrot (19622) | more than 10 years ago | (#7382199)

> Problem is that does anyone want to write an operating system in such a high level language, where the optimization is questionable?

No problem...

main(int argc, char *argv[]){

Now go build it... (2, Insightful)

darkov (261309) | more than 10 years ago | (#7378457)

Saying software is too complex is stating the bleeding obvious. But the world is complex and it's not that easy building software, wether you're a programmer or user, that can simplify it. A clue to this is how good, user-friendly software is much harder to write.

He keeps on pushing his Intentional Software barrow, but where are the techniques that actually deliver results. Anything most programmers will come up with will be just as impenetrable as C. The problem is programmers are not known for their empathy for users and don't really want to try to find out what it means to not know how to use a computer or its software.

Re:Now go build it... (4, Insightful)

Oddly_Drac (625066) | more than 10 years ago | (#7378548)

"The problem is programmers are not known for their empathy for users"

Oh, I don't customers and I often share amusing stories of stuff that's Blue screened just before you meant to save it. If you mean that some Programmers consider themselves godlike because of years of hubris and the certain knowledge that you couldn't be found out if you cloaked as much as you could in jargon, then you might have a point.

The customer knows what they want, and they'll express it to you in their terms; you have to translate their ideas into something workable, which can be a ballache, but if you've started from a position of billable hours rather than a fixed cost, you're already ahead of the game simply because you can work on milestones rather than having to constantly rehash.

The idea of having a high-level language that 'anyone' can use has largely already happened with HTML. As a result we have some outrageously bad HTML out there because of the complete lack of understanding of abstraction. Put simply, Decamino wouldn't look through Galileo's telescope because he _knew_ that Galileo is wrong; the paradigm that allowed for the earth to move out of the center of the universe hadn't yet come to pass.

Although OO is currently viewed with some suspicion because it may not be the best way to do _everything_, everyone involved in commercial programming has at least started to view things in the terms of objects; that concept may take a while to filter down to a public that thinks animated cursors on the web are the dog's back wheels, or seem surprised when you have to keep AV software updated.

Re:Now go build it... (1)

Wonko42 (29194) | more than 10 years ago | (#7379018)

I agree with everything you wrote except for, "the customer knows what they want". That made me giggle. Teehee.

Michiavelli of Marketing Speaks (1)

4of12 (97621) | more than 10 years ago | (#7380477)

customer knows what they want

A quaint, outdated model.

In today's mass production world we already know what the customer wants.

The customer wants
to feel good about himself.

Target your pitch that way and you'll get the sheep coming in to be sheared, as you praise them for being adventurious, vigorous, attractive, and knowledgeable sheep (or wolves, if they like being called wolves better)....

Pretend to listen to your customer, because if they think you're listening to them and care about them, then they feel good about themselves and you are achieving an important objective.

Sheesh, I thought everyone knew this stuff...

Re:Now go build it... (1)

BigZaphod (12942) | more than 10 years ago | (#7378798)

Is there a reason that your sig has "i" and "j" in the wrong position? Just wondering.... :-)

VB & Delphi (1)

floydman (179924) | more than 10 years ago | (#7378491)

are there for that exact reason. I cannot think of any easier tools to use,drag and drop components,almost no coding unless necessary, espically delphi. I wont be mentioning C builder as user has to be familiar with c++ and with OOP, inheritance, overriding and all that stuff.

But he has to keep in mind that the things you do with such a tool are quite limited, the more automated the process is, the less room for inovation he has...

nothing new (3, Insightful)

mikeburke (683778) | more than 10 years ago | (#7378541)

There's a whole raft of tools out there that put this philosophy into action - witness MS Access, VB etc. Even an Excel spreadsheet can be viewed as a 'programming environment' really.

There are 2 kinds of problems that programmers solve - technical problems and business problems. The technical problems can be abstracted by tools like the above, but the business problems remain.

Techniques such as Object Oriented design, abstraction, etc etc are just as useful for solving these kinds of problems as they are, for example, when writing a new web browser.

It's difficult to see how a groovy GUI can hide or solve these problems. You're still going to need a certain set of skils to guide the development and architecture of any nontrivial system.

I'm sure we've all see complex websites that have been put together by naive users of Frontpage - bloated HTML, endless redundancy (cut-n-paste) and a hideous task for someone else (with a similar skill level) to pick up and modify. It's hard to see how you can prevent these kind of problems when you go down the "everyone can use it" path.

MS Access (2, Insightful)

Ender Ryan (79406) | more than 10 years ago | (#7378730)

Where I work, we have a guy who has done some simple "programming" with MS Access. Sure, it works pretty darn well, but at the first sign of trouble, it falls all over itself with undebuggable garbage.

Not only that, but it is entirely unmaintainable, even by him.

Real programming is a whole lot more than just pushing some buttons around.

Re:MS Access (1)

bearclaw (217359) | more than 10 years ago | (#7379372)

Sounds like your friend isn't very good at his job. I've written plenty of code inside MS Access databases and it was easy to debug and maintain.

It's just like anything else - it takes thought.

Re:MS Access (1)

Ender Ryan (79406) | more than 10 years ago | (#7379444)

It's not his job, there was just noone else available to do it.

My point was that programming isn't something that just anyone is ever going to be able to do, IMO.

Re:MS Access (1)

bearclaw (217359) | more than 10 years ago | (#7379777)

I agree that programming isn't something everyone can sit down and do.

Re:MS Access (0)

Anonymous Coward | more than 10 years ago | (#7381317)

Most people don't even understand basic logic, so trying to get them to combine structured logic of some sort with their domain knowledge, if any, is going to be "problematic".

Re:nothing new (2, Interesting)

Godeke (32895) | more than 10 years ago | (#7378951)

You hit the nail on the head when you mention Excel as a programming environment. Because the environment determines order of evaluation for you, you have a declarative language, and I think in the long run that is the key.

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.

Who bells the cat? (2, Insightful)

crmartin (98227) | more than 10 years ago | (#7378701)

Simonyi has a good point. Don't let Hungarian notation bother you -- it's a kludge on top of an essentially untyped unprotected language (C) trying to get back some of the protections offered by strong typing, and while Hungarian notation is a horrible solution, so are all the others.

But the problem is that while keeping clarity is a great idea, it's proven immensely hard to do. Fred Brooks (viz., the No Silver Bullet paper) argues that this is because the problems we're solving with software are intrinsically complex; there's no way to reduce the complexity below a certain point. On the other hand, anyone who writes real code knows that they spend a hell of a lot of their time writing the equivalent of a for loop over index i again and again and again. There's some unnecessary redundancy there.

But saying that you want less complexity is a lot different from saying you know how to get rid of the complexity.

Re:Who bells the cat? (1)

Brandybuck (704397) | more than 10 years ago | (#7379831)

There's some unnecessary redundancy there.

Don't confuse "complexity" with "details". This is the mistake that the author is making. Take for example a web server. The http protocol is complex no matter what language you write one in. With C you have to worry about buffer overflows. With Ruby you don't, but you still have to worry about invalid URLs. With C you're stuck with the drudgery of for loops. With Ruby you don't have to wade through that, but you still have to manage your server threads or processes. The complexity is still there, even though you're no longer worrying over the trivial details.

Building a house is a complex task, whether you forge all your own nails or buy them in bulk.

Re:Who bells the cat? (2, Insightful)

crmartin (98227) | more than 10 years ago | (#7380836)

Yes, exactly. There is some redundancy in the way we code, but the complexity is not just in that redundancy. There are some hints of the intractability of reducing complexity in Greg Chaitin's algorithmic information theory.

It could work. (1)

kabocox (199019) | more than 10 years ago | (#7378710)

Let see what to do we need to really make this work.
1 Truely intellegent AI.
2 AIs that think humanity needs to be "helped."
3 AIs that can read MBA's Minds and/or regular users.
4 AIs that can seemlessly transform those thoughts/ abstract business practises into a workable solutions.
5 I for one will welcome our AI overlords that will automaticly write all our business, government, & personal policy.
6 We will be in the Sims where the computer controls us!
7... Humor & Fun for the AIs.

Stuff and Nonsense. (1)

the eric conspiracy (20178) | more than 10 years ago | (#7378712)

Riiiighhhtt. So who is going to write this 'programming environment for idiots?" Surely it must be recognized that you are just moving the complexity problem to a different layer with this approach, PLUS losing the ability to gain low level access when needed.

Meta complexity? (4, Interesting)

FunkyRat (36011) | more than 10 years ago | (#7379385)

Surely it must be recognized that you are just moving the complexity problem to a different layer with this approach, PLUS losing the ability to gain low level access when needed.

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 [] .

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."

Re:Meta complexity? (1)

drgnvale (525787) | more than 10 years ago | (#7381423)

Two things... 1)_Damn slashdot for only giving me mod points when there are worthless posts, and not when posts like this one show up, and 2) Don't forget lisp.

Re:Meta complexity? (1)

joto (134244) | more than 10 years ago | (#7382788)

Was this just a typo, or was it intentional?

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.

Look at the 12th word.

Re:Meta complexity? (1)

FunkyRat (36011) | more than 10 years ago | (#7383235)

ROTFL! No, it wasn't intentional! I hope you know I meant present. You'll have to excuse me, I'm doing Slashdot today like Rush Limbaugh does his radio show -- I'm taking hyrdrocodone for a knee injury. On top of it all, I have this miserable stinking cold!

Re:Meta complexity? (1)

the eric conspiracy (20178) | more than 10 years ago | (#7382807)

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).

All coolness, but how does that eliminate the need for humans to deal with complexity? It's still there at some level in the system until you build a system that can eliminate complexity adaptively. When you do that there will be no need for human beings any more.

Re:Meta complexity? (1)

FunkyRat (36011) | more than 10 years ago | (#7383303)

Well, actually, in a way, that was my point or at least a corrolary to my point.

We can do really cool things to manage complexity and still make computers useful tools for the general populace. I agree with Simonyi's arguement that more needs to be done in this area.

However, at some point, people must be ready to accept the fact that power brings with it complexity and if they wish to do grander things then they need to be willing to learn. Most people aren't willing to do so. Yet for the few who are, the tools should be there.

Re:Stuff and Nonsense. (1)

Paradise Pete (33184) | more than 10 years ago | (#7379718)

This sig no verb.

This reply has no

Complexity Arises from Customization (2, Insightful)

mugnyte (203225) | more than 10 years ago | (#7378786)

People want to make the world in their image. So, they hot-rod their cars, paint their rooms new colors and ask for new software. That software need to do something that hasn't been done *and published in a coherent way* before. So the programmers delve into the details of APIs and language capabilities and create complexity.

Also, the migration between new hardware, capabilities (higher bandwidth, wireless) or goals (FPS gaming) and such are always going to create a complex "first example" that need many iterations before commodization.

I think this guy is premature to assume all programming goals are easily commoditized right now. If people were to give up behaviors when the plug-ins given to them don't exist or are buggy, thee'd be a lot of hodge-podge solutions.

Example: Visual Basic programming was supposed to be a "glue" for clicking together COM ocmponents, and MS was touting a new era of component "publishers" and "subscribers" (and next up is the same thing via .NET and web services) We all know how Visual Basic attracted lots of newbie programmers without formal degrees who clamored to read Compu-Mags for tips, and MS beefed it into a full-fledged development environment (compiled exe's, generate COM natively, getting away from variants). It has solved many problems, but didn't create a world of commodization as hope (even if there are 100's of OCX vendors in those same Compu-mags)

But it just doesn't happen in the long run. You can buy enterprise that does thing from soup to nuts and still find tons of work in "making it your own" with interfaces, reports and other customizations (talk to an SAP project manager).

Anyway, this is an interesting topic, but ultimately limited.

good intentions misguided (0)

Anonymous Coward | more than 10 years ago | (#7378800)

That all sounds good until you take into consideration that most people do not think logically. Given that applications/programs work within well defined logic, how the hell are you going to translate an MBA's gibberish into reliable executable logic. Part of the job of programmers is educating the business guys and finding a workable/sane middle ground. Really, that makes as much sense as saying "building cars is too complicated and fixing them is even more complicated. Therefore we should give everyone a way to tell the factory exactly what they want and have the assembly line make it."

Sometimes people with good intentions go wrong, very wrong.

Removing software complexity... (+1 long-winded) (1)

Cool Hand Luke (16056) | more than 10 years ago | (#7378808)

... is a laudable goal, for sure but I don't see Simonyi's purposed solution as the end-all solution to eliminating complexity to software. If I understand this set of tools correctly, Simonyi is purposing a way to map software designs to actual code, which can be platform dependent.

Two lines in the article jumped out to me:

"When these tools are developed..."

Exactly, when these tools are fully developed, all will be milk and honey. I have to wonder how long is would take to develop a set of design tools that is encompasses both a wide range of design patterns and a wide range of platforms.

  1. To what extend is there a limit to the set of possible software architectures based on the modeling tools' abstractions and UI paradigms? For example, does a traditional icon-based UI hinder diagramming designs that involve dynamically created classes and objects? (Just a hypothetical question; the answer is irrelevant to my point.)
  2. What is the scope of the type of platforms abstracted away by this tool? Can I design stand-alone, UI applications, embedded software, and n-tier J2EE systems with the same tools? How tractable is the problem of designing design tools flexible enough to encompass all possible development platforms?

"But Simonyi's colleagues and competitors have their own, often very different ideas about how to use modeling to save software from the burden of its increasing complexity..."

With a number of competitors in the same marketplace, wouldn't there be pressure to be first to market with a tool that isn't all-encompassing of either design patterns and/or platforms. More to the point, I suspect Simonyi's solution will involve a certain amount of lock-in from the end-users either in the design patterns and/or platforms used. Some of this lock-in could be from necessarily of keeping the scope of the tools manageable. (For example, only supporting Java-based applications and systems might abstract away all Java-supporting Operating Systems from Simonyi's tools.) However, some of this lock-in might be based on economic or philosophical reasons. (For example, the design tools might only support a VM that Simonyi's company happens to build, or design patterns people within Simonyi's company have a fetish for.)

The long and short is I suspect any set of design tools that come out of the wood work, whether from Simonyi or others, will have some lock-in built into them.

A final thought: I personally believe Newton's quote: "If I have seen farther than others, it is because I was standing on the shoulder of giants." aptly applies to all engineering endeavors. Technology makes strides and improves because of continuous efforts on humanity's part to build upon and improve on previous work. I think Simonyi's purposed work will, at best, abstract away the task of converting a particular software design to actual code. However, Simonyi has then only provided a platform for much more complex designs, instead of eliminating them. Software engineering may move farther away from platform-specific coding, but the design aspects still remind, and will be expanded upon.

All that being said, as a long time Macintosh user, I wish him the best of luck. ;)

COBOL (3, Insightful)

aridhol (112307) | more than 10 years ago | (#7378817)

Wasn't COBOL orignally written in order to allow the user to bypass the programmer? One of the lessons they learned from that experiment was that, even given a simplified language, most people don't understand computers well enough to write a program.

I'm not saying things like API obfuscation or similar. I mean people don't generally think logically. Computers don't think emotionally. The average person has no idea about algorithms, or why you may want an O(lg(n)) algorithm in preference to an O(n^2) algorithm.

For these things, professional programmers will still be required.

Re:COBOL (1)

dubious9 (580994) | more than 10 years ago | (#7380960)

I think the point that the article was about was lessening the need for software engineers in favor of process/algorithmic engineers. Processes are still very complex and require intellegence and education to solve efficiently. It's the difference between writing quick sort in puedo-code or whatever and actually implementing in a language where you need to worry about implemention details. It's those details which really tend to be bothersome. If they can find a way to make "psuedo-code" executable, or a system that's ~100% business logic, that would make complex system design a heck of a lot easier. And thus, if it's all business logic, then non-programmers should be able to go in and change it. That however is still non-trival and hence the new term "process" engineer.

Re:COBOL (1)

kisrael (134664) | more than 10 years ago | (#7381438)

Yeah, I don't think people would even be that good at writing pseudocode. Even before they get to worrying about details like performance and efficiency, the fact is most people are poor at breaking down tasks, even the ones they do all the itme, into small enough pieces that even a computer could do it.

In short, I don't think something like this will happen until we really get AI going. What this guy propses looks at first glance like a visual tool for what COBOL was supposed to be, first glance meaning the example they gave.

Re: COBOL (1)

Black Parrot (19622) | more than 10 years ago | (#7382102)

> Wasn't COBOL orignally written in order to allow the user to bypass the programmer? One of the lessons they learned from that experiment was that, even given a simplified language, most people don't understand computers well enough to write a program.

In my experience, most people don't understand what they're trying to do well enough to write a program, let alone understand 'computers' well enough to write it. I've lost count of the number of times I've had to explain to a PHB that it's useless to generate reports that total the number of pounds, pallets, and railcars (all together) of all the apples + oranges (all together) that shipped last month.

The reason there's no silver bullet for programming is that the problem doesn't lie in the programming languages; the problem lies in the problems we apply programming languages to.

You can teach a moderately intelligent person everything there is to know about the sytax of Scheme in half an hour, but even experienced programmers still tend to have trouble thinking out how to write useful programs in it.

A decade ago the trade journals were chock full of articles about nifty "fourth generation languages" that would let PHBs cut programmers out of the loop, and we all know how that turned out.

Software should be as easy to edit as a PowerPoint (3, Funny)

cheezus (95036) | more than 10 years ago | (#7378864)

"Software should be as easy to edit as a PowerPoint presentation"

oh great, now nearly every app is going to have a random ass ugly transtion between user interfaces, will use no fewer than 20 fonts, and have clipart everywhere. You will have to wait for each line of the EULA to slide, spiral, disolve or some other animation it's way onto the screen before you can click ok. Not only that, the application will surely present no other information than reading the bullet points to you.

Re:Software should be as easy to edit as a PowerPo (1)

lowmagnet (646428) | more than 10 years ago | (#7379313)

Also, ever object will start out a vomit-green colour.

what a horrible idea. (0)

Anonymous Coward | more than 10 years ago | (#7378948)

Let's take this one and run with it, shall we?

Everyone's a Terrorist
Arms races are collapsing under the weight of their own complexity. Charles Simonyi's solution? WMD's that are so simple that even laypeople can use them....

It's not the tools it's the specs! (1)

bhima (46039) | more than 10 years ago | (#7379137)

I'd have to say that by far the problem is not the development tools we use. I've used GCC and cosmic (for HC11,12 & 68332) and some ridiculous proprietary IDE for the Hitachi H8S series. I'll have to admit that I'll take vim over these IDEs but JTAGs, BDMs are great. What causes the most problems? Feature creep and the odd attachment management types have to old crufty code. (I supposed they think they paid to much for it).

Currently my favorite hobby is ripping out code for old models or features which marketing has finally admitted no one uses (except of course the marketers at conventions and sales calls) which happen to be the features that were implemented with least thought, specification or clear design. It's surprising how much easier it is to remove code to achieve stability than add code to do the same. It's like re-factoring only better (less filling / tastes great).

So my point is a good compiler, and good debugging tool and VI is fine.

Now I don't do overlapping windowing apps, so I can't comment on the misery these developers must face :)

Re:It's not the tools it's the specs! (0)

Anonymous Coward | more than 10 years ago | (#7381970)

Feature creep and the odd attachment management types have to old crufty code.

Yeah. Oh God yeah. A LOT of code complexity arises from management instructions like "add n to the system". When you point out to them that the system doesn't support n, they say, "well yeah, that's why you need to add it". So you build a half-assed n and hang it somewhere and hope to God it works, and spend the next six months keeping it alive.

And when you brief somebody else on what you did, you'll have the joy of explaining yourself.

familiar? (1)

ameoba (173803) | more than 10 years ago | (#7379185)

Something about this article seems familiar, but I'm not sure where I saw it before. It makes reference to using UML as a 'easy-to-understand interface' for desigining programs.


Essentially, what his idea comes down to, is finding representations that are more removed from what's going on under the hood, such as using pictures to represent program flow instead of the current textual representation. This is not only an old, established idea, but completely bypasses the fact the the fundamental difficulty in designing software is coming up with formal specifications.

Take his example of turbine blades; he states that " you were to use the most meticulous craftsman to make them, you still wouldn't get anywhere near the degree of accuracy you need". Unfortunately, turbine blades are still designed by highly skilled engineers; what he wants to do is give somebody the ability to say "I want a fan-like-thing that moves a big metal bird" and have a jet engine pop out.

Bored Billionaire Syndrome (0)

Anonymous Coward | more than 10 years ago | (#7379265)

I just dimiss this guy (as revolutionary as his achievements were 20-30 years ago) as a bored billionaire. He's thinking "why not personally fund an basically unsolvable problem for a while?" It's good press. And I'm sure he's intelligent and -will- learn and/or create a few things along the way. Shits and grins.

He wants to eliminate code, not design. (1)

dstone (191334) | more than 10 years ago | (#7379418)

Unfortunately, turbine blades are still designed by highly skilled engineers

Exactly. Once the highly skilled engineers design the blade, he wants to ensure that a bunch of hamfisted craftsmen and welders and such don't screw up the implementation with mistakes, sabotage, job-security-slackness, labor negotiations, etc.

Simonyi says he wants the code to "look like the design". There is still a role for the designer.

what he wants to do is give somebody the ability to say "I want a fan-like-thing that moves a big metal bird" and have a jet engine pop out.

No, I don't think he's trying to translate vague human requests into code. He wants the user to become the designer or modeller, and the tool to become the code-monkey. He wants the user to create the design with GUI tools and reusable components (like PowerPoint, he says -- dunno about that), which is going to require the user to think about requirements and interfaces (hmmm, good luck) but not the code or maintenance. He doesn't envision replacing the role of designer or the model. I thought the article made that clear. But he does want every "user" to be a designer/modeller. Ugh. Not so sure about that one. ;-)

Re:familiar? (1)

Brandybuck (704397) | more than 10 years ago | (#7379889)

Ever seen a simple UML diagram for any real world solution? I haven't. UML wasn't designed to be simple. It was designed to that you could design complex software without worrying about the trivial details of implementation.

Unfortunately, even the UML advocates tend to forget this. I remember a Rational saleman giving a presentation at my work. "Look how easy this is," he said, as he brought up the UML diagram for Rose itself. Ick!

it's already there (1)

kipple (244681) | more than 10 years ago | (#7379402)

it's called visual basic.

if it just wasn't for all those script kiddies exploiting vulnerabilities of such a beautiful language.. let's hope they make script kidding illegal with the next version of the Patriot ACT, codenamed LongCorn..

XUL, XUI, XFORMS, XAML ... (2, Insightful)

Bazouel (105242) | more than 10 years ago | (#7379548)

... all of those technologies make designing simple apps a piece of cake. Shouldn't be that hard to make a visual IDE for newbies that generates those XML.

The perfect utility (2, Insightful)

Slowping (63788) | more than 10 years ago | (#7379604)

Someone just needs to write a program that users can run, to check and make sure that the target program runs correctly!

(yes, I'm joking)

But that's why we have FORTRAN! (1)

dpbsmith (263124) | more than 10 years ago | (#7379616)

That's exactly what FORTRAN does. You don't do any programming yourself, you simply describe the problem you want solved in a natural, easy-to-learn language, and the FORTRAN compiler writes a bug-free program that implements the solution.

If you're not using FORTRAN, you're wasting time and effort. Why, when you write a single line of FORTRAN the FORTRAN compiler writes an average of ten lines of code for you, so you become ten times as productive and can get projects shipping and earning revenue times as fast. And is it ever good code! Why, it's 99 and 44/100% as efficient as the very best hacker-tweaked assembly language. FORTRAN even puts the instructions on the drum for you in the best locations for optimum access speed.

(If you personally happen to dislike FORTRAN, then substitute The Last One, or DELPHI, or Visual Basic, or LabView--that programming language where you drag icons around and "wire" them together... it doesn't matter, the claims are always the same, including tenfold productivity boosts)

Compexity misunderstood (2, Interesting)

Brandybuck (704397) | more than 10 years ago | (#7379677)

"Software should be as easy to edit as a PowerPoint presentation," Simonyi asserts.

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? (2, Interesting)

BigGerman (541312) | more than 10 years ago | (#7380431)

there is a framework [] where they believe in exposing the business objects inside the app to the end user. Kinda like spreadsheet / powerpoint but the real deal.

Noggin' up backside (1)

jo42 (227475) | more than 10 years ago | (#7380573)

> "Software should be as easy to edit as a PowerPoint presentation"

Allrighty then. Hide the complexity at the surface level. Put the complexity where it can't be seen - behind the scenes. And just how have we improved things? All we have done is move the complexity to somewhere else. Don't fix that hole in the wall, just paper and paint over it. Idiot.

NYTimes: Powerpoint and the shuttle disaster (3, Interesting)

Anonymous Coward | more than 10 years ago | (#7380817)

This is from late September, so unfortunately there's no direct link to the full article at nytimes anymore.

The Level of Discourse Continues to Slide
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






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 include it.

"We're proud of it," he said, pointing out that the product is simply a tool -- "a blank for you to fill in" with ideas and information.

"I feel like the guy who makes canvas and the No. 2 green viridian paint," Mr. Leach said. "I'm being asked to comment on the art show."

His point is shared by plenty of people who say the criticism of PowerPoint is misdirected. "The tool doesn't tell you how to write," said Bill Atkinson, the creator of HyperCard, an earlier program considered by many to be the precursor to PowerPoint. "It just helps you express yourself," he said. "The more tools people have to choose from the better off we are."

It's likely, then, that PowerPoint is here to stay -- everywhere. And not always for the worse. At the wedding reception of Lina Tilman and Anders Corr last year in New Haven, guests made two PowerPoint presentations. They were everything that slide shows usually are not: wry and heartfelt works that used the tired conventions of the form to poke fun at the world of presentations and celebrate the marriage.

NASA apparently still lacks a similar sense of irony. Earlier this month, the space agency held a three-day workshop in Houston to give reporters a firsthand view of its return-to-flight plans. Included in the handouts were dozens of PowerPoint slides.

Cat and the Bell (1)

Quill_28 (553921) | more than 10 years ago | (#7381149)

Reminds of the fable where mice want to be protected so they decide to put a bell on the cat, that way it can't sneak up on them.
Great idea! Except of course who is going to put the bell on the cat?

Yes, I would love software that could do everything he wants. Now who is going to write it? Will it collapse under it own weight?

Give him a lollipop (1)

Sir Robin (9082) | more than 10 years ago | (#7381271)

This reminds me of a quote from the fortune file:
When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
In other words, figuring out what you wish done is the hard part. Automating the requirments gathering process won't change that. Try to desribe in words a computer can understand how to peal a banana. Describe how to pick up the banana. Describe how much pressure to apply. Describe what to do if the banana is too squishy at the top for the peal to break open. Etc, etc, etc, ad nauseum.

That said, the objection to the "power point" line is at least a misinterpretation. Software should be as easy to edit as a PowerPoint presentation. Not as easily written, mind you, just as easily edited. I wouldn't object to a more powerful editor. But, will it work with Vim? ;)

Software == PowerPoint? (1)

Frambooz (555784) | more than 10 years ago | (#7381564)

"Software should be as easy to edit as a PowerPoint presentation," Simonyi asserts.

In that case, software should ship with its own slow, monotone narrator that reads ALL the words on the screen so it's hard not to doze off after five seconds. Great.

Oh wait... my OS already has that. Microsoft Narrator.

(P.S. Can't wait for my dialog boxes to slide in from left to right -- or better yet... rotation!!! oh boy oh boy.)

Quote: "making the code look like the design" (2, Funny)

idontgno (624372) | more than 10 years ago | (#7381579)

Hind's [] 7th Law of Computer Programs:

Make it possible for programmers to write programs in English, and you will find that programmers cannot write in English.

Did anyone else... (1)

idontgno (624372) | more than 10 years ago | (#7381625)

misread the title of the story as "Removing Software Completely" and get enthused about a new technique to comprehensively uninstall crappy software from Windows?

You may commence the usual /. geek-bigot joke answers: "fdisk", "install (linux|bsd|beos)", etc.

No incentive to make software simpler. (0)

Anonymous Coward | more than 10 years ago | (#7381724)

Software is complex because people want it to be complex.

When software is fast enough, users want to move knowledge from the user to the program. This inevitably makes the program more complex.

When software is too slow, users want it faster (or faster machines).


There is no incentive for making software simpler. It mainly happens in efforts to increase speed, or from personal programmer pride.

None of this will ever remove the programmer from the loop. programmers are those people who best translate ill-defined, vague, contradictory, requirements into something a computer can run. New programming systems or languages or editors make things easier for everybody. The best are still the best, and likely still worth hiring.

Re:No incentive to make software simpler. (0)

Anonymous Coward | more than 10 years ago | (#7382422)

Software is complex because people want it to be complex.

Software is complex because most people can't think abstractly enough to make it simple!

Who... (1)

whitefox (16740) | more than 10 years ago | (#7382525)

Who programs the programmers?

Hey TACO (0)

Anonymous Coward | more than 10 years ago | (#7383062)

Get that cock out of your mouth, you don't know where that's filthy bastard.

they're on the same level (0)

ChipMonk (711367) | more than 10 years ago | (#7383468)

Real marketers use a professional media production company. Wannabes (think Stef Murky) use PowerPoint.

Real programmers understand the data flow behind their language. Wannabes use Visual Basic.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>