I think it’s pretty clear the whole .lucee thing is not yet fully-realised even conceptually, let alone being at the stage of implementation.
Personally I think you should scrub the idea completely, But at the very least scrub it right back to the drawing board (and out of the v5.0 product) until you work out what it is.
I can understand wanting to innovate based on where CFML has done ground-work, and also to fill in those infuriating gaps that CFML could have done better but simply hasn’t for one reason or another.
But that in itself is not the starting point for a new language. And what’s a “dialect” (as it’s come to be known) in this context? I think the earliest reference to using that word might well have been my own (I stand to be corrected on that), and I wasn’t being kind at the time. It was used in the context of “piss; or get off the pot”. What’s there at the moment isn’t a “dialect” of CFML. It’s just an ill-thought-out mess. Sorry.
What the concept of .lucee is, though, is the starting point for a discussion. And that discussion has not been had (I saw the beginning of it with IRIS, but even that wasn’t framed the right way). There should be no code representing a .lucee implementation yet. This is demonstrated by the half-formed implementation that currently languishes with zero interest in Lucee 5. It also demonstrates that the people making the decisions to start implementing .lucee in the form that it currently is should not be the decision-makers in how it should be implemented.
All that said, I think Lucee development ought to focus on the CFML engine. CFML as defined by Adobe, but implemented in a more rigorous, faster, more expedient fashion. That’s where the strengths of the LAS dev team lie, and where they excel.
I’ll quote myself from an (at this stage) non-public discussion on this board:
One of the reasons why I was really excited about the LuceeLang idea was that we finally would be able to abandon the terrible, terrible, terrible concept of all those Admin switches and toggles that switch on and off various compatibility or speed features as the users/developers just wanted for their server. It might not occur to everyone right away how bad those switches are.
To me, the out-of-control variety of Admin toggles for language and compiler behaviour is my most-hated thing in Lucee - and was in Railo before, too.
I still stand to that. I think Lucee’s way of dealing with toggles and switches and nobs and this and that is terrible and should not be continued. LuceeLang would have been a great way out of that. There are other ways to improve on that, for sure, but I can’t see LAS moving away from the “we want the product to be configurable as detailed as possible” approach at all. Sure, some administrative configuration is necessary, but I’d be interested to see another modern web platform where server admins can configure themselves mad when it comes to language (compilation) behaviour.
This fits well with the “piss; or get off the pot” context @adam_cameron mentioned above. What does Lucee want to be, if there was no LuceeLang?
And why can’t we then just say:
“Let’s not give a shit about ACF(ML) and truly innovate and move CFML away from compatibility”.
If people want to get the benefits of running Lucee, there then will be a migration cost/project involved on their end, but why trying to stay compatible at all? Just some food for thought.
An interesting idea. At its simplest Lucee 4.x could be seen as a version to maintain for CFML compatibility and security fixes, while 5.x could then be taken as a platform to extend into a better CFML as long as there is a clear deprecation -> upgrade path ( similar to can be seen with, for example, the Ember update path which involves a lot of fixing up deprecations )
Lucee as a language is the only way I see of getting new developers to look at Lucee the server. I currently work for a large CF shop in the corporate space. They decided to start all new development in .NET. As a CF programmer I have the option of learning .Net or finding a new job. This is the 2nd time I have experienced this in the last few years. People are moving away from ColdFusion and the vast majority of ColdFusion developers still don’t know that Lucee exist.
Fighting against the ColdFusion is dead mentality is a waste of time. That ship has sailed.
If you position Lucee as a new language that has the easy of use of CFML without its baggage has a chance of success. Who would signup to be a Pascal programmer but people are programming in Delphi. Lucee the language rids the Lucee platform from the ColdFusion is dead baggage.
Lucee the language should
only included the cfscript version of Lucee CFML.
should turn on the switches that make sense for the platform
allow for new innovation that does not run on the CFML side of things.
I could say more but a decision needs to be made of the future of Lucee the language. I think the idea has a future but it needs a plan and a the backing of the group.
If LAS had pushed that hard right from day one, I would agree with you. I think the divide – the distance from CFML – needed to be there from day one. By this point, anyone investigating Lucee is going to trip over CFML on the website and the mailing list and the Slack channels. It’s going to be really obvious that Lucee is not much more than a rebranding of CFML. It’s too late to separate the languages now – we’re almost a year away from the Lucee launch and the Lucee Language is no further forward than it was then, yet the CFML dialect has had all sorts of enhancements and marketing / discussion. The ship has sailed. I think it’s clear that no one’s heart was really in it back then and what I’m seeing elsewhere here from LAS indicates that no one’s heart is in it today either. A missed opportunity.