Slashdot Mirror
Removing Software Complexity
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."
If everyone could do it, I wouldn't be doing it.
Didn't Apple have some QuickCard thingy for a while. I recall them touting it as programming for the everyman...
----------- Sig what?
The self writing book report.
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
Dave
I write a blog now, you should be afraid.
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.
"Provided by the management for your protection."
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?
...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.
Oddly Draconis
Too cynical to live, too stubborn to die.
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.
Only 'flamers' flame!
Does slashdot hate my posts?
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.
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
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...
The lunatic is in my head
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!
--Mike--
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.
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.
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.
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.
Not only that, but it is entirely unmaintainable, even by him.
Real programming is a whole lot more than just pushing some buttons around.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
How to write a program in AppleScript:
(Okay, okay, well, Mac users will get the joke.)
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.
.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)
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.
Sometimes people with good intentions go wrong, very wrong.
... 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.
"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. ;)
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.
I can't say that I don't give a fuck. I've just run out of fuck to give.
"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.
/bin/fortune | slashdotsig.sh
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....
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 :)
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
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.
Please.
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.
my sig's at the bottom of the page.
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.
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.
Also, ever object will start out a vomit-green colour.
Heute die Welt, morgen das Sonnensystem!
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."
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..
-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)
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.
... 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.
Intelligence shared is intelligence squared.
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)
(\(\
(^.^)
(")")
*beware the cute-bunny virus
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)
"How to Do Nothing," kids activities, back in print!
"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.
Don't blame me, I didn't vote for either of them!
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.
I thought AppleScript was basically Visual Cobol...
customer knows what they want
A quaint, outdated model.
In today's mass production world we already know what the customer wants.
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...
"Provided by the management for your protection."
> "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.
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
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.)
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
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?
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?
My
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.)
No encryption can withstand the power of the Lucky Guess.
Make it possible for programmers to write programs in English, and you will find that programmers cannot write in English.
Welcome to the Panopticon. Used to be a prison, now it's your home.
You may commence the usual /. geek-bigot joke answers: "fdisk", "install (linux|bsd|beos)", etc.
Welcome to the Panopticon. Used to be a prison, now it's your home.
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).
Iterate.
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.
> Problem is that does anyone want to write an operating system in such a high level language, where the optimization is questionable?
No problem...
Sheesh, evil *and* a jerk. -- Jade
Who programs the programmers?
Get that cock out of your mouth, you don't know where that's been....you filthy bastard.
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 ;-)
Professional Wild-Eyed Visionary
Real programmers understand the data flow behind their language. Wannabes use Visual Basic.
Charles Simonyi was the man at Microsoft that tried to answer the complexity of Microsoft's software with more complexity.
Now hearing a statement like this from him sounds hardly convincing.
And... do we really want a programming language so simple everyone can use it? I thought Visual basic and VBA tought people very well that we do NOT want it!!
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.
Software should be as easy to edit as a PowerPoint presentation
;)
I don't know... I'm capable of programming in a handful of different languages. But I've never been able to spend less than three hours on a bloody PowerPoint presentation and produce more than a single slide.
I say programming is much simpler
May we live long and die out
I work in an accounting department and the average accountant doesn't understand basic data modeling. If you can't define your data and its relationships how are you going to build systems around it? I know, lots of word and excel documents.
What is he trying to put me out of a job. :)
...but it's good to try it out. The more the complexity grows the more work ist to be done when you want to upgrade things or simply fix an error. Take a look at a programming language as easy to read as e.g. ABAP/4. It's almost readable as a plaintext but still you can build extremely complex software. ;)
If you have a IDE that allows you to abstract the coding from the semantic significance, it makes your code more easy to understand. If you have different levels of abstraction (like some diagrams in UML) and your IDE supports working in higher abstractions and not just viewing, you can build new things on a more abstract and therefore easier level.
But to achieve that either every project has it's own levels and definitions of abstraction levels or it has to be built in the programming language itself. But both possibilities will increase the complexity of the abstractions. So no easy going...
From the article:
What, exactly, would a machine for writing software look like? It would itself be software.
Well, I call mine a "compiler". They're not new.
My Karma: ran over your Dogma
StrawberryFrog
To answer your question, two years ago i started thinking along these lines. i went a bit further than most...i sat down and implemented tools to do exactly this. I developed them for my own internal use since i build a wide variety of one-off platforms and i manufacture embedded systems. i still use them two years later because nothing even comes close to the power i get from my platform and the speed of development.
To what extend is there a limit to the set of possible software architectures based on the modeling tools' abstractions and UI paradigms?
1. If developed correctly there should be no limits whatsoever. In practice, my tools limit me in two ways.
[a] They are slower than traditional approaches due to the overhead of interpretation (even with precompiling).
[b] Less data can be handled dynamically and real time data streams are hard to handle. sometimes working with delegating real time to a dedicated C program and letting is talk in non real time to the tools is best.
2a. What is the scope of the type of platforms abstracted away by this tool?
any platforms can be abstracted as long as they fit into the traditional input->compute->output paradigm (which mostly all do, since everything in computer systems uses a turing machine model. You are using a CPU after all).
2b. Can I design stand-alone, UI applications, embedded software, and n-tier J2EE systems with the same tools?
i've designed and implemented (well actually designed only since my tools do the implementation for me) web based shopping carts, n-tier database/app server backed load balanced financial apps for brokers, stand alone UI applications, embedded systems (not just software..entire systems with hardware interfacing) with my system.
2c. How tractable is the problem of designing design tools flexible enough to encompass all possible development platforms?
its not that difficult. its a pain when handling hardware devices but other than the obvious pain of writing drivers, its not hard. i've run my tools on AIX, Solaris, IRIX, Linux, BSD, Windows 3.1, Windows 95, DOS, QNX, Novell, Windows 2000/NT/XP, AS/400s.
So it is doable. will everyone do it ? nope. it takes time and money to do it and no one has the time or money. its a hard sell to develop this for businesses. i developed it because i need it (and it continues to be developed and used 2 years later..chances are it will take 20+ years before it has everything i want in it). will someone pay me money for it ? not on your life. on the other hand the systems i develop with it do sell. whats ironic is that if i sold the system to my customers they could implement the same platforms i sell them at a fraction of the cost of each individual unit. but i know i can never sell it to them since they'd never buy it.
Classic example, floating point arithmetic is complicated because it is inexact, so = doesn't work like you hope. Every so often some-one has the bright idea of building a tolerance into =, so that it works like it should and programming becomes simpler.
So you still have to be aware of rounding error and build a bigger tolerance into your code when appropriate, but now you also have to cope with a non-transitive = so sometimes a=b, b=c, yet c != a. Over-simplifying made it more complicated.
Second example, SOAP, the Simple Object Access Protocol, uses the same port as http. This make things simpler for the system administrator. He doesn't need to open an extra port in his firewall to let SOAP through. How does he block SOAP without blocking http? Ah well, simplifying things has made them awfully complicated.
Mega-example: You have two distinct concepts in assembler, skipping optional code, and choosing between alternatives
TEST
COND JUMP skip
OP1 optional code
OP2
skip: OP3 mandatory code
etcetera
TEST
COND JUMP alternative
OP1
OP2
JUMP rejoin
alternative OP3
OP4
rejoin OP5
etcetera
We could have had language keywords opt(ional) and alt(ernative) which would look like this
opt(boolean)statement;
alt(boolean)statement1;statement2;
but to make things simpler, languages just have one word keyword, if, instead of two, opt and alt.
So they look like this
if(boolean)statement;
if(boolean)statement1;else statement2;
Except of course they don't. There is now a dangling else problem, so we all resort to defensive programming and write
if(boolean){
statement;
}
or
if(boolean){
statement1;
} else {
statement2;
}
Computing would be a lot simpler if we were more understanding and accepting of complexity. Then we could concentrate on spotting and reducing the complexity we can do something about, rather than adding to the complexity with misguided over-simplifications.
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,
So? You could have been bitten buy assuming that a function called IncrementValue() doesn't divide the value by 12. You could have been bitten by assuming that the comment above the function accurately describes the contents. There is no programming technique whatsoever that can stop you from being bitten by the mistakes of dumb cow orkers.
This does not mean that meaningful function names, accurate comments and a judicious amount of type info in var names are bad things.
My Karma: ran over your Dogma
StrawberryFrog
I had already thought of it: a PowerPoint Compiler!
Drag'n drop those images of people, businesses and tasks. Draw arrows between each. Use as many slides as you want to detail the flow of operations. Then hit F5 to have the compiler spit and exec your new application!
And abstraction is the fundamental means of reducing complexity.
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 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 ?
It's all very well in practice, but it will never work in theory.
No discussion of PowerPoint is complete without checking out http://www.norvig.com/Gettysburg/
very well put.
another way to put it..
Everyone can write a novel, but it takes good writer to write a good novel.
This sounds like a really complicated program... how should we write it?... Oh.... shit!
In my short career so far I've worked with two "languages" that are making progress toward ease of understanding and user-friendliness: Python and LabView.
With Python I've been able to quickly write applications in much less time than in C/C++, the code is easy to read and looks like the pseudo code I'd write if I were going to implement something in another language.
Labview, although I only loosely consider it a programming language, is a great tool for the hardware folks I work with who wouldn't dare touch a "real" software language. It's pretty amazing what someone can do through it just by dragging boxes around and drawing the lines between them.
Both have helped to ease some of the pain of writing software for me, and I'd suggest them as good foundations for making software development less complex.
I had in mind the older and less fuzzy definition of "declarative language", meaning one that is not Turing complete because there it lacks explicit conditionals, loops, and recursion.
For instance, BNF is used to specify grammars, yet context free language parsers can be generated automatically from those grammars (e.g. with yacc). Thus BNF is an extraordinarily powerful language, but it doesn't specify algorithms, it just declares the grammar -- and is not Turing complete.
If BNF is augmented with the ability to do grammatical parsing based not just on input tokens but also by conditionals on arbitrary memory locations, then it becomes Turing complete (because it is then an Augmented Transition Network).
People who like fuzzy terminology would no doubt still call that a declarative language, but they've taken away an otherwise perfectly good category name for things like BNF. Is there some other terminology I've overlooked/forgotten, or am I going to have to start saying "Turing-incomplete declarative languages"??
Foldoc, BTW, has its imperfections, including that it does not bother to comment on multiple usages, as in this case, or the one I noticed last week: "algorithm" as diametrically opposed to "heuristic" -- whereas it's quite common for people to mean "algorithm" as including "heuristics" as a proper subset.
Professional Wild-Eyed Visionary
Simonyi still believes only a handful of super/uber geniuses can design software, but once that designs done, a standard office weenie can build it.
He believed that back in PARC, he took that belief to Microsoft where it failed utterly, and still thinks so today.
and he's still wrong.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
That's when I started to look for another solution, and found Linux -- which has never, obviously, been pure BSD-like, but did always include enough BSD stuff rather than exclusively SysV side of the world to make me happy.
Professional Wild-Eyed Visionary
Software is already easier to edit than with Powerpoint.
I can do it with notepad.
Very strange that this article doesn't even mention MDA (Model Driven Architecture) which promises to generate code from UML models.
Apple's long neglected HyperCard was the only development environment in which children were developing applications in very soon after they could read.
A descendent of it exists in the form of "Runtime Revolution" , but even runrev has suffered feature creep, and isn't nearly as elegant and intuitive as HyperCard was.
Software development and complexity is staying about static. The tools that we use today I would have been astounded 20 years ago but the reality is that I am now developing more complex programs and my users want more than they ever have. 5 years ago I had never written a threaded program, today I would never write a program without it. I could have ruled the world with a simple word processor when I started (pcwrite anyone) now I have to have all the bells and whistles like tool bars, menus, fast keys all on programs that simply balance your checkbook.
I started using Borland Builder. I was astounded by the simplicity of the application. I developed suites of programs in weeks that I had on the backburner for years. Then the boom dropped, the users wanted better error handling, etc. I had to start subclassing the VCL components and bending them to my (or my users) will. Suddenly those clean simple plug and play programs blossomed to a complex program.
What about tools like Borland Builder and VB leading developers into temptation. The road to all evil I have found is the simplicity of adding code to a button on the screen. The programmer stops designing their applications and just building them as they go. Portability lost, clean intefaces gone, and modifications are now complex impossibilities.
I love the golden bullet, I beleive that better tools like Borland Delphi will continue to hide the horrors below the surface of programming through clean concise interfaces however the bar will shift higher, expectations will move and there will always need that logical structured mind to make something that will last and not be a write only application.
Consider what the simple phrase means "Extensible without modification". Write something that can be used in ways you have not imagined without adding any further code. Tricky.
Search google for "simonyi wysiwyg" (sorry about the typo, if that's the worst you can do to try to agravate me then don't bother) Before you call the guy an idiot. Idiot.
My Karma: ran over your Dogma
StrawberryFrog
I don't give a toss about that, which part of non-sequitur do you not understand? The thread was about hungarian notation, which sucks.
... why don't you search for "strawman". I didn't call you an idiot; it would be redundant. ... flame ... fucktards ... winge ... moan ...
Oh. May I refer you to your first post, wherein I described Simonyi as "someone who has influenced the current state of the art of programming with several of his ideas" Note that I did not say for good or for ill, though I would surmise that if an idea catches on, these is likely to be some good in it for those who use it. Those who don't find good in it, shouldn't use it and not waste everyone's time whining about how much it sucks, like 13 year-olds.
Note also that this description is not limited to Hungarian notation. Clear? Good.
Now you replied that he was "influencing (the current state of the art of programming) negatively". I see that you did not refer specifically to Hungarian notation either, so this could be a slur on his life's work as a whole. I took the liberty to point out another contribution that you are unlikely to be able regard as an entirely bad thing. It is thus completely sequitur to bring up wysiwyg, as it shows how it would be wrong to say that overall, Simonyi has influenced the start of the art negatively.
Now run back to class, kid.
My Karma: ran over your Dogma
StrawberryFrog
Confucius say, "Find worm in apple - bad. Find half a worm - worse."