I think we should remove the Lucee dialect from Lucee 6.
nobody is really using it, we can leave it in the 5.4 branch.
We can remove a lot of cruft and there are size, memory and minor performance benefits to be gained
I suspect itās usage is so low, because thereās so little documentation about it. Iām not sure how much development time has been spent on it or to support it, but it would seem like a good candidate to remove and reduce the code footprint. Certainly if it could be made optionally, that would make good sense.
Any idea how many people are actually using the functionality?
hardly any bug reports, little documentation, itās no longer maintained
Then it seems like it should be killed. With limited development resources, I think it make sense to depreciate features that arenāt be used so focus can remain on the more critical parts of the language.
5 Likes
I 100% agree, this should be removed to slim the Lucee engine and reduce complexity. Iāve never used it and never seen any code use it.
4 Likes
Iāve only ever heard of it, never looked into it. 
1 Like
It was something that was discussed as a direction for Lucee to go - away from the shackles of Adobeās hold on CFML - but never really fleshed out in any sensible way, largely due toā¦ erm ālanguage design disagreementsā. But then a version of it was chucked into Lucee anyhow.
That was pretty much when I concluded āyou lot have no idea what you are doing, do you?ā and parted ways with what seemed like a good project back in the Railo days, but clearly lost its way shortly after Lucee started.
Soā¦ yeahā¦ def drop it. Should never have been in there in the first place.
3 Likes
first cut of a PR to do this
3 Likes
I tried to use it years ago for an issue where adobe needed the app.cfc to be in root but Lucee needed it in the root/public folder, originally my solution was to make an app.lucee file but that didnāt seem to work, so just renamed that one on Lucee server packages.
When this first came up a few years back I was a little excited about the whole thing. Especially the tag option of removing the cf from the front of the tag and it looking more like so:
current - <cfscript>
proposed - <:script>
I donāt know, it seemed sexier. . . .
But if itās not going anywhere, sounds like it should go.
So my original thoughts on this subject were pretty passive. Having had a little longer time to think on the matter my opinion has changed.
My view point stems from a competitive point of view. Namely, CF vs Lucee. It may have been that Railo now Lucee was initially created to provide an open-source version of ACF. Much effort was put into keeping Railo compatible with ACF so that it remained a viable open-source option.
From an outsiders perspective it seemed that things changed when Lucee was born. Terms like āfasterā, āre-structuringā, āfixingā started to be a consistent theme found in the blog posts. If nothing else, Lucee took on the air of being a competitor if not outright so. Lucee has still kept compatibility a priority while introducing small tweaks to various functions to improve speed and reliability. Also giving thought to the intended purpose of a functions arguments and what a developer thought they were doing but instead getting a different result. Kudos for that! From the āmarketingā Iāve seen, the feeling I get is that Lucee can do it faster and with less impact to the systems itās installed on.
When the idea of a Lucee dialect was first introduced way back when I was very interested. If I remember correctly the idea was to implement features that only a .lc or .lucee file would support while still being compatible with ACF code. I thought āLucee, you clever girlā. Weāll keep the old guard interested and weāll start initiating features in the .lc realm that will be attractive to the new devs coming online but will also impress the grizzled oldies in the field. I had no idea what those features might be, but I was interested in finding out. I thought it a clever way to start making a separation from ACF.
The Lucee dialect could have fought two battles: Technical superiority (covered above) and product separation. Currently when asked what language I use, I tell them āI use Lucee, which is an open-source version of Coldfusion.ā. To the majority I could be speaking in groot. To the few that understand such things they are interested until I say āColdFusionā. Then I get āI thought that language was deadā. To be honest I think that unless youāre an LCF/ACF dev, the āColdFusionā language is dead, to the greater software world that is. To be honest again, I donāt really care what they think. I love the language and since Iām the sole dev for a company of my own making I can do whatever the heck I please. But can Lucee have that same attitude?
IMO as long as Lucee is associated with coldfusion, itāll suffer the same bias because of guilt by association. Continuing to flesh out the LCF dialect and making it feature rich while still supporting ACF functions within a .lc file would be a smart way to go. As the .lc file grew in capability & popularity many devs might just say they use Lucee. Boom, no more reference to ACF. Think about it. Why did Microsoft rename their browser to Edge. They had started to bring Internet Exploder into compliance with W3C standards, but because of its bad rep, it suffered.
I know thereās a lot of opinion here and I certainly have more, but thatās what I was thinking about this fine sunny morning here in Tucson, AZ.
the thing is, the Lucee dialect is basically abandoned and we donāt have the funding / resources to build, maintain, improve and innovate two dialects.
The core lucee cfml dialect has an extensive test suite, all of our users are using it and have a heavy investment in that code base.
Removing the Lucee dialect reduces code complexity, reduces resource usage and will slightly improve performance of our core cfml dialect (i.e. less if lucee {} else cfml {} code paths)
I do appreciate your sentiments Hugh, but Lucee has always been an open source implementation of cfml and that is our primary focus
4 Likes
Lucee Dialect was never formally released. A well developed prototype was included in the server for feedback. By default the dialect was disabled and had to be enabled by would be hackers.
The strategy was to fork from the āstrictā Adobe CFML language interpretation to a more modern Lucee interpretation of CFML where specific features could be defaulted/leveraged/developed without constant compatibility issues.
Sadly this effort morphed into language debates re-litigating legacy CFML design decisions rather than just a vehicle for innovating within the existing CFML landscape, imperfect as it is. So more of a good idea that failed to launch than a released feature-set that was unused, abandoned or poorly executed.
As @Zackster points out we need to focus our resources on core feature set we have. And given that Lucee Dialect never made it out of the gate we should have no qualms about putting it on the bonfire
2 Likes