Arguments against .lucee extension

dev google-group-archive
21

I’d like to introduce a slightly different angle in this discussion, which
is the observation that CFML is first and foremost a framework. This is the
framework that accepts the request, passes control to CFML code (with or
without Application.cfc) and makes available the different scopes. All CFML
code is tightly coupled with this framework, it cannot live outside it,
which makes this framework actually more important than the CFML language
itself.

Thinking about this, isn’t it strange that nothing has really changed in
the CFML framework since its inception? I mean, we’ve had application.cfm,
request.cfm, etc. since which version? Maybe since before the millennium
even. The progress and insights outside of CFML, mainly MVC, have lead to
many frameworks built with CFML, but you could hold the view (maybe I do)
that this was, in hindsight, actually patching up the CFML framework. Maybe
the CFML framework itself should have adapted, like the .NET framework
incorporated MVC at some point. Additionally, things like websockets and
REST are not first citizen but more or less glued on afterwards. The CFML
framework is aging, to the point of outliving itself.

This might be an opportunity for Lucee: change the framework. Take the Play
framework for example (https://www.playframework.com/). What if Lucee was
built on top of that instead of JSP? This may be a bridge too far for the
moment, but I see some big advantages:

  • We get all the new stuff, battle tested and all. Some things are
    solved in new ways, like concurrency.
  • Lucee has/is an MVC framework from the ground up, which is a good
    thing for everybody, including developers that are looking to switch.
  • And, last but not least, Lucee can position itself as independent of
    Adobe and ColdFusion, while still being true to CFML.

There would be no need to change the CFML language (yet), but it would be a
new direction. A nice compromise between some of the standpoints voiced
here.
This whole thing would be a daunting task, certainly. A migration path
would be necessary, etc. As I said, probably a bridge too far right now.
But looking at the state of the CFML framework, I can’t deny the feeling
that it’s holding CFML back. Maybe a drastic move like this is needed.

Thanks for reading this far.
Jeroen

22

I was never speaking about a new language, I was always speaking about a
dialect on top of the engine.
The current idea is as follows.

We review all possible runtime and compiler settings and we define for
every one the default behavior for this dialect, this includes of course
also settings new to lucee 5 like “handle unquoted tag attributes as
variable|string”.
We review the core tag and function library, for example we remove the
function “dateFormat” and rename “lsDateFormat” to “dateFormat”.
The libraries also define the prefix of tags (cf) and if not existing tags
are ignored or not. So we can also control this behavior.

All I was taking about is covered by this…

It has to be more ambitious than that, otherwise it’s not a good use of
your time, IMO.

What pain point is what you describe actually addressing? Is anyone
actually clamouring for these compiler/runtime settings to be “hardcoded”
via using a different file extension? Is starting a new file extension so
as to be able to obsolete/tweak some functionality something you see other
languages doing?

It really seems to me that this is an exercise in quelling your own
annoyance about some of the idiosyncrasies that CFML has acquired over the
years. I think you’d just gotta accept that you chose to do your own
implementation of somebody else’s idiosyncratic language, and just live
with the idiosyncrasies like the rest of us do. What you’re describing
isn’t a language “dialect”, it’s more like doing a spell check.

Well when I think about it now… it’s more actually dealing with some of
the shortfalls in Railo’s approach to things, in that it accumulated all
these settings which varied how the compiler and runtime works. Maybe you
should just ditch them from Lucee (5) and revert to simply behaving how
ColdFusion does, in all these non-conformist areas. I think the gain in
cross-compat and coherency would perhaps be a better solution than having a
whole new file extension to sort out some dodgy settings.

What you’re suggesting will just dilute Lucee’s credibility even further
(than it has been after forking from Railo, I mean).

Now I could understand if you were taking the lessons we’ve all learned
from CFML’s shortfalls and then creating a new language “inspired” by that
(and diverging from the bad rep CFML has, etc), but… that’s a huge
undertaking (language design and marketing), and I think you (both Micha
and LAS) would be over-extending yerselves there, and on a very risky
project. As others have said… there’s no shortage of well-established
alternate languages out there already, and something would need to be
pretty bloody special indeed to penetrate that space. “greatly improved
CFML” won’t be that thing.

In conclusion: my opinion is to rethink this whole “.lucee” idea entirely.
Then put it to bed.On Friday, 13 March 2015 15:47:32 UTC, Micha wrote:

–
Adam

23

I think you need to polish your reading & comprehension skills, Andrew. The
only one mentioning “fault” here is you.

If anything, I implied the fault is Adobe’s, but I was also observing
that “this is the reality that we live in”.

Given Lucee knows that Adobe won’t follow their lead, then I think it’s
unhelpful - to the CFML community - for Lucee to persist as if it does lead
CFML development. It doesn’t. Adobe - for better or for worse - does. Lucee
I think needs to be realistic about this.

There was a point at which Railo had possibly enough traction behind it to
start leading CFML dev, and perhaps it could sway Adobe: Adobe did copy a
few things Railo introduced, after all. However it’s clearly not on Adobe’s
agenda to be helpful to their community, so bearing that reality in mind, I
think Lucee kinda needs to not make things worse by pretending it does lead
CFML development. I think diversifying CFML only serves to dilute it, not
make it stronger.

I also think the fork from Railo to Lucee lost a lot of the traction and
credibility that Railo used to have. Perhaps once Lucee re-establishes
itself as a working, credible CFML solution, then they can see whether it’s
viable for them to try to lead again. There’s more to this sort of thing
than the fact the underlying codebase and dev personnel are the same, I
think.–
Adam

On Saturday, 14 March 2015 10:23:03 UTC, Andrew Dixon wrote:

How is it Lucee/Railo fault that Adobe choose to copy but implement it
differently? Surely that is a ACF issue and not a Lucee/Railo issue. It is
Adobe causing the incompatibility not Lucee/Railo.

At this point I think it is just a matter of Lucee doing its thing and
ignoring Adobe entirely. Lucee needs to be Lucee and that’s that from my
point of view. Micha is trying to find a middle ground with the .lucee
extension so that we can bring CF developers along and have somewhere for
them to go when (not if) Adobe abandon CF. Lucee cannot be held back by
Adobe and their “manager” (not developer) centric view of how the language
should develop (cfclient).

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - Member

On 14 March 2015 at 09:29, Adam Cameron <dac...@gmail.com <javascript:>> wrote:

On Saturday, 14 March 2015 09:18:35 UTC, Chris Blackwell wrote:

Either LAS feels it has the capability to move CFML forward and evolve
the language, or it wants to remain an ACF compatible language.

Which will it be ?

TBH, my opinion of Lucee has circled round back to where my opinion
started with Railo when I first encountered it (v3): just copy ColdFusion.
Make the app server faster, smaller, etc, make the code compile into better
bytecode, but from the CFML perspective… don’t diverge at all: follow
Adobe’s lead.

As bad as some of the decisions Adobe make are, I don’t see some of the
decisions going into Railo being that much better at times, and given Adobe
don’t seem prepared to pay attention to how Railo has initiated change (eg:
the way the generic tags->script was implemented in CF was completely
different to how Railo was already doing it), then I think
Railo^h^h^h^h^hLucee is actually doing the community a disservice by
attempting to drive the language forward. It just leaves a mess for us
CFML developers to have to work around.

I think a lot of the things Railo initiated were very good when taken
in isolation, but the reality has so transpired, IMO, that one can’t
take it in isolation.

–
Adam

24

Is starting a new file extension so as to be able to obsolete/tweak some
functionality something you see other languages doing?

this is my main objection to the whole .lucee concept. Unless you’re doing
something radically different in language structure, then don’t invent a
new language. changes to compiler flags, scoping behaviours etc should be
handled by having a clear road map, a deprecation period and then breaking
backward compat at some sensible predetermined point, like a major version
release.

Other languages seem to have survived breaking backward compat without too
much problem, but its seems people are still worried about compat with ACF,
or this really wouldn’t be an issue. Its really a case of “shit or get off
the pot”. Either LAS feels it has the capability to move CFML forward and
evolve the language, or it wants to remain an ACF compatible language.

Which will it be ?On 14 March 2015 at 09:05, Adam Cameron <@Adam_Cameron1> wrote:

25

I think you need to polish your reading & comprehension skills, Andrew

That will be my chronic dyslexia getting in the way!!!

Anyway, you can’t lead when you are copying what has already been done by
your rival!!!

Adobe are clearly not developer focused, as you well know, and the Lucee
team is. My point is that Lucee just needs to get on and do what it does
best and serve the developer community it has.

Therefore if the community wants ACF compatibility, which it clearly does
in some case does, then that is part of what Lucee needs to do, but it also
has another set of developers, like myself and my team, that want to be
able to use stuff outside of the ACF compatibility realm then Lucee needs
to do that as well, hence the suggestion of a two tier approach.

Most of the arguments here (not from yourself) seem to be about people
believing they are going to lose the ACF compatibility and that is entirely
not the case. Lucee is going to keep the ACF compatibility but extend out
into a new realm with the Lucee “dialect” (CFML++, CFML 1.5, CFML Next,
whatever you want to call it).

At some point down the track the community position might have moved so far
away from ACF compatibility that it is not longer worth keeping and at that
point then Lucee could choose to remove it, but for now it is going no
where, in fact Micha did a “fix” this week for an ACF compatibility bug
(see “requesttimeout=“0” throws exception on Lucee 4.5.1.000” post).

If the decision was taken by LAS to only follow Adobe’s “lead” then I for
one would be, as they say on Dragon’s Den, “out”.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - MemberOn 14 March 2015 at 10:36, Adam Cameron <@Adam_Cameron1> wrote:

I think you need to polish your reading & comprehension skills, Andrew.
The only one mentioning “fault” here is you.

If anything, I implied the fault is Adobe’s, but I was also observing
that “this is the reality that we live in”.

Given Lucee knows that Adobe won’t follow their lead, then I think it’s
unhelpful - to the CFML community - for Lucee to persist as if it does lead
CFML development. It doesn’t. Adobe - for better or for worse - does. Lucee
I think needs to be realistic about this.

There was a point at which Railo had possibly enough traction behind it to
start leading CFML dev, and perhaps it could sway Adobe: Adobe did copy
a few things Railo introduced, after all. However it’s clearly not on
Adobe’s agenda to be helpful to their community, so bearing that reality in
mind, I think Lucee kinda needs to not make things worse by pretending it
does lead CFML development. I think diversifying CFML only serves to
dilute it, not make it stronger.

I also think the fork from Railo to Lucee lost a lot of the traction and
credibility that Railo used to have. Perhaps once Lucee re-establishes
itself as a working, credible CFML solution, then they can see whether it’s
viable for them to try to lead again. There’s more to this sort of thing
than the fact the underlying codebase and dev personnel are the same, I
think.

–
Adam

On Saturday, 14 March 2015 10:23:03 UTC, Andrew Dixon wrote:

How is it Lucee/Railo fault that Adobe choose to copy but implement it
differently? Surely that is a ACF issue and not a Lucee/Railo issue. It is
Adobe causing the incompatibility not Lucee/Railo.

At this point I think it is just a matter of Lucee doing its thing and
ignoring Adobe entirely. Lucee needs to be Lucee and that’s that from my
point of view. Micha is trying to find a middle ground with the .lucee
extension so that we can bring CF developers along and have somewhere for
them to go when (not if) Adobe abandon CF. Lucee cannot be held back by
Adobe and their “manager” (not developer) centric view of how the language
should develop (cfclient).

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - Member

On 14 March 2015 at 09:29, Adam Cameron dac...@gmail.com wrote:

On Saturday, 14 March 2015 09:18:35 UTC, Chris Blackwell wrote:

Either LAS feels it has the capability to move CFML forward and evolve
the language, or it wants to remain an ACF compatible language.

Which will it be ?

TBH, my opinion of Lucee has circled round back to where my opinion
started with Railo when I first encountered it (v3): just copy ColdFusion.
Make the app server faster, smaller, etc, make the code compile into better
bytecode, but from the CFML perspective… don’t diverge at all: follow
Adobe’s lead.

As bad as some of the decisions Adobe make are, I don’t see some of the
decisions going into Railo being that much better at times, and given Adobe
don’t seem prepared to pay attention to how Railo has initiated change (eg:
the way the generic tags->script was implemented in CF was completely
different to how Railo was already doing it), then I think
Railo^h^h^h^h^hLucee is actually doing the community a disservice by
attempting to drive the language forward. It just leaves a mess for
us CFML developers to have to work around.

I think a lot of the things Railo initiated were very good when taken
in isolation, but the reality has so transpired, IMO, that one can’t
take it in isolation.

–
Adam

–
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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f75a03d9-8a8a-43b4-8db6-160e51a68ad6%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f75a03d9-8a8a-43b4-8db6-160e51a68ad6%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

26

Either LAS feels it has the capability to move CFML forward and evolve
the language, or it wants to remain an ACF compatible language.

Which will it be ?

TBH, my opinion of Lucee has circled round back to where my opinion started
with Railo when I first encountered it (v3): just copy ColdFusion. Make the
app server faster, smaller, etc, make the code compile into better
bytecode, but from the CFML perspective… don’t diverge at all: follow
Adobe’s lead.

As bad as some of the decisions Adobe make are, I don’t see some of the
decisions going into Railo being that much better at times, and given Adobe
don’t seem prepared to pay attention to how Railo has initiated change (eg:
the way the generic tags->script was implemented in CF was completely
different to how Railo was already doing it), then I think
Railo^h^h^h^h^hLucee is actually doing the community a disservice by
attempting to drive the language forward. It just leaves a mess for us
CFML developers to have to work around.

I think a lot of the things Railo initiated were very good when taken in
isolation, but the reality has so transpired, IMO, that one can’t take it
in isolation.On Saturday, 14 March 2015 09:18:35 UTC, Chris Blackwell wrote:

–
Adam

27

How is it Lucee/Railo fault that Adobe choose to copy but implement it
differently? Surely that is a ACF issue and not a Lucee/Railo issue. It is
Adobe causing the incompatibility not Lucee/Railo.

At this point I think it is just a matter of Lucee doing its thing and
ignoring Adobe entirely. Lucee needs to be Lucee and that’s that from my
point of view. Micha is trying to find a middle ground with the .lucee
extension so that we can bring CF developers along and have somewhere for
them to go when (not if) Adobe abandon CF. Lucee cannot be held back by
Adobe and their “manager” (not developer) centric view of how the language
should develop (cfclient).

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - MemberOn 14 March 2015 at 09:29, Adam Cameron <@Adam_Cameron1> wrote:

On Saturday, 14 March 2015 09:18:35 UTC, Chris Blackwell wrote:

Either LAS feels it has the capability to move CFML forward and evolve
the language, or it wants to remain an ACF compatible language.

Which will it be ?

TBH, my opinion of Lucee has circled round back to where my opinion
started with Railo when I first encountered it (v3): just copy ColdFusion.
Make the app server faster, smaller, etc, make the code compile into better
bytecode, but from the CFML perspective… don’t diverge at all: follow
Adobe’s lead.

As bad as some of the decisions Adobe make are, I don’t see some of the
decisions going into Railo being that much better at times, and given Adobe
don’t seem prepared to pay attention to how Railo has initiated change (eg:
the way the generic tags->script was implemented in CF was completely
different to how Railo was already doing it), then I think
Railo^h^h^h^h^hLucee is actually doing the community a disservice by
attempting to drive the language forward. It just leaves a mess for us
CFML developers to have to work around.

I think a lot of the things Railo initiated were very good when taken in
isolation, but the reality has so transpired, IMO, that one can’t take
it in isolation.

–
Adam

–
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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/77e452b4-3258-4719-835c-11c962c61c31%40googlegroups.com
https://groups.google.com/d/msgid/lucee/77e452b4-3258-4719-835c-11c962c61c31%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

28

@jeroen What a fascinating idea. I’m impressed by the Play framework,imagine that Play for Java, Scala and Lucee.

I’ll be looking forward to hearing responses on this topic.

Adam (not THAT Adam) Chapman :wink: