The approach to implementing/designing .lucee

Continuing the discussion from Redux: Rename “component” to “class” in the Lucee dialect:

Well here’s the thing. I think LAS’s entire approach to “planning” and building .lucee is back to front. The approach of starting with CFML, doing a rename, and then bolting stuff on, taking stuff out, changing stuff around is entirely (entirely) the wrong approach. What’s been delivered so far is - I’m afraid - a waste of everyone’s time: it’s just CFML spelt differently. This is of no point or use to anyone, as its basis starts with all the things about CFML which are wrong, out-of-date, only partially realised, etc. With a bunch of stuff that’s good, there’s no denying that too. But no-one needs a “kinda CFML, kinda not, based on a language designed in the 1990s and shows it”. Where’s the market for that? Beyond being an outlet for the LAS dev squad’s mores to “do their own thing”.

Anecdotally, Java looked at C++ and identified an OK basis, but with a lot of hoary bits and set out to create a similar language which was a bit more approachable. C# came along later and did the same thing with Java. However they didn’t start with the earlier language, open the hood and start pulling things out, chucking more stuff in, then standing back and declaring some sort of Heath-Robinson-esque mishmash to be what they set out to do. No. The designers actually… well… designed the new language. From the ground up. They allowed the good bits of the earlier language to influence their design decisions, but it was a purposeful ground-up design.

What I think you should be doing is going to the drawing board and wiping it clean. Acknowledge there’s a body of good work in the internal libraries of the Lucee CFML implementation, but the language that stuff implemented isn’t representative of the direction you think a modern “if we had our time again” language might take.

Revisit core concepts like:

  • what sort of language it ought to be? Is the historically-organically-grown weirdo mishmash of procedural and OO really what you want to be perpetuating?
  • would you want to strengthen the approach to OO that it has (discussions like “component” or “class”)
  • what about data types? We’ve been talking about structs a lot recently, but do they have so much place these days in an OO language, if objects are cheap and easy? Possibly not!
  • should arrays start at one or zero (personally I’m undecided, but err towards 1)
  • lists? No.
  • tags for everything? Or a much smaller subset of tags for using in views?
  • etc

But plan the thing, plan it in a way that yer happy with, then implement it. Don’t build the thing on a platform of sand and weird & poor Allaire/Macromedia/Adobe decisions. Make it your own thing.

Or… just don’t bother. Do it properly, or not at all.

I think the TAG could and perhaps should be helping out with this. To be clear, the members of LAS themselves are in no way responsible for undertaking this - though could/should be facilitating its happening. Creating the TAG is a step towards this but anyone can help out through constructive input and undertaking work (another responsibility of LAS is to ensure that this is easily possible).

Right now the focus of the TAG has been on processing incoming enhancement ideas and requests. I’m not sure what appetite there is for repicking apart the Lucee dialect (given that many of the members were involved with it before) - but there’s probably helpful work that can be done there.

I personally have been very much on the shelf with the dialect. I think it could be a good thing but think rushing it into 5.0 is a mistake (all the good stuff with static components + methods, etc. is more than exciting enough for me). I think that IF we can make the case for delaying the dialect, we stand a chance. I’ll put this forward for the TAG to discuss - I think this is clearly more pressing than discussing many of the minor incoming tickets that there are (not that we need to stop discussing them - plenty of opinion and ideas to go around - action can happen much later).

I am excited about the potential for the Lucee dialect but agree with @adam_cameron and @dom_watson here that we need to design it properly and not rush it into Lucee 5.0.

Whatever LuceeLang 1.0 is, it can’t carry over the “mistakes” in CFML or we’ll be stuck with them there forever as well.

There are some fundamental decisions to be made about LuceeLang. I’ll try to find time this weekend to kick off a series of new threads about the things I think need to be decided before even basic feature decisions can be made. Do we have an appropriate topic tag for meta-language discussions?


Really looking forward to this.

I think having high level conversations about where we want Lucee Lang to go is a great idea. To a degree, this has already begun with the Lucee Manifesto ( ) that @modius posted a while back.

I do also think I have different opinions on the suitableness of CFML as a starting point for Lucee Lang. I’ve always seen this as more of a refactoring of CFML, not the invention of a whole new language. I see CFML as a great language that has modernized, is still productive, and has a pretty good overall organization, but it’s tied down by years of backwards compat, little warts here and there, and the fact that its owned by Adobe. The Lucee Lang dialect to me is an opportunity to break free from all that and begin to move laterally to a place where we can freely correct the things that are wrong, clean up inconsistencies, and introduce new features that would otherwise be too disruptive in CFML.

That’s my understanding of how we arrived where we are today so a discussion of essentially binning CFML and starting with a tabula rasa would equivocate to a rather large change in that direction. I think it’s fair to be able to question everything in Lucee Lang to ask if it should change,but I guess I see a much greater value in taking CFML where it left off and incrementally changing it to a point where we have a new creation based off CFML but free from any of its history.

Now obviously this is a process that is still fairly early-on so it’s reasonable that the divergence between CFML and Lucee Lang is relatively small. If there are items that the community feels should be different, then tickets can be entered and we can have that discussion. I even like the idea of having a series of discussions just to re-affirm the basics of the language. Perhaps this is what you had in mind all along so we’re both on a closer page than I thought.

As far as when this is released, I’d agree it’s not a fully-realized concept yet. I would like to see Lucee 5 get out the door ASAP as an OSGI-based CFML engine (possibly with an alpha version of Lucee Lang for people to play with) and that would give us more time to beat Lucee Lang around into a more finalized form.

1 Like

I don’t believe anyone is actually suggesting that. I’m certainly not (as you’ll see when I post my screed this weekend!). And to be honest, nothing in the Manifesto speaks to that in either direction. There are two specific pieces of the Manifesto, which I’ll quote here (with my emphasis) and will address in depth in my subsequent posts:

Lucee Language has its roots in the ColdFusion Markup Language (CFML) but Lucee Language is not CFML.

Where possible lucee language should facilitate the transition of developers from CFML to Lucee Language.