Clarification and some notes on yesterday's "CFML is dying. Let's drop it off at Dignitas" article

G'day:
I added a coupla things to the "CFML is dying. Let's drop it off at Dignitas" article this morning, after some discussions and more thoughts over night. I'll just summarise them here.

<cfquery> is gone

Queries will be executed much as they are now in Railo / ColdFusion 11 with queryExecute(). I would say that the sql argument can either be a string of SQL [...]

Perhaps instead of representing SQL statements as strings, something like JOOQ could be used? I'm not used it, but it came up in search results when seeing what existing languages did to better represent SQL statements than just in strings.

Arrays

It pains me to say it ("Why do ColdFusion arrays start at 1 instead of 0?"), but arrays will be zero-based. It's dumb that that is how modern languages do it, but it's a point of contention and best to follow the herd with this one.

That said: see the comments against the article, starting with Sean's one, and continuing with my follow-up, and his to mine. The question is... should the actual numeric value of the index be important? Most array looping would be done with an iteration method (like .each()), and generally one just needs to leverage the ordering of an array, not necessarily the numeric value that implements the ordering between one array element and the next. I think perhaps this desire to know the array index comes from a history of using indexed for loops to loop of the index values of the array to then access the elements. That's quite old school. Food for thought.

Closure-functions / callbacks / etc

(And by that I mean stuff like each() / map() / reduce() etc). These will be a heavy focus in the language. And function expressions, IIFEs and all that magic will be promoted. If there's any other functional-programming-esque notions the language can leverage (so being a functional / OO hybrid), it'd be good to hear about them.

Another kinda similar which I might get away with describing under the "functional programming" banner is the concept of generators, which are functions which run to a point (when they encounter a yield statement), then return to the calling code. The next time the function is called it doesn't start afresh, it resumes at the next statement after the yield. This can be leveraged to some quite interesting ends. I thought I had written an article in which I mention these as a suggestion for CFML, but I cannot find it at the mo'.

I've actually raised a ticket for this with Adobe (3555025) and now Railo (RAILO-2942). There's some discussion on this blog article - "Working with infinite sequences in JavaScript" - by Tim Taubert.

I also had an interesting conversation on Twitter with Mark Mandel this morning, which I will reproduce here.

(DE = David Epler; AC = me, MM = Mark Mandel. Both Dave and Mark are people I deeply respect in my sphere of "tech people I know", so they're probably more worth paying attention to than me!)

DE
why create another language that runs on JVM? There are already several other good alts.

AC
Same reasons there's more than one JVM lang now: each have diff. strengths. This is more shaking off CFML's cruft & do a rebrand

MM
I have to ask though - what makes CFML so amazing that is worth investing all that effort into?

AC
A lot of what I suggest would be reasonable features for CFML as it stands. Plus some tidy-up.

MM
Again, what amazing thing does this give us? what's the win here? Your article needs a WHY not just a WHAT.

AC
The "why" is I think Railo will ultimately struggle getting penetration with CFML as it stands. Which I did say. I'm not positioning this as "here's a new language for Mark and David to play with", I'm positioning it as an evolution of "CFML". On the other hand you seem to be suggesting CFML shouldn't be allowed to evolve and progress?

MM
No I'm saying that if you can't say why this is somehow better than current offerings, what's the point? Or another angle - what makes you stick with cfml, other than "Moving is too hard because X", and is that a good enough reason?

AC
FFS. I'm not suggesting Railo "invents a new language" for my benefit. This is not about me. A concept that seems to be an unendearingly foreign concept to people around here.

MM
But your spec is essentially a new lang, so wouldn't it be essentially the same as porting an application to a new lang anyway, no?

AC
Well I think the simplicity of how CFML does a bunch of stuff is nice (YMMV), but the outward "skin" of the language is poor and pretty much everything I suggested there was an ehancement of existing functionality (closure shit etc), or stuff I've already raised (or meant to raise) as features for CFML itself. They all seem "good fits". The problem (IMO) CFML has, and has killed its cred, is some of the crufty tag-based & procedural-based approach it has. So basically suggesting a "reskinning". Parsing <rv:if> instead of <cfif> won't be much work, I think. The changes I'm suggesting are mostly retiring stuff. And then augmenting some other stuff.

MM
unless I misunderstood, your spec dropped/altered a lot of core functionality. So wouldn't you have to migrate existing apps?

AC
This is not like biological evolution. We're not going from Cfml Erectus to Cfml Sapiens. We'd still HAVE Cfml Erectus.

MM
Or is this more for existing cfml shops that want more modern features at a much lower learning curve than a whole new lang?

AC
Pretty much that. I don't want it to sound like CFFORM for Node.js (etc), but I looked at a bunch of excellent features that JS, Groovy, Ruby etc have, &tried to look @ a "how would this fit into CFML". But @ same time redefining CFML also could be leveraged off the existing Railo code base fairly easily, I think. So building on where Railo is strong, but unhamstringing it from some of the shit they need to do to be CFML-compliant.

MM
See that gives us a Why do this :) and a Why to debate. I couldn't find it before.

AC
I did think I had said most of that in the article. Funny (haha) that it seems I can articulate it better in 140char chunks :-| maybe to interpret it that way one needed to be reading the article from the perspective of being inside my head?Happens sometimes

MM
To recap: For those unable to move, a lower learning curve to modern features for new apps, & a shorter migration for existing.

AC
Pretty much.

MM
In which case, you're feeling it would be easier to convince upper management that taking the time to change would we worth it?

AC
Well if Railo still served CfmlOld as well, shops could simply start to migrate across as they see fit. And greenfields work could just use the new "language".

I dunno if that helps people see more where I am coming from. One thing I didn't seem to articulate is that when I said Railo should put CFML into maintenance mode, I meant exactly that. I did not mean remove it. So it'd still serve CFML if one had CFM / CFC files, but if one wanted to use the new dialect (and let's look at it as a dialect, not necessarily a new language), then it's there. So at one's whim, one can ease into it. Or dive in.

I don't really see this as a new language. I see it as a reskinning of the existing language. I happen to really like a lot of what CFML does, I just think it could approach its functionality in a tidier, more contemporary fashion. That's all I'm suggesting here.

I'm also meaning it as a start of a discussion, not the end of a pronouncement, which some people seem to have taken it as. There's some really good comments against yesterday's article: a mix of "for" and "against", too. All good stuff. Make sure to go read it all if you're interested in this topic.

Keep the comments/thoughts/suggestions coming!

--
Adam