Software is collapsing under the weight of its own complexity. Charles Simonyi’s solution? Programming tools that are so simple that even laypeople can use them.
Everyone’s a Programmer
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Even stringing together modules can be quite complex, as can be seen by the fact that not everyone can handle the unix-type command line.
So how would you design these programs? In some sort of UML type diagrams ? Let’s face it writing decent programs will always require a decent programmer. Regardless of wether he’s writing in machine code, or thinking on a higher level.
Here’s the deal, people think that software is something that’s so simple. And software is simple. If you’re explicit in telling it to do what you want, it will do it.
But there’s the rub.
People don’t want “Do what I want”, they want “Do what I mean”. There is a VAST difference between the two concepts.
Anyone who is married encounters this problem routinely, and despite statements to the contrary, Men are fairly sophisticated reasoning machines and they STILL screw up this simple “want” vs “mean” issue daily all across the planet. (Of course if goes both ways, I’m just playing to stereotype…)
Let’s take another simple example today. Today you can go down to any home center and buy cabinets for your kitchen. Totally modular, prebuilt, finished, everything. Simply screw them to the wall.
But when someone says “Install my cabinets”, they don’t want them simply bolted to the wall. They want all of the finishing work as well. Leveling, squaring, fitting to the rough floor and non-plumb walls of the real world, etc. It looks so easy in the brochure and the video, but they you have to work with your 30 year old walls and floor.
Human beings are HORRIBLE at communicating and describing the minutia that dominates their processes in their daily lives. How often have we heard “Here let me tell you — no wait, it’s easier if I show you”? Because the bandwidth of seeing all of the detail in a process is much higher than simply writing it down.
This communication gap is what continuously frustrates software projects — all software projects where the person having the problem is different from the person writing the code.
Ever implement a spec and get to a “x = doThing(); if (x == null) { … ummm… now what?”? “Oh we didn’t think of that.”
These turn in to “Well, if we do that, then this, that and the other happen…” “But we can only handle that, not this and the other…” and so the changes cascade.
XP helps address this problem by having a dedicated domain expert to field these questions quickly.
Can we use higher level tools? Of course we can. But people soon learn that the higher level the tool, the sooner it becomes more restrictive on what they want to do, because the tool maker didn’t consider something the user feels is important. The user can’t bend the tool to their whim. Some users compromise, others complain. Whenever they get off track they’re either stuck, or they’re buried in the detail that the tool is specifically designed to shield them from.
So, good luck to these guys and all, but we have literally been through this so many times before that I’m very skeptical that they’re going to make some leap that will actually make this any better.
Brought to us by the guy that invented hungarian notation, the scourge of Windows programming.
Sounds interesting, and in theory it’s probably possible, but I wonder how well it would work in practice. Will this be the panacea of software development? If so, it will probably take decades to get it right.
I read this article a few days ago. The proposition is highly dubious in my opinion. This sort of thing has been promised for years (decades) now. The only thing that has occurred is that software (tools) have become ever more complex.
I also found the obvious idol-worship of Charles Simonyi to be a bit annoying. One comment, I found to be particularly strange was “As the inventor of the first what-you-see-is-what-you-get interface, Simonyi seems uniquely suited to this challenge.” How so? I don’t get that. Sorry but conceptualizing the WYSIWYG word processor doesn’t seem to be necessarily the leap of a genius.
Furthermore, I’m not sure, but I think ALL of these software genius/pioneers have been “one hit wonders”.
Mitch Kapoor (also featured in that issue of Technology Review) hasn’t really repeated. Dan Bricklin? Nope. Ozzie Osborne? Nope. Charles Simonyi? Not yet anyway. Andy Hertzfeld? (mentioned in the Kapoor article)? Nope. Bill Atkinson? Nope.
And the list goes on.
It is almost as if, like they say about authors…every author only has “one great book in him/her”. (Though, admittedly, the repeat success in that business seems MUCH greater.)
Finally, I am also suspicious of these multi-millionaire/billionaire software “giants” that are using their own money to fund their efforts. It starts to sound a lot like just a really expensive hobby to me. When you contrast these current projects with the circumstances under which things like Multiplan, Lotus 1-2-3, (even the original Mac software), etc. were built. Tight deadlines. Shoestring budgets. It’s almost like these are REQUIRED circumstances to build great things.
> This communication gap is what continuously frustrates software projects
I believe this is a fundamental statement about software development efforts. I have come to believe that communication, in all of its various forms is the linchpin to success (or failure) in a software development project.
Perhaps the tools Simonyi proposes will resolve this problem. But I am (highly) skeptical.
Oh ya, I was waiting until someone thought up another “true solution” to all programming problems, as if applying OOP to everything in the last 10 years didn’t waste enough time and resources already. Software is complex and precise, humans are inprecise and dumb, get over it.
What we really need are tools that are simple, clean and consistent and that can be conceptualized easily, not another BFG.
> Software is complex and precise, humans are inprecise and dumb, get over it.
Software is complex. True, but not necessarily so.
Software requires precision. Yes.
Humans are (generally) imprecise. Mostly true, but those who can be precise have (at least one of) the skills for creating software.
Humans are dumb? No. The implication here is that somehow “software is smart”. Humans are smart and we ought to leverage this intelligence for creating software rather than continuing to figure out ways to get rid of humans from the process.
http://intentsoft.com/
i know simonyis works for quite a long time and i can’t wait to see his product.
if you want a preview, there’s a strong and rock solid product (made by a group of uruguayans engineers) which is based in most of simonyi’s statements around how software must be developed.
give it a try
http://www.genexus.com
I guess in a way, any configurable program and things like spreadsheets are kind of like little programming languages in themselves. People have enough trouble with them. I don’t think they’ll ever get non-programmers writing programs unless its taught throughout school.
I don’t think that’ll happen though. Software is so much more complicated than other things because even though at the fundamental level programs are much easier to write than say, engineering something, we try to do so many things that the complexity soon rises beyond anything humans have ever created before. A piece of software of the same complexity of a car is extremely simple compared to the programs we write on a regular basis. There’s just some many components and so much data flying about.
Making things ‘visual’ won’t help either. You still have to deal with the complexity.
Everyone is fully capable of being a professional programmer. They just don’t want to.
I don’t think they’ll ever get non-programmers writing programs unless its taught throughout school.
School teaches us how to work, not how to think.
Its quite funny how HW & SW engineers end up swapping ideas and then abandoning their own past.
The SW industry has already had Hypercard, SuperCard, Prograph etc and they don’t get the attention they probably deserve so they disappear.
For decades HW engineers used schematics, 1st paper drawings then CAD to capture scematics of pcbs & chips. It worked quite well till the no of sheets went past 100 and no of low level items went to 10K+. Now most chips are programmed in HDLs descended from old C and ADA. Try getting any decent tool to help visualize what 10M lines of HDL does, good luck. The SW guys that write these tools don’t want to write nice friendly graphical tools since those are much harder to write than compiler like tools.
Its now totally uncool to use the schematic word in the HW industry. Most tool writers prefer ascii text file exchange than proprietary binary graphic formats.
So now Simonyi gets the great idea to use graphics etc. I actually half agree with the intent but it only works well on a case by case for each industry segment.
It comes down to segmentation, after learning to write language compilers for awhile, all the automated tools that help build the next compiler are there, but they don’t seem to help do the really hard part that can’t easily be explained. If a problem can be described in any meta or mathematacal language, the rest is much easier, otherwise its a dog.
If you want a program that people can say ‘make me this’ and it writes it for you, you first have to figure out how to do proper AI. We’re wasting out time trying to do that on Turing A-machines.
Everyone is fully capable of being a professional programmer. They just don’t want to.
That’s probably true. People are more capable than they like to think they are. But it’s not entirely their fault for thinking that way. I could ramble on for hours about the pitfalls of Western society…
School teaches us how to work, not how to think.
Hmm, I have to agree actually, I’ll retract that statement. It’s sad but true. I’m clasping on to romantic ideals again…
Python already is that language.
Seriously, there was a development tool that Novell used to produce called App Builder; or something like that. All you had to do was drag these components out of a menu and place them on a work area. Then, you right clicked on them and set whatever properties you wanted to. If I remember correctly, you didn’t have to actually write any code. Sounds easy, but it was quite difficult to get anything with substance to work. Visual Age for Java sort of took a similar approach to some degree, but it was cumbersome as well.
Of all the languages I’ve ever programmed in, I find Python to have the perfect mixture of simplicity and functionality. This is, of course, my opinion.
My take on this that we should all move to higher level languages, that are integrated further into the Operating System at a lower level.
This is a product that provides for graphical programming within Visual Studio…
http://www.softwiretechnology.com/
But it is still a pretty complex environment and not really for non-programmers, IMO.
They dont have people make software anymore the computers actually code the programs
“… higher level languages, that are integrated further into the Operating System at a lower level.”
If that’s what you want, you might want to check out IBM’s JCL, or Job Control Language. It’s not pretty, but it is integrated into z/OS at a lower level than is the likes of bash or tcsh, which are merely application programs like gcc and VB.
It’s precisely the integration of higher-level components into the lower OS level that make soBig such a delight to countless computer users the world over.
Ahh yes, another excuse for “cheaper programmer’s”, where people who can do proper jobs have to use substanded tools and poorer pay… Didn’t we get enough of this with Visual Basic that we now have to go with even EASIER languages?
How sad that we do this to ourselves, and allow the unemployment ques grow.
Check “Candygrammar” in “The New Hacker’s Dictionary” or the “Jargon File”.
To quote: “The usual intent of such designs is that they be as English-like as possible, on the theory that they will then be easier for unskilled people to program. This intention comes to grief on the reality that syntax isn’t what makes programming hard; it’s the mental effort and organsation required to specify an algorithm precisely that costs.” pg 103.
En otras palabras, the difficulty with programming is not in its language syntax, it’s in deciding how to put the problem so that you can find a solution to it. Languages like the Mac’s Hypercard – which imho should be published under the Apple Public License as Open Source – succeeded because they were on hand and they didn’t come with the “programming language” and “genius-level_ cultural baggage, so someone could pick up programming skills just by playing around with it.
And because they could play around with it, they learnt how to program.
It all starts with a few innocuous recorded macros, then grows and grows out of anyone’s control.
On the other end of the spectrum, you have the soft used in nuclear power stations and other refineries, that evolves constantly and that is strictly tested and controled and which use languages that are not exactly trivial.
The real world is even more complex than software. But somehow, plane designers, architects, building engineers and project managers seem to be able to cope.
Software industry needs better processes, better practices and better documentation standards.
In the company I work for, most of the IT management doesn’t have an IT background. It doesn’t happen in finance or in manufacturing. And I don’t think it is that untypical. How can they drive continual improvments about things they have no idea about ?
The important thing is not the syntax, but what you mean with it, the semantics, the meaning of the program. The windows in Visual Basic are one trivial example of semantics better expressed graphically. The syntax used for it, or the graphical representation, is largely irrelevant.
My own (free software) research on the topic is at http://mozart-dev.sf.net and http://xlr.sf.net
The idea is certainly nothing new. Companies have been working on this sort of thing for at least 20 years that I know of.
I think that we might require a system outside of the academia that people who want to be programmers join, and that system rewards people with resources including tools and authority to direct projects of various sizes. The company that designs this system will be making their knowledge base public but only to experienced programmers as a reward strategy. It is these programmers who will be able to build the tools and the agents rather than a closed prorietary company. We would benefit the most from a learning organization because many more minds, more ideas, would influence the direction of progress, something which should not be controlled by a beurocracy.