Curl RIA news

Work on a Curl refactoring project has kept me from having any time to blog, but the May 7 release of Curl 7.0 prompted me to get a bit long-winded over at www.eclectic-pencil.com
I had recently been to a Smalltalk presentation of Seaside where I thought we needed to show serious app's and not the typical "toy" applets (even if they illustrate important technical points.)

Recently I have begun to wonder how much working with developers who reject evolution as a biological fact and perhaps as a cosmological construct has also meant that I have been working with developers who reject evolution in software.

The other day we watched a large river otter crossing our path in a nature refuge: it moved rather like a sea lion. And sure enough, scientists think they have found the link between an otter ancestor and today's marine mammals. Evolution of species is not a theory. Our planet is not 5000 years old. These are the facts, but they are facts not accepted by a great many software developers here in America. I would say that if you want to hear some absurd views, spend some time in a room with a random selection of software developers ( I mean corporate employees, not independent-minded consultants.) The percentage of extremist views to be heard on any team is not representative of American society. Nor the percentage of Americans of color or of female gender. And why so few openly homosexual software developers? In testing and QA, yes. Documentation, yes. But not development. Straight and, in my experience, oddly skewed to the political and religious right. The sad truth is that corporate employment in software development, for all its "professional" trappings, is better understood as a curious form of servitude. Historically, did not the servants become the clerks and then, once again, servants? Servitude is the corporate norm. Deferential servitude and most often in the service of office politicians with little science or technology under their belts. Let alone engineering or business savvy. It is just social evolution. If you work in software development in an American corporation, these appear to be the facts. ( The first effective managing and reporting bureaucrat may have been Samuel Pepys, whose London diary remains a very revealing document. He may have been the first secretary of the British Navy to know the multiplication tables (need I remind that computing owes a great deal to the needs of naval gunnery.) The first corporations were viewed as something on the order of conspiracies to defraud the Crown, if memory serves ... gifts were the norm in doing business with government officials; Pepys borrowed large sums from his boss. I could go on ...)

But what could evolution mean in software development as an engineering practice? In aviation we have seen significant change with Cockpit Resource Management and "fly-by-wire". If you look back at Fred Brooks on teams and software, you may know that surgical teams have also evolved to where we sometimes have two or three teams in procedures that may exceed 24 hours. And we also have sobering data on surgical outcomes and post-op complications. Choose your surgeon well. But also hope that he or she operates with the assistance of a surgical specialist (thoracic, abdominal, orthopedic) and with some of the lessons learned from cockpit voice recorders on how to communicate when things start to go wrong or the unexpected happens. What is the software equivalent of a trauma team bent on stabilizing without repairing? Has software development seen a comparable revolution in securing a desired outcome?

I recently mentioned to a software development manager that one of our finest musical teams, a famous touring string quartet, is composed of individual professional musicians who avoid even staying in the same hotel. But what does the typical corporate software manager mean by "team player"? Surely they can't mean the game of candor and statistics, baseball. What do they mean? Get on board? Never second guess? And is the typical co-located software team really conducive to evolution in the design and implementation of a software product? How much of the time spent in meetings is time spent thinking about the product? And what explains the high turn-over in staff?

Over the past months I have had some contact with a very dynamic team working in an expression-based language other than Curl and I have been very impressed by their openness and their lack of "group-think". And that in a little over a year I believe their application has gone through 3 versions of a UI. And the developers are not co-located or even on the same continents.

Suppose you have a small Curl team. It should be possible to produce quickly 2 or 3 prototypes for any new web software proposal. One of those prototypes may then evolve. By which I mean that we will take the maleable "proto-product" into a few dead-ends before we find a viable implementation with a suitable memory footprint and adequate performance. And maybe in version 1.x we are still parsing XML and we have no business rules and no customizable UI templates. Version 1.x may itself be a dead-end. Better to own up to it before it is your version 2.x or even worse, your version 3.x

Taking evolution seriously may mean that the product is ready only when it is ready and not when someone in marketing said it would be ready. It may mean taking a different view of "failures" and of time over-runs. It may mean taking the long-view and not the quarterly review. And a little more candor.

If it now may make sense to talk about galactic evolution or of evolution on a cosmic scale, might it not be useful to take seriously how a rather simple prototype can evolve into a multi-faceted software suite? And more often not?

Software projects do not set out to fail, but so very many do. Perhaps one way to thrive is to be able to accept failures, but failures in shorter cycles. I think that in the case of web applications, Curl can offer something unusual in this regard. Rather like a multi-paradigm language such as Oz, Curl permits starting in a declarative mode ( and with very few type restrictions ) and then trying to tighten things up by adding restrictive directives while also decoupling classes into components and into layers. And getting it wrong, stepping back, re-assessing, and making another pass. And then seeing unexpected, unanticipated possibilities. And then flourishing as a product within your market niche or corporate division.

Curl only aims to be a secure enterprise platform. But it has worried me that its many practitioners in Japan and Korea have not insisted on obtaining a refactoring browser for the Curl IDE. It seems to me to be an essential tool for working on software that is permitted to evolve ( a great deal of Smalltalk product was not permitted to evolve: group-think dictated Java. I even once watched a PROLOG expert system for underwriters replaced by the work of DBase "Clipper" developers in need of a project. Nothing is too irrational to occur in software engineering/software management. We have Scott Adams. We need a Samuel Clemens.)

It seems time now for the Curl IDE to move into open-source. And even then it may not evolve in viable directions. But it deserves a chance at a refactoring browser and closer integration with a testing framework.

It should be clear that Smalltalk is evolving whether with traits in Squeak or with Seaside in VisualWorks as "Web Velocity" or the other directions taken in Slate and Io. Curl, on the other hand, only has one dialect and aside from emacs, has only its own IDE or an Eclipse plugin. Even if Curl the language does not evolve in the ways in which SNOBOL evolved into ICON and UNICON or in which Tcl evolved into XOTcl, Curl remains an environment in which there is an almost unique capacity to produce software which evolves: from prototype to product or from web applet to the desktop or to a unique browser variant. Most recently we see the addition of SQL on the client side. I am hopeful that we will see soon a "main-memory DB" package for Curl applets on the desktop.

More importantly it needs to emerge from the "unknown" rather as Smalltalk is emerging from the "once known".

PS
If you do not think programming languages evolve, take the time to explore the emergence of PROLOG III and PROLOG IV or the return of SNOBOL-style string processing as an option for ICON or look at what became of Smalltalk as Self and then as JavaScript and now again as Slate or IO, or Ruby or ActionScript. Examples abound.
Some languages not only seem to evolve, they transform as corporate and community assets: the two major Prolog sites almost ceased to even mention the language by name. The corporate marketing proposals to replace the name of Smalltalk or the name of Curl must recur annually if not more often. Smalltalk is a set of dialects saved from extinction by a happy mutation called Seaside. Curl is becoming a platform. Did I say the other post grew long-winded?

PPS over at James Robertson's Smalltalk blog I see his comments on time spent in the debugger and think, Ah-Hah! Time spent in the debugger in exploratory mode could be seen as accepting that software evolves ... what emerges is not always from some documents or designs but from doing the task. Murray Gell-Mann has said something similar about those who believe design certainly came first. It ain't necessarily so. So I may be wrong about the lack of attention in Curl to XUnit and an RB. Develope. Emege. Evolve. In the battle of TLA's that would be DEE versus TDD. ( I was also looking at some Frank Gehry sketches for the Waisman Museum and the ensuing maquettes, blueprint details while standing in that building.)