Quote from the COBOL entry in Wikipedia:
The first compilers for COBOL were subsequently implemented during the year 1960 and on 6 and 7 December essentially the same COBOL program was run on two different makes of computers, an RCA computer and a Remington-Rand Univac computer, demonstrating that compatibility could be achieved.

In other words, half a century has passed, and we still haven't found a way to make programming so simple a manager can figure it out.  Yet Big Corporations still think it can be done.

I'm rather an admirer (and more than a little jealous that he got published, which makes it more difficult for me) of Nick Carr.  After I added my comment, I stopped by his blog, and found this older post (I hadn't been aware of the news before seeing this post):

http://www.roughtype.com/archives/2010/08/brave_new_googl.php

Which has led me to consider, not for the first time, the implications of automation generally and in systems building narrowly.  Would we want some software that "empowered" managers and business analysts to create applications as easily as they brush their teeth?  Would they not build systems that destroy economies ever more adroitly than the ones built by Quants (who really had been rocket scientists before going to Wall Street and The City)?  Is the ultimate COBOL a goal we *should* pursue?

The whole notion that "machines" can take over all of our thinking, and thus make our lives easier and better, is right out of "2001", "Blade Runner", "Robo Cop", or "Soylent Green".  For those who've seen clips of newsreels and tv spots from the 1950's (or are old enough to have seen them in real time), machines would take over all the drudge work, and *all of us* would have more *well paid* leisure time.  And it hasn't turned out that way.  The major problem with the notion is that, we have no theory of distribution in economics; none, at least, that satisfies the Right Wing elements.  

What has happened with the efforts so far, is that the owners of these wondrous devices, be they hardware or software, accrue to themselves the monetization of the productivity gain, leaving the rest of us poorer in real terms.  At some point, there will be no "skilled" work left with which to earn sufficient income to consume all the largess these machines (sans human intervention) produce.  Well, except to explicitly take from the rich to give to the poor, who then buy the production so that the rich can continue to run the machines.  I know, I'll call it Recursive Economics(tm).  Japan is nearly to the point; no other solutions have worked.

Since the IBM PC and all of its successors have entered the workplace, income and wealth inequality have increased.  Part of that is clearly (in the USofA, at least) due to Political machinations (whether these machinations are directly tied to the machines is a longer story), but also in large part to the concentration of computing resources in financial sectors of the economies, starving others.  It is known and documented that people working in the hard sciences left for Wall Street and The City; it looked like the work paid better.  May be so, but the macro effects of such accumulated micro decisions was a disaster.

If there were such an Oslo, the end result would likely be that, since it would no longer require much brainpower to build systems, those most adept at corporate hijinx would get to build those systems; the Ladder Climbers, Glad Handers, and Back Stabbers.  Where 100 really smart engineers would toil for a year to make a system, 3 MBAs (and we now know how smart those guys are) would knock one out in a weekend's pub crawl.  I'm not sure that's a measure of progress toward meritocracy.

In "The psychology of computer programming" is said - more or less - that managers see programmers as a necessary evil, and every now and then an attempt is made at getting rid of the latter by developing some easy to use (for a manager, that is) programming system (e.g. COBOL :-). Irony is that such a system has to be developed by the very same people it should replace, an event I don't think is very likely.

Since this is still up, and not garnering much conversation, I'll add a more positive note; in the sense of what Oslo could/would be.

I've not had much use for diagramming (UML, etc) to drive schema definition/scripting.  Such a process seems wholly redundant; the work process/flow determines the objects/entities/tables, and converting these facts to DDL is not onerous.  

OTOH, getting from the resulting schema to a working application is a bear.  There have been, and still are, frameworks for deriving a codebase from a schema.  Most are in the java world (and, not coincidentally I believe, COBOL some decades past; it's that ole enterprise automation worship), but without much fanfare.  I suspect, but can't prove, that Fortune X00 companies have built internally (or, just as likely, extended one of the open source frameworks) such frameworks.

This is what I thought Oslo was to be:  a catalog driven code generator.  My obsession with SSD these days (and it's looking more and more like the idea is taking hold Out There) still convinces me that BCNF catalogs can now be efficiently implemented.  Since such catalogs are based on DRI, and such kinds of constraints are easily found and translatable, generating a front end (VB, C#, java, PHP, whatever) is not a Really Big Deal.  Generating, and integrating, code from triggers, stored procs, check constraints, and the like is a bit more work, but with more normalization, constraints become just more foreign keys, which are more easily translated.

That's where I expected Oslo was headed.  This is not an ultimate COBOL objective, but "drudge work" tool for database developers (and redundancy notice for application coders, alas).  Such a tool would not reduce the need for database geeks; quite the contrary, for transaction type database projects we finally get to call the tune.  Sweet.

An interesting discussion - too bad there have been so few comments.

When Oslo was still fresh, I decided to give it a look. I had heard some rumors - and if they were all true, Oslo was sure to be "The Next Best Thing". Design the schema and the processes from the users perspective, using some conceptual modeling technique (preferably driven by the BPMN and SBVR standards). And simply generate the application from that design with no further human intervention required. Not exactly the same as where BuggyBunFunny expected Oslo to be headed, but reasonably close.

What I saw was quite different. In the places I was pointed to, there were no graphical components whatsoever. There was a specification, and some examples, of the language "M" (not sure if it was called "M", "D", or yet something else at that time). And what I saw made me shudder - memories of typing record definitions for my PL/I and Cobol programs on an IBM 3270 terminal that I though I had carefully suppressed came right back to me! If that language was designed to be understood by managers and end users, then surely Mount Everest was designed to float in the atmosphere.

I must admit that I completely lost interest at that point. Maybe that was wrong. Maybe Quadrant has become everything that it should be (except the wide acceptance). But reading this blog and the comments don't make me believe that to be the case. And so, I must conclude that the world is still waiting for a good tool to make the translation from manager/end-user wishes to working applications less painful.

Oh, one more thing. I quote the blog: "Anyone who has ever suffered the task of turning UML diagrams into a database schema would have quaked at the plans". That is of course a given. UML diagrams contain information that cannot be represented in a database; database schemas contain information that cannot be represented in a UML diagram, and UML diagrams are on the logical layer whereas database schemas are on the physical layer - you don't want optimization for the physical layer to clutter up the UML diagrams that will be presented at meetings.
The second of these objections is the most important one. As long as diagramming techniques are used where information is discarded to keep the diagram simple, human intervention in the translation from diagram to database schema is unavoidable - for who else can add back the details that were left out in the diagram?