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."
m_lpstrnzCharlesSimonyi (Score:4, Insightful)
Google for "the tactical nuclear weapon of code obfuscation" to receive further enlightenment [mindprod.com]
Dave
Simonyi (Score:3, Insightful)
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 (Score:5, Insightful)
Now go build it... (Score:3, Insightful)
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.
nothing new (Score:3, Insightful)
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.
Re:Now go build it... (Score:5, Insightful)
Oh, I don't know...my 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.
Who bells the cat? (Score:3, Insightful)
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.
MS Access (Score:3, Insightful)
Not only that, but it is entirely unmaintainable, even by him.
Real programming is a whole lot more than just pushing some buttons around.
Complexity Arises from Customization (Score:3, Insightful)
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
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.
COBOL (Score:4, Insightful)
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.
XUL, XUI, XFORMS, XAML ... (Score:2, Insightful)
The perfect utility (Score:3, Insightful)
(yes, I'm joking)
Re:m_lpstrnzCharlesSimonyi (Score:2, Insightful)
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:Head in hands.... (Score:3, Insightful)
Don't you know anything?
Re:Who bells the cat? (Score:3, Insightful)
Real programmers will still have jobs (Score:4, Insightful)
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.)
Re:m_lpstrnzCharlesSimonyi (Score:2, Insightful)
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:Sounds familiar... (Score:3, Insightful)
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.
VB/Access/Cobol/Simonyi: No silver bullet! (Score:5, Insightful)
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.
Exactly.
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 languages...it'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 ;-)
Complexity is caused by slow computers (Score:4, Insightful)
Calculating a differential query means that you modify the outcome of a query based on how the data changed instead of reexecuting the whole query.
Re:COBOL (Score:3, Insightful)
Interesting. And really, learning to do break up tasks of fairly great complexity is probably 75% of programming...once you got that, most of the rest is just details.
Personally I think this ties into a fallacy the vast majority of us share, that we are essentially rational beings, that all of the things we do in life could be traced down to logical decisions, maybe even the binary firings of clusters of neurons. Really, I think we're just gigantic cluesters of ad hoc heuristics, and attempts to describe our thoughts as logical processes are just optimistic, post facto mappings to what we would've done, if we had the time to think about it. (And there is some experimental/clinical evidence for what a great after-the-fact story teller/rationalizer our brains are...)
Development is about abstraction (Score:3, Insightful)
The history of programming is the movement from physically inserting patch cables to program a computer to manipulating abstractions. In languages like C, those abstractions are still pretty close to the hardware; in OO languages they tend to be closer to the problem domain. Edsger Dijkstra once said that software development was unique as a profession because it required practitioners to operate at 7 levels of abstraction - from transistor to algorithm to software architecture to business domain. Of course, very few of us deal with "transistor-level" programming these days.
So, Simonyi's "intentional" programming is part of this broad sweep of improvement in programming languages in the last 50 or so years. The current emphasis behind Model-driven architecture [omg.org] is a similar desire to somehow take away all that messy code stuff and replace it with nice, easy to understand pictures.
The problem with both these approaches is that complexity exists inherently in the problem domain. The role of a software development team is to chose a path through that complex problem domain and implement it with working code. Right now, I don't believe we have tools which are sufficiently expressive and intuitive to model the complexity of the problem domain, and we must be years if not decades away from being able to convert such models to working code.
UML is lovely - it's a great language for expressing software ideas and conveying a lot of information in a graphical format, but the average business user just does not get it; in my experience they are primarily useful for communicating between developers.
Use cases (in textual form) are far more useful for communicating with business users, but to convert a usecase into a working program would require natural language parsing at a level that must be a generation away.
We should wish Simonyi luck - his ambitions are worthy, and will benefit all working developers if they bear fruit. And what better use to put a couple of billion dollars to ?
Re:Software should be as easy to edit as a PowerPo (Score:2, Insightful)
another way to put it..
Everyone can write a novel, but it takes good writer to write a good novel.