If I understand correctly, the tradeoff is an improvement in execution
speed and nicer Lucee internals, at the cost of forcing every app that uses
the arguments scope to be rewritten using the
local.args=duplicate(local); construct (or perhaps more clearly, using
If I’ve got that right, IMO that’s a poor tradeoff.
The idea being expressed here seems to be that you would only have to
rewrite your applications if you want to move them to this new version of
CFML, whatever you want to call it (CFML+). Lucee as an application server
would still support the current version of CFML. However, as a business
owner, I’m having doubts whether it is feasible for such a small
development team to manage a project with a suddenly much larger scope. I
would assume that given the lack of resources, the ol’CFML area of the
codebase would be neglected to focus on the shiny new CFML+ area, no matter
what dev team’s intentions may be. Which would leave development on the
ol’CFML area effectively dead, or at least withering rather quickly. If
that’s a wrong assumption, then please explain why, not only to me, but
likely to many others listening in.
The changes being discussed here would touch nearly every function in my
codebases, and perhaps many, if not all, of the display templates. For me,
this would mean many months of work to rewrite everything without
revenue, to stay with a language that was being actively developed and
That would be a wonderful exercise for me as a programmer, but quite
stressful for me a business owner. What do I do if and when Micha decides
to leave the Lucee project? Will Lucee have enough momentum by then that
others will step in to fill his shoes? I couldn’t go back to ACF at that
point without another significant rewrite. My codebase wouldn’t be
compatible. It’s plainly a financial risk. As a business owner, why should
I take it?
Nobody has been talking much about these risks here, or at least the
perception of risk. Employees generally won’t be making the decision to
move to the Lucee version of CFML+. That will be left to business owners.
And for business owners, stability, and the perception of ongoing
stability, is going to be much more important than whether or not
functions have an arguments scope, arrays are 1 or 0 based, or query syntax
and array syntax are essentially the same.
Not sayin’ the language should not be improved, at all. But if we are going
to be taken seriously, I think we need to be concerned about the image we
cultivate in regards to change and stability towards business owners, and
anyone else with a stake in existing codebases written in CFML. Yeah, CFML+
might be able to attract new developers for new projects, but I’d be wary
of losing the momentum the Lucee project has from its current support base.
Or to put my opinion more bluntly, give it more “bottle”, if that’s an
appropriate use of the slang, Adam, as an example, might be a great
contributor to the discussion and an astute study of computer languages,
but until he convinces his company to move from PHP to Lucee, and his boss
makes his continued employment conditional on the financial success of the
move, he doesn’t have much skin in the game.
So yes, let’s change CFML for the better, definitely. But it will only be
folks with skin in the game, lots of it, that decide to use Lucee in a
serious manner, and therefore be in a position, and of the inclination, to
seriously support the project. So I think it’s important for Lucee to take
the needs these folks into account while blazing a new trail, because those
with skin in the game are the ones who will create momentum.
To me, that’s the tradeoff - stability vs. innovation. Or better expressed,
how can this apparent tradeoff be minimized to the point where it becomes
stability + innovation?
Reference Stewardship: the Sobering Parts
“Yeah, you should break his code. It’s for his own good!” @22:34
Evolution with Compatibility @23:10On Mon, Feb 9, 2015 at 1:01 PM, Dave Merrill <@Dave_Merrill> wrote: