Monday, May 25, 2009

Surge, the RIA platform; Curl, the language

As an enterprise RIA vendor, Curl, Inc. might well opens its platform even further than its recent embrace of SQLite, JSON and AMF.

At that point the Curl language would be just one aspect of their RIA offering.

When a Java developer is learning Curl, I often have occasion to make the reminder that a procedure or a method return is an expression, that is, we use {return} or {return result} or {return asset, valuation}. But I also remind developers to select a word and tap the F1 key in order to take advantage of the Curl Documentation Viewer to take advantage of its live code examples.

If you use Help to open a search in the docs viewer for return you may miss what you would have seen with a simple F1 on a return word in your code. The return word is a macro.

The return macro is defined in the package CURL.LANGUAGE.COMPILER

It may well be that the time is coming when ordinary Curl developers will be able to look at that macro implementation code in that package.

With the new Curl 7.0 library access modifier, it should be possible to expose much more of the implementation of the Curl language to interested Curl developers.

In the long-term, the Curl language should move into the public domain. The return could be macro.

Sunday, May 24, 2009

The Squeak Smalltalk FOTB: Sophie embraces Java?

The Sophie project site reports that Sophie 2.0 will be in java in order to be browser based.
Was Strongtalk considered? To think what could have been accomplished if Curl, the language, had been an option! Next I suppose I will hear that Croquet or Cobalt has left Squeak for Scala. It must be a typo. The must have mean Gears and JavaScript V8.

You can get Sophie 1.0.4 here and learn about the Future-of-the-book here.

Over the years I have seen 2 expert systems running in PROLOG rewritten by teams looking to use their FoxBase or their java skills so this should not surprise me. After all, the book will no longer contain text or the text will not be in UNICODE strings so why use a text-focused language with graphics. Or were ICON, UNICON or REBOL deemed more obscure than Squeak? Here's my tip: prototype Sophie 3.0 in Curl using the any type with all preprocessing directives turned at the lowest levels. Then implement it in your most effective language based on your project's developer pool.

Perhaps what they were choosing was not the language but the VM, and in that case the JVM would not be a bad choice if the CINCOM Smalltalk VM was not available for the terms of their license. But by the time 2.0 is released, they could well have made a major contribution to Clean Slate Smalltalk, or Strongtalk, or Self, or Io. And in a project such as this, Scala with traits would look to be a natural given the prospects of major refactoring in the future of the project (traits are to refactoring as were classes to OOP components.) Ok. Not a word about Rebol. Well, maybe one word: a project such as this needs to have the types on the side of the values, not the slots. What has been termed "cash instead of personal checks". Chapter the last.

Using gedit with the Tcl/Tk IDE for SNOBOL4

Over at my Curl blog I've added on note on using gedit as the external editor with a nice simple IDE for SNOBOL, the original pattern-matching language intended for computer users. That blog entry also has a link to an object extension to ICON which permits UNICODE strings.

Thursday, May 21, 2009

Xmarks and Curl on Eee PC with EeeBuntu linux

Rather than wait for the LXDE version of eeeBuntu's "base" ubuntu linux for my Asus 900A netbook, I opted to add Xmarks (formerly Foxmarks) to my FireFox browser and then built a new OS instance on an 8GB SSD HD chip in my netbook's external SSD slot. The install went fine and Curl 7.0 installed without any problem ( I then added the Curl 6.0.5 debian Surge RTE for good measure). Now the sweet part: I added Xmarks into the EeeBuntu FireFox with the passwords option and here I am - a fresh OS and all my bookmarks and passwords in place. Even Twine is up on the toolbar.

There could have been an easier way: an OS that can update itself, which could be Rebol-friendly Syllable.

But now I won't hesitate to go for the LXDE build because what will I lose? A few minutes on Synaptic to reinstall Mozart Oz and ICON 9.4.3 And even then the Oz will be out-of-date from that repository (and the repository has neither Io nor UNICON.) There has to be a better way to move up a linux version using a new SSD flash card and not lose my linux app's ...

Tuesday, May 12, 2009

Must-see iTunes programming video

Andy Bower of Object-Arts has a video that simply must be seen: creating an interface to iTunes.

I've been very impressed by many Smalltalk podcasts, but this tops them all. Of course to misquote Oscar Peterson, the best improvisations are the best prepared; Andy makes this look so easy. But having seen this done once, it's hard to imagine not being able to make a very few notes and then be able to do much the same for any ActiveX COM object of interest with this AX Interface Wizard.

It has been a pleasure to build software in Dolphin Smalltalk, so I was glad to learn that there will be a Next Generation version of the Object Arts Smalltalk for Windows.

There is a non-commercial, public version of Dolphin available, so if Windows is your target OS and you want a high-productivity programming environment, you could not go too far wrong trying Dolphin 6.0

Sunday, May 10, 2009

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

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

Friday, May 8, 2009

Rails, Grails and Curl

After looking at the embedded comments used by RIFE it seemed time to revisit Ruby on Rails. While looking at an example in the PragProg 2nd Ed. I was struck that what I was looking at would be easier in Curl.

Curl has both anonymous procedures and macros so stands as a strong functional language in any comparison to JavaScript, JRuby or Groovy. Smalltalk has blocks.

But instead of getting this blog note written, I have been messing about with CLISP and the question of just what macros offer. Well, in Smalltalk they would offer operators with more than 2 characters so we could have <=> instead of just <= or => and such. Or ;-)

But I only wanted to show how a few macros can make a Curl web page so nice and clean and readable compared to the latest thing on rails. A sort of pirouette of Curl. But things got macro out of control ...

And Controllers? Well, in Curl they help with animation or represent devices that have rotations, such as joysticks. Oh - Curl comes with a Quaternion class for rotations in 3D.

So when is a web content language out of control? When its comments are used to control its content? (those aren't comments; those are annotations - this a concordance, not a document ...)

Everything we were taught about separation of presentation from X is wrong when it comes to a rich web GUI. And an object is not a row in a relational database (there, I dared to say it ..)

In the early days of television they did not know what to call those who were watching the action as it happened on those funny tubes in restautants and bars. They became 'viewers' but we talk of 'watching TV'. The View in MVC is a bit like that: we pull back the 'model' a ways and achieve some degree of decoupling from any data store. But a 'personalized and dynamic view' is not the 'view' of early MVC. It likely required something like viewer-specific persistent data. Make that a 'personalized and dynamic view of a collaborative process or activity with published tasks' and the closest thing that I know today is Croquet.