[Lucee] Stability vs. innovation (was Outsider perspective)

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

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

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:

See my answers between the lines

Micha

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

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.

Whatever we do, we will for sure not do 2 separate project, we will have
one engine with 2 dialects on top of it. Because a lot of settings are
already there, we simple have to add a file extension rule for them, not a
big deal, removing the argument scope for example needs only 2-3 extra
lines of code to make this depending on the extension.
The implementation I have in mind will not produce a lot of extra effort.
https://bitbucket.org/lucee/lucee/src/e6ffd51e0eb0c16d730fc9bf9f6364df8bb63792/lucee-java/lucee-core/src/resource/fld/?at=master
https://bitbucket.org/lucee/lucee/src/e6ffd51e0eb0c16d730fc9bf9f6364df8bb63792/lucee-java/lucee-core/src/resource/tld/web-cfmtaglibrary_1_0?at=master

We will never go for a solution that is producing a lot of overhead.

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.

Same codebase, cfml+ will simply has a different fld and tld file.
https://bitbucket.org/lucee/lucee/src/e6ffd51e0eb0c16d730fc9bf9f6364df8bb63792/lucee-java/lucee-core/src/resource/fld/?at=master
https://bitbucket.org/lucee/lucee/src/e6ffd51e0eb0c16d730fc9bf9f6364df8bb63792/lucee-java/lucee-core/src/resource/tld/web-cfmtaglibrary_1_0?at=master
So we can decide if we make a function available in one or the other
dialect.

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.

Whatever we do, I’m sure the CFML project will be still be important for as
for a long time, it is more a marketing decision, so we will embrace new
users not with CFML anymore.
But don’t forget only teach the engine a new dialect …

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

Both will be actively developed because they are the same…

That would be a wonderful exercise for me as a programmer, but quite
stressful for me a business owner.

That cap’n also mean new business, converting the code for your clients …

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?

Because of that we have started the association, to let the project relay
on more companies and not only Rasia

I couldn’t go back to ACF at that point without another significant
rewrite.

Have in mind that acf is for Adobe just business, I don’t think they make a
lot of money with it, I’m not sure how long acf will still exist…

My codebase wouldn’t be compatible. It’s plainly a financial risk. As a
business owner, why should I take it?

I think that is the only way to get a growing community, se that could be
the best insurance for the future.

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.

Good point, I know that a lot of people selling CFML solutions never sell
them as CFML solution, because CFML does not sell. You simply have to sell
it as JVM based technology, well established in the tech world.

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.

Like I told before, this topic is not new to us and we discussions this
with a lot of the big player in the community already, to make sure it will
be adapted by framework and application developer, what is the most
important point to start…

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?

One engine to dialects
VW sharan vs. seat AlhambraAm Montag, 9. Februar 2015 schrieb Nando Breiter :

On Mon, Feb 9, 2015 at 1:01 PM, Dave Merrill <@Dave_Merrill <javascript:_e(%7B%7D,‘cvml’,’@Dave_Merrill’);>> wrote:

Reference Stewardship: the Sobering Parts Brian Goetz - Stewardship:
the Sobering Parts https://www.youtube.com/watch?v=2y5Pv4yN0b0

“Yeah, you should break his code. It’s for his own good!” @22:34
Evolution with Compatibility @23:10


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAGHrs%3D-%2Bghh3DBy8AMfFEQ2c%3D2QUWy0MYc80mjU%3DEkKcx5gn-Q%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAGHrs%3D-%2Bghh3DBy8AMfFEQ2c%3D2QUWy0MYc80mjU%3DEkKcx5gn-Q%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.