Fixing broken software development for the masses

Our programming tools should be more democratic, egalitarian, said (Dr.? Mr.? I was assuming Dr.) Edwards a while back. (I, a peon, have great respect for and mostly agree with him, of course, utterly seriously.)

What I see happen in the real world is something like: (1) hack something up to get it working asap; (2) oh no we got actual customers [remember the famous quote about not being able to change Makefile syntax?] we'd better keep on truckin' with this since they want new features and are already bought in to how it works today; (3) who the hell wrote this crap, I can't possibly maintain it! [remember the famous death of Netscape?]

So if we hand people Visual Basic, they might make something great that would never have existed before. BUT what kind of rats nest of hell code will they produce, and what zillions of crazy bugs will they have, and and and.

If that is a real problem somewhere in the world sometimes, how best to address it? Rewrite it? Outsource/offshore rewriting it? Sell it to CA, Inc.?

Or something else? What could we have in our programming languages and ecosystems that would let the masses have their cake and eat it, too?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Visual user interface design vs. markup

Even as a few people still work on improving visual gui editors, I've noticed that the entire software development community seems to have chosen markup languages over concrete tools.

We've chosen metaprogramming over tools. We've chosen text = visual design.

So user interface, it's as if textual programming languages won out over visual programming languages all over again, just in the realm of visual dsls instead of in the same language the rest of the code was in.

Perhaps if programmers used more powerful languages better suited to run-time generation, something with the power of scheme, for instance, then the two languages would merge and user interfaces would be in generated code in the base language.

What could we have in our

What could we have in our programming languages and ecosystems that would let the masses have their cake and eat it, too?

Easy extraction, refactoring, and sharing of subprograms. Type-safe structured editing. Good support for Visual DSLs.

We could do a lot to address the entanglement problem, where code easily becomes entangled with context through state, namespace, etc.. If we make it easier to extract, share, and safely reuse pieces of applications, we could have something much closer to a component-market (rather than an 'app' market).

Shifting a lot of type support into the editor would make it a lot easier to snap elements together safely, and to search a market of available components for relevant content.

Visualization can help users grok code they haven't seen before, and provide considerable feedback during development so they begin to absorb information without consciously thinking about it. We really need many ways to visualize code and behavior (e.g. views of code, views of types, views of statically computable values, animation during compilation or of partial-evaluations during composition, animation of execution). Automatic fuzz testing could provide a nice basis for animations during edits.

wrong level of problems though

People used visual basic because they didn't know how to program or get started, and having a visual editor for their user interface made it possible to get simple programs up in a gui environment without learning much.

People like that don't need solutions for problems with modules and sharing and safety and programming in the large, they need their hand held to do the first steps of small programs.

And I'm not sure that type-safe anything is useful for small scale programmers, either neophyte or professional. It's a lot of mental overhead that isn't worth it, no matter how much research is obsessed with it.

Morphic maybe?

Note that "morphic" is a newer design for a Smalltalk gui and visual editor, perhaps it started in Self rather than Smalltalk.

Smalltalk's gui was copied by everyone.

It has some really bad elements, using a model/view/controller separation when 99.99% of programs don't need it was a horrible choice.

But the fact of having a simple (not complicated by types) message passing model for the gui and the openness, easiness to explore and change and trace (at least in the original version) made it the easiest to program to. But it wasn't any good for absolute neophytes without a visual editor.

The lack of a meta-language for the user interface makes it out of style, rigid and less useful to professional programmers (unless they get used to generating smalltalk), but it's still the best known approach for "visual basic" like use.

The problem with smalltalk has been the way it's licensed not the rest of it.

I just failed in a search for it

But I believe the Alan Kay and some others have a current project trying to demonstrate that the basics of an OS and tools (such as editors) can be written in much simpler code, maybe 1/1000th the size that people are used to. The system is based on a dynamically typed language (Smalltalk) with some sort of constraint programming helping with gui layout - people may be using the constraint library for Mac programs these days too, I'm not sure.

