Lambda the Ultimate

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.

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.

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.

Steps Toward The Reinvention of Programming

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

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

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