CFSCRIPT – The little language that …

November 18, 2007

To quote Ben Forta in 2004: “<CFSCRIPT> today is in a strange place. ” ( I don’t think much has changed in that regard. The fact is, Macromedia ColdFusion stopped partway through the metamorphosis of becoming a scripting language. Kind of like stopping part way through a sex change; the important parts are there, sometimes both sets, and it can be ugly to watch. Now it’s in Adobe’s care, and there are more than just PHP and ASP wandering by and looking at CFSCRIPT, with a mild sense of relief (glad that’s not me) and perhaps a bit of Schadenfreude.

I’ve read articles about Coldfusion programmers jumping ship and running to Ruby on Rails, I wish everyone the best voyage possible, whichever boat they sail. I spent years coding C++ as a plugin to Netscape, to serve up web pages. Then Apache Server. Coldfusion looked like a treat from that vantage point. Despite it’s imperfections, it is a powerful way to make many web applications happen very quickly. That doesn’t change the fact that CFSCRIPT could never run on it’s own. It’s incomplete. Like Pinnoccio, always needing Gepetto around to keep working on him, and no Blue Fairie coming to turn him into a real boy. Yes, CFSCRIPT is in a strange place, and it will likely see out its days in the place that it is.

There is an almost audible sigh of relief that escapes when entering a block of logic which won’t be needing html tags or CFML to make it do it’s job. But eventually the lines of code free of the greater than and less than signs is brought to a screeching halt by one of those things that cfscript just cannot do properly, or requires the esoteric approaches of the guru to get through.

I noticed Sean Corfield’s scripting plugin post, basically allowing a Coldfusion 8 developer to plop in some PHP here, some Ruby there. (a moody person could write alternative verses of PHP and Lua, bringing a Wagnerian feeling to the code). A colleague has been telling me about Groovy, and its possibilities and I stand intrigued. Something will have to yield, one way or another. For things CF could not handle, I used to opt to extend CF with C++ CFX tags. Now, with CF being Java based, it is cleaner to extend with Java (my opinion). Can Groovy solve some problems that CFSCRIPT could not? Is it compelling enough to justify a significant effort in that direction? Groovy and Hibernate play well together (supposedly). I may do a little with Groovy’s Gant (to get past the Ant XML build structure), but beyond that I don’t know. Groovy is too new for risking on my customers, for the time being. But what the future holds, I cannot tell.

As for the rest, I am grateful for having had the chance to work with all of the languages I have. I wish every programmer could have a wide exposure to languages in that way. I feel the same way about natural languages (written and spoken and signed-eg. American Sign Language). The more one can learn about other languages, and their inherent approaches to solving problems, and their implications, the better one can understand and utilize their home language. And though I make fun of different computer languages, I enjoy working with them a great deal.

After doing some work with Lex/Yacc for preprocessing of some code, I did some experimentation with the problem of carrying the cfscript language the distance, by adding “real” classes, to replace the tag based cfcomponent artifact.    Then, adding to that some special system classes that could yield database connectivity and scaffolded views, and cfscript is more complete, operationally.  None of this changes the fact that  CF is locked behind a webserver, and there is no past nor any future for CF based console apps or desktop apps.  It is a backend database application server for the web, when it is doing what it does best.

It is difficult *not* to conclude that Adobe (and perhaps Macromedia) purposefully prevented the completion of the ColdFusion CFSCRIPT “language”.  And given that, it would be interesting to understand exactly why, though one could guess that they don’t want to be a big player in that marketspace, to distract their focus from other more interesting areas.  For the developer who continues to hitch his career on ColdFusion, I would admonish them to add a few additional tools into their toolboxes.

G-Index for June 2007

June 15, 2007

In the very same spirit as May’s G-Index, here is the G-Index of Programming Languages for June 2007, using my arbitrary list of languages (leaving out the top runners, Java and C++), and using language name +”language” as the Google search term.  Here’s how things fell:

G-Index for June 2007

Notepad++ Support for ColdFusion 8

June 1, 2007

The full fledged IDE’s are nice and all, but some situations call for something that’s lean and mean. I happen to use Notepad++, a Scintilla based product. While it lacks ftp support, as far as I know, it has plenty for me to get some basic stuff done quickly. So, I added “support” for the new tags in Coldfusion 8.

And to make it go, save it in the Notepad++ folder, under your personal applications folder in windows. Unzip the contents and rename to userDefineLang.xml (sic), if you don’t already have one, or copy its contents to the existing one.

So, for example, my folder is C:\Documents and Settings\howard\Application Data\Notepad++\userDefineLang.xml


For more on Notepad++

If you know of a plug in for ftp support, let me know.

G-Index for May

May 29, 2007

G Index May 2007

As millions (or less) closely watch, the Erlang programming languages maintains a thin lead over contenders Eiffel, and Haskell, as it has been predicted  by some to be the “next” Ruby on Rails, or  killer language/platform paradigm.

The G-Index is a measure taken by putting the string “Programming Language” and the name of the language in question, into Google, and recording the number of hits.  It is not intended as a scientific study, nor as sarcastic social commentary, and is quite possibly just an excuse to post a graph.

On the Taxenomy of Ducks

May 27, 2007

On the Taxenomy of Ducks:

Using Object Inrospection and Reflection to Manage Systems Integrity

          When I was 12, my brother and sister and I spent a week in Seatle, visiting my grandparents during winter breaker.  On the Tuesday of our visit, my grandmother had her bridge club over, and my grandfather was out taking care of some holiday shopping, so my siblings and I were left to entertain ourselves for a few hours.  It was was raining outside, so my sister decided she would read a book.  My brother wanted to play a game (I was hoping we would play chess).  So, he went to grandmothers game closet, and pulled out a box, handed it to me and asked me to set it up, so we could play a game.  The box was labelled Chess, and had pictures of a chess board and chess pieces on the outside, so I was excited to play a game of chess.  I opened up the box, and began to set up the board pieces, and I found that a few pawns were missing.  I could have just told my brother we could not play, as there were pieces missing.  I could have gone and interrupted grandmother’s bridge game, to ask her if she knew where the missing pieces were.  But I found some dice laying on the table, so I substituted the dice for the missing pawns, so we could play a game, and asked my brother “Okay, white or black?”
Rabbit Or Duck
           The roles and responsibilities and expectations of objects in software systems are subject to the requirements, methods and organization of the system architect, and the engineering team lead.  How objects handle their input objects is an age old problem, and with the introduction of distributed systems, the shapes and sizes of input objects can suffer from their own contraints.  An object needs to have a way of behaving when it is handed an object for processing, and the first thing it needs to do is inspect the input.  If the input is not what it requires, then it needs to either handle that somehow, or throw an error.  Or maybe he doesn’t want to deal with it at all and “fixes” it by making the error message go away….
try {
} catch(e:Error)
  //do nothing - let someone else deal with it.

          This principle of software development has become topical because of the fairly recent adoption of a practice dubbed “Duck Typing” by some, popular in ColdFusion and Ruby development circles.  So, what is “Duck Typing” and why does it raise discussion around object behavior?         

          In software languages like C++ and Java, objects are classified by types, which define specifically what properties they have, and what methods are available.  When the C++ or Java code is compiled, the compiler checks to ensure that the inputs to object methods are of the expected types, and if not, a compiler error is thrown.  In interpreted systems, like Ruby, or JIT compiled systems like ColdFusion, the types are checked at runtime JIT compile time.  If the objects are strongly typed, an error is thrown.  This is much like my brother handing me the box from the game closet.  If the box was not labelled Chess, I could have objected and handed it back to my brother.

          The practice of “Duck Typing” is to abandon this practice, and let the called object deal with whatever object it is handed.  I have heard it told to me that "If it looks like a Duck, and it Quacks like a Duck, then it is probably a Duck"  So, in other words, if it is the object has a radius parameter, then it is probably a circle.  In practical terms, this is a shift of responsibilities from the caller, software environment or compiler, to the called object.  The objection to “Duck Typing” is that often this means a shift of responsibility to quality control, the bug tracking team, customer service and the project manager who is left explaining why their enterprise web system is crashing, and the development team is having difficulty tracking the bugs.  What has not been clarified in some team development environments, is that there has been a shift in responsibility.  Someone has to pick up the slack.  It is left to the called object to be more diligent in checking it’s input, and more flexible in how it handles the input.  Like, when I discovered there were pieces missing from the chess set, and I made a couple of pawns out of dice, the team needs to be clear on what the object has the authority to do, to perform its function.       Communication needs to be of the highest order in cases like this, where repsonsibility is shifted to the worker classes.  Once it is clear what the developers are being handed, there are a few strategies which need to be embraced when the protective tools of compile and runtime type checking are no longer there, because in the end, the software needs to work. There is ad hoc internal type checking, which can be set up with a simple tag, or an extra parameter on an object, which signifies the class.  There is an inventory process which an object can run on acceptance or rejection of a call.  The inventory is a matter of running through an object’s properties, like a checklist, to see if this is here, if that is there, etc., to make sure its properties match to what is expected.  The reflection API can accomodate this, as well.    If you are using Duck typing in a project, make sure to build type variance into your unit tests.  Better that the unit tests blow up than your codeline… or the customer.    What is the reason for this interest in a methodology?  Where’d the Ducks come from?  Well, when the girls start screaming, look for the rock star.  Quiz Time:  Is it David Hasselhoff or David Heinemeier Hannson?  Well, the DRY principal employeed in Ruby on Rails, says that the interface (required behavior) leads to repetition.  (DRY = Don’t repeat yourself… so repeating, bad).   Dave Thomas and Andy Hunt (Pragmatic Programmers)  These guys are incredible.  They advocate pushing Ruby on your business, with the tactics of Scientologists on a three day weekend.  Well, that was then.  Now, they are pushing Erlang (saying it’s today’s Ruby).  Give me a break.

     There is some merit, however, in the argument that the behavior of an object should in some cases define what it was, and so, having a type would be redundant.  And, given suffiently compelling context, I’d give it a whirl.  However, the situations a contractor is placed in are often a little less predictable than the cozy intellectual Oasis of Object Orient land.  There is a large installed base of non OO scripting methodologies, and relational databases, which aren’t going to step aside and make way for new practices.  Same goes for the installed base of employees.

     So, while not denouncing the practice of Duck Typing completely, I would question the argument for its adoption simply on the basis that it has one aspect of DRY, so it will lead to some future benefit.  In every single case, where a change is made, I have to ask myself How much is this going to cost? and What business benefit are we going to derive?  You *cannot* simply remove a solution from its context, and then advise for it.  If you remove it so far as to remove it from the problem, then the solution looks for a problem, any problem, to take its place.

     Sean Corfield expressed concern that people seemed to miss the point of his talk, when they talked only of the performance boost of using Duck Typing.  Removed from even a contrived context, how would anyone think any differently?  You can lead a duck to water but you can’t make him…. (okay, a metaphor mix in was called for)

   As a quick disclaimer, I should say that I am passionate about patterns, enthusiastic about object oriented methodologies and applications which can really drive efficiency and creativity.  While this is so, I witness many people who simply do not understand the underlying pricipals, but think they do.  It’s okay to not understand.   The concepts are not at all down to earth… they are abstract.  But for the people who think they understand the principals and try to drive an implementation with complete disregard to tried and true principals and practices of Unit testing, communication, and so on, … and without any support from a return on investment standpoint, let me say, these people are dangerous to software projects.

     I will continue this (rant?) and tell how the chess game turned out in a later post  (continued….)

ArrayUtil and RemoteObject Proxies in Flex

May 17, 2007

The problem:

In Flex, you’ve performed all of the steps to issue a remote query, and your responder has received the resultevent, and you go to evaluate the payload, and it gives you a null error:  “Error #1009: Cannot access a property or method of a null object reference”.

A solution (as described in Peter Ent’s blog):

Assign the result through ArrayUtil.toArray = mx.utils.ArrayUtil.toArray(;

(link (solution near bottom) :

What’s really going on?

The underlying object carried by the result event is a Proxy Object, and not an ArrayCollection, nor an array.  It could look like an ArrayCollection, but only if handled in a particular way.

Why can’t the problem be fixed?

Because the paradigms have been mixed, and they can’t be unmixed. 

The paradigms I refer to are what contrast delayed instantiation, which is characteristic of functional programming languages like Scheme, Lisp, and Haskell, and eager evaluation, which is typical of declarative programming languages like C, Java, and PHP.  In order to force declarative languages to use delayed instantiation (or lazy acquisition, or lazy loading), a bit of code has to be put in place to manage the laziness properly, and as unobtrusively as possible.  The pattern typically used is the Virtual Proxy Pattern.

In this pattern, the interface to the object that is presented, is in fact, a proxy.  It may return the real fully populated object, and it may return a shell.  That all depends on how it is implemented.  In Flex, if an object is not quite ready, you can bind it with no problem, but you don’t want to directly access the underlying object, or its members.  There are interfaces (like ArrayUtil) which you can operate through to either force it to load up all of the data, or to tickle the object, and set a listener for when it is populated (basically binding).

The Rich Client interface in Flex, provides many cases where this behavior is desireable, and to force it to load up all of the data is not always appropriate.  It is similar to the problem developers run into when they first start trying to actively drive a command into a view that has not been instantiated.  They will get a null error.  Then, after trying many things, and poring through the books, they find creationPolicy=”ALL”.  And the immediate error goes away.  That is how you defeat delayed instantiation in your views.

But, the delayed instantiation is there for a reason.  It was put in place to solve a problem, and by incrementally removing the solution, without understanding what it solved, is tantamount to inviting or encouraging the problem to surface.

It’s all about timing.  And making good use of time, which can be devoured very quickly by rich user interfaces.  For anyone who has done Windows programming, or other UI programming, you might be familiar with onDraw() event handlers for views, and how that all happens on a larger reDraw cycle.  The same principle applies here.  The data and the view are on different schedules.

When I continue, I will look at some code examples, with Haskell first, and then Java, for comparison.  Speaking of Haskell, looks like they have an actionscript byte code assembler for Haskell, with support for the Flash 9 virtual machine (AVM2).  Great work guys!

(to be continued)

Hooked on a Railing

May 15, 2007

David Heinemeier HanssonHooked on a Railing
Reviewing recent history (last three or four years) I acknowledge that David Heinemeier Hansson is a rock star, and not to be confused with David Hasselhoff. While Mr. Hasselhoff’s gifts to the world have included ending communism in Europe,and blessing us with this little musical gem (see video below), Heinemeier Hansson is no more hooked on a Railing, than he is focussed on the future, and helping to shape it in a very D.R.Y. way.  (For the uninitiated, David Heinemeier Hansson is the creator of the influential Ruby on Rails framework.  D.R.Y. is one of the motto’s of his Agile framework : Don’t repeat yourself).David (”The Hoff”) Hasselhoff
But the two David’s do share a common influence, inspiring thousands of would be, could’ve been, and other sufferers of a vague inferiority when in the presence, of one of the David’s. Once the malady has been diagnosed, it is far too late to help. When the 40 year old comes home with his shirt unbuttoned down to his beer belly, lifts his sunglasses to peek over the windshield of his GTO convertable, and sighs with satisfaction at a sideways glance into the rearview mirror, everyone knows to keep a solid distance, or to risk being assaulted by more manliness than you can fit in a can. Delivered with that sublime sensitivity only the Hoff could deliver (and right over the Iron Curtain, too!)

Night’s shadow does not draw a deep enough curtain to conceal the irrational exuberance of ambitious projects started on sourceforge, often with great promise, but lacking in that one key element which turns a brainstorm of well groomed linguistic marvels, into revision 1.01. The tabloid bloggers, eager to drop a name, or shout out the programming paradigm particular to patterns and practices in Python, Ruby, or OCaml, rush to lift up each new “framework” which is presented, and decree that it is adorned with those favorable qualities of the day. A sprinkling of buzz phrases in sketchbook of unfinished ideas, a mention of Scaffolding, or Lazy Evaluation, or principles of REST, or Object Relational Mapping, brought out and paraded before the willing, drive an embarrassed sigh, and a few muffled chortles, from gawkers and standers by. It was supposed to mean something at some point in its development, but was utterly lost in the circumstance, schedule and the sense that it lacked that Quality of David (QoD), that some would understand. Each vocal group after Ruby on Rails, Groovy on Grails, ColdFusion on Wheels, Gypsy Lispers on skateboards, thinks they’re bringing the Esperanto of computer languages to the table. But William Shatner never got the memo that he was to be your spokeperson.

2005, David was ordained Hacker of the Year, by Google. That carries more prestige than being knighted by the Queen of England, in some people’s books. And the rock star elite are vaguely aware that they have drawn onlookers, and groupees, and Iwasthere’s, and hopers for the startup which makes billions, and mostly curious people who wonder, what it might be like. Hacker of the Year, not Corporate Evangelist, which is more common than a PHP Programmer these days, the title worn and bruised, the position carrying as much weight as a marketing director, but it beats having to wear a funny hat.

Standing from up in the bleachers, I can see, a plethora of programming languages, frameworks, ontologies, most of them being a halfhearted attempt to imitate what their creators don’t understand. And so there is always so much rubbish, but it is so hard to tell while the game is on and the lights are bright. Once the game has been played, and the locker rooms have cleared, it will be the rubbish that is blown aimlessly over the field of dreams, and the self deluded who have wandered into another romance with their own image. It’s a distraction, an amusement, and a little sad, all at the same time. Occasionally, I feel like I should lean over a railing.

The burst of creativity, regardless of how misguided it is, in some cases, is reminescent of the old days of the late 1990’s. The winners and the successes and the shared glory of all of humankind will be the headlines we remember. Creativity and innovation can be messy, but it’s one of the key reasons why I am in this business.