The Myth of the Non-programmer Programming Language

The continual search for making 'programming for the millions'

Posted by 09/28/2005

There has been an unending attempt to write languages that non-programmers can use. I contend that all of these languages end up being used by either a) programmers or b) highly technical people that might as well be programmers.

SQL

The SQL dialect begins so simply. It's case insensitive and it almost reads like English. "SELECT user, name FROM users where state = 'TX'". It's fairly obvious what that is supposed to accomplish. From what I understand, one of the design considerations with SQL was to get the database querying away from the programmers and into the hands of the people that actually use the data. But inner joins, stored procedures and all the rest made that impossible. I would say Microsoft Access came the closest to pulling if off with the Query builder tool. But even Access ended up in the hands of Access developers.

XML and XSL

XML and XSL were supposed to be something anybody could do as well. XML is self-describing, simple and extensible. I was hopeful about this myself - because the XSL to produce HTML seems so close to just plain HTML - with a few extra logical statements thrown in, which are just a few more tags to learn. And the masses have picked up on HTML pretty well. Or have they? That kind of fell into the hands of Web Developers. And XML/XSL? I'm not sure whose hands that fell in - but it's not the masses.

Rules Engines

You write an application that runs on business logic. If someone has a credit balance of over $10,000 they are not charged an account fee, for instance. This business logic may change year after year, and it really should be something the users can change without the need of an intermediary. So why not make it so the users can set rules like that? It works okay in very limited scopes - such as the MS Outlook rules for forwarding. You have to have a small unit of logical outcomes; "If an email comes from _____ then put the email in folder _____." That's pretty simple. Some Rules engines claim to be set up for the 'common man' i.e. the user rather than the developer - but all I've seen in practice is more programmers writing the rules.

BPEL

This seems to be the latest incarnation of programming by non-programmers. Who knows how it will proceed. If you follow IBM's take and use a visual modeling tool of some sort - perhaps it could border on something like the MS Access Query tool. But I'm thinking in the end it'll just be programmers doing this anyway.

Visual Studio .NET

One thing Microsoft has done well (and the Open-source community hasn't) is usability studies. Even though MS Word kind of sucks these days, over the years they've had a lot of success making things people can use easily. The .NET Visual Studio environment is really a derivative of the old Visual Basic interface. And whoever came up with that originally - with the properties window and the drag-and-drop forms - really was ingenious. It's the gold standard for IDEs to this day. People don't always want to admit that. And .NET is easy to use. That environment is the closest I can think to programming for the masses that exists.

Eclipse

At the same time, I'd have to say I prefer Eclipse to VS .NET - largely because of all the plugins. And it is so widely used maybe it is becoming the IDE for the masses. But if by masses you mean non-programmers, not just large groups of people, Eclipse - and J2EE - are too complex for them. And even Visual Studio is only going to be used by a select group of 'developers'.

Is an IDE actually more productive?

Myself, I have a love/hate relationship with IDEs in general. When forced to use one, there are times that I use an option - where I think. "Wow. That is cool. That just saved me a huge amount of time". But for every moment like that there is an equal and opposite moment of "Why is this not working? Where did I set that option? Tracking down that problem just cost me hours of work". And they seem to cancel each other out - at best. I find myself preferring Vim and I think, in the final analysis, that type of tool is more productive. Michael Feathers' paper The Humble Dialog Box makes a good case. It often boils down to short-term gains = long-term loss.

Productivity

All this blabbering about an IDE is probably unrelated. I've gone off topic. But it seems related to me. Maybe because they all have the common goal of making it so easy to program that anybody can do it. But the last 30 years tells me that goal is doomed. I think it's solely about how we as a trade improve the quality of our work. And from that point of view SQL and XML and XSL have been totally successful - but I'm not so sure about the IDEs and the RAD tools. I'm still skeptical.

Comments

Post a comment


Total: 0.35 Python: 0.08 DB: 0.27 Queries: 20