While Kay's systems never seem to get finished or polished these days, the idea that the underlying system could be much simpler might make programming much easier. Perhaps that would be useful in general for the sort of non-sophisticated programers who loved Visual Basic and for the rest of us.

The proliferation of unnecessary complexity makes programming a lot harder than it needs to be.

And the idea that even full featured programs could be much much much smaller has been proved. The editor in the Xerox star was fairly full featured (supporting even Asian texts layout and pictures..), and imagine how much smaller any program written in the 70s had to have been.

Previously on LtU

Steps Toward The Reinvention of Programming

We may have had some follow up posts about it, too.

emergent effects

People like that don't need solutions for problems with modules and sharing and safety and programming in the large, they need their hand held to do the first steps of small programs.

The former supports the latter. Having easy component sharing and integration helps people find and recognize what they need, e.g. in component libraries, especially when taken together with good visualization, without grokking the inner workings. The ability to easily disentangle components, in turn, helps keep systems more maintainable and the work more reusable, including from one prototype to another.

Type-safe composition and editing can be very useful for small-scale projects and neophyte developers. It's no different than how having differently shaped adapters at the ends of your wires (e.g. for Ethernet vs. USB vs. PS/2 vs. power) helps people compose things correctly without really thinking about it. Types can also aide search for relevant components. Types can be used in many different ways, some productive and some much less so.

Every little element of design contributes to everything else. Or at least it should.


If we don't then we're just going the Monty Python swamp castle skit all over again like we did with previous "peoples' languages" like VB. Those who inherit the code of such things are generally as a rule very sad as a result.

Of course, the fact that *any* code one gets to inherit and maintain makes one really sad means our *entire* approach to coding things up frankly sucks, even if we're using "professionals' languages".

I'm not sure I buy that.

The problem with visual basic is a lack of power, lack of abstraction not a lack of typed variables or modules.

I would much rather inherit a program written in R5RS Scheme than one written in visual basic, even though R5RS has less support for typed variables and no more support for modules, because it has enough power to represent abstractions.

There's a practical

There's a practical difference between modularity with careful discipline vs. limiting entanglement so first-order expressions are easily refactored into modules. There are also UX differences between using types to say "no! you're wrong!" after having written something and type safe structured editing, which uses types to ensure you get it right at edit time. Dismissing my description as 'typed variables and modules' does disservice to both my ideas and your comprehension of them.

As far as lacking power and abstraction, I think that's the easier problem to address. A difficulty is providing abstraction to "the masses" which suggests support for thinking in low-order, concrete ways. DSLs are probably suitable for this role, since a good DSL can abstract over the computational noise while remaining concrete within one domain. IIRC, VB never really experimented with visual DSLs. PureData has experimented with them a little, but I believe it could be done better.


The problem with {visual basic, java, go, c, and any number of other languages that people use on a regular basis to ship code} is a lack of power, lack of abstraction.

:-) :-(


I wanted to play some DSL building package based on the idea that you have an editor that doesn't even allow syntax or semantic errors.

Of course my computer is too slow and with 2 gig of ram too small to even run the editor.

My feeling, though, is that an editor that doesn't allow errors is an editor that doesn't allow writing and modifying code. It would be one of the deepest rings of hell.

There has never been a popular product that attempted anything like that, so saying that it's "the future" is selling snake oil that almost sounds disproven. Isn't that just a visual language without the pointless pictures? Also proven to be a pain in the butt?

I guess that's too harsh. But I'm not convinced.

I suppose editors will get better, computers will get faster etc.

Forcing structure on people kind of makes sense as training wheels or as error reporting after you're done editing, but if editing requires more complex asking permission than just typing, then it will slow people to a crawl.

Structured editing with a

Structured editing with a keyboard is possible, e.g. similar to using intellisense to build and search for expressions. Paul Chiusano's recent work on Unison is an example aiming for typesafe editor (especially related: [1][2]). More generally, we might also leverage a concept of gestures, for which the keyboard might be one tool for inputting them.

I'm not sure what you're imagining. I'm certain you can imagine plenty of obviously bad ways to do it. We wouldn't be favoring those.


gestures that should be supported.