The (Missing) Lucee Language spec

language
1

Ok, this topic has bubbled up a few times here and there and there’s apparently been various opinions between moderators and some other contributors on how this should be brought up.

Let’s talk about the (missing) Lucee Language spec.

It’s clear there’s an interest in the Lucee dialect/language (whatever people would prefer naming it). What is missing is an actual Language specs defining the goals of what Lucee should achieve and solve.

What currently seems to happen publicly is that individuals from LAS and the wider community comment on chosen topic threads in this forum — by chosen I mean they seem to be either driven by @micstriit asking for feedback or other community members making enhancement suggestions from the left field; some of them being very good, some others I would rather strongly disagree with (I’m trying to be polite here - what I’m really referring to is on the spectrum from “meh, not a good idea” to “absolutely lunatic”). And frankly, ideas of the type: “Hey, we should do this!” followed by a quick implementation without further reflection very often turn out to be the worst things for a long-lasting language design.

I’m sure there’s more happening behind the scenes and I’d truly hope that the LAS members have all the knowledge of what Lucee is gonna be and how it’s specced etc… and if it’s the purpose and intention of this process to keep it closed — then fine. Personally, I’d strongly disagree with it, but it’s up to the members how they want to run their project.

Now, here’s the constructive part:

What I’d rather want and suggest instead is: an open, transparent process designing the Lucee language. Lead by a group of people who have the theoretical and/or practical experience of working on language specs and/or have a deep understanding of both CFML and other modern languages and paradigms.

I’ve said multiple times to a wide variety of people that Lucee needs a language steering group, but that doesn’t seem to be happening (at least it’s not communicated to the public).

The outcome of this process should be a language spec with decisions made by actually putting a group effort into solving questions like: Why or why not would Lucee need a “:” namespace? Which tags are clearly not needed anymore? Which paradigms do we want to support in which way: Closures/Lambdas/more functional features etc.? Even a fundamental question like: “What problem does Lucee solve?” should be answered properly by coming up with a mission statement.

After all that’s been done (or partly in parallel) implementation starts. And the Lucee language then gets released when it’s ready for an alpha/beta etc and not to necessarily make it into Lucee 5.

I know a lot of people in the inner circle of LAS have an issue with what (and maybe how) @adam_cameron and Sean Corfield are saying re the new Lucee language; but let me tell you that both of them have very valid points and ignoring those voices is the absolutely wrong way forward for LAS.

Personally I’ve got no whatsoever monetary and commercial interests in the success or the failure of Lucee & the LAS and am not associated with any product that members of the LAS might or might not develop on top of LAS; I like Lucee and CFML as an idea and I just hang out here and contribute bits and pieces for personal fun and try to make it better at this stage. But even to me it’s easy to understand how the current loose approach can lead to a lot of frustration and people not joining or leaving a community due to uncertainty and no one really knowing what’s going on with the new Lucee language.

In a wider sense this topic comes back to general communication issues the LAS has and has to work on. And to be fair, LAS has done a really good job with putting @modius in charge of that and providing explanation and communication around the fork, the legal aspects and all what’s hooked into that. I’d just like for someone in LAS (and maybe it should be @modius again because he’s clearly a very calm and patient voice of reason) to take charge of the Language spec for the Lucee language and open up the process.

3 Likes
2

Here, here Kai - well said. I am in the same boat as you as far my interest in the success of this project. In the end, I truly want to see the direction of this project articulated and after listening to Geoff on your podcast, I agree that he seems well suited to it.

Sometimes it’s amusing to grab some popcorn and watch the fireworks when certain personalities clash. Apparently tone/language irks some more than others - not me at all, but whatever. I find the input to be insightful, important and, frankly, vital. So I hope everyone keeps coming here.

3

I agree we need at the very least a public brief that outlines the goals of Lucee Language, and what we hope to achieve with respect to a Lucee 5.0 release.

While the intent has been articulated, repeatedly, in several forums there is no central point of reference nor a clear set of deliverables that people can pick at.

Now that we are getting close to a stable foundation for the next-generation Lucee engine, its becoming more and more critical to provide some clarity around Lucee language. I get that — LAS gets that.

LAS is working on a proposal for the language that outlines the modest expectations for the initial release. It won’t be earth shattering but it will provide more clarity.

Ahead of that proposal…

The overall intent of Lucee Language is not to create a completely new paradigm. It’s purpose is to enable us to take CFML forward with a new dialect (.lc/.lucee), while maintaining compatibility with Adobe ColdFusion on the existing dialect (.cfm/.cfc).

Many of the “features” slated for Lucee Language 1.0 already exist in Railo (ie pre-dating Lucee fork) but cannot be enforced without shattering compatibility with apps that run on ACF. We want to enforce these standards as part of Lucee Language, while still allowing users to run their CFML apps.

For example, we cannot change the way scopes cascade in CFML as it will break compatibility. Options already exist in Lucee that allow for strict cascading, and consequential security and performance improvements. These will be enforced in Lucee Language.

For example, we cannot change the default scoping of variables in CFML components without breaking compatibility. We want to enforce these alternate defaults as part of Lucee Language, while still allowing users to run their CFML apps.

How do we alter syntax, or tag attribute changes, or core functions without breaking CFML compatibility — or worse, constantly managing two separate approaches in the one dialect (Lucee’s preferred approach and Adobe’s less preferred approach)? How can we introduce new features that do not exist in ACF? We need a new dialect; Lucee Language.

So the goals of Lucee 1.0 are modest; CFML with all the best options of Railo/Lucee server turned on, and without the baggage of backward compatibility, and historical but awkward language choices… These goals set the foundation for how we can move forward with a CFML-like language that is de-coupled from Adobe.

When we talk about Lucee “Next Gen” being an architectural foundation for this — it’s really about getting in place the machinery to allow us to run two separate dialects of essentially the same language side by side, and to allow these dialects to diverge overtime without jeopardising our commitment to ACF compatibility.

Frankly, if you like CFML and are interested in its future I think its a brilliant strategy. If on the other hand you have less interest in CFML, and more interest in another language entirely, then Lucee Language might not be for you.

Why would Lucee Language appeal to non-CFML developers? For the same reasons CFML appealed to many of us in the first place. CFML rocks. But we’re not happy standing still. We want more from CFML.

4

Thanks for responding, @modius — this is a very useful start imho. Comments and further questions/items inline…

I think a lot of what you said above is very true and can be a starting point. But it raises a strong question re community involvement:

Why is LAS releasing a proposal outlines the expectations for the initial release but hasn’t involved its community of (expected/targeted) users — or involved only in a very tangential way?

The assumption here is that the foundations of the new language (and please note I’m clearly distinguishing this from the foundations of the architecture of Lucee 5) are being built and decided on behind closed doors of LAS (I assume by its members).

[If one wanted to take it in a malicious and negative way, one could well argue that this approach is not much better than the approach of a lot of commercial software companies that would throw an alpha at their users after having magically determined (= “marketing has guessed”) the features people might or might not want in version x of the product.]

I’m not at all saying you’d not be entitled to do it this way, but I don’t like it and I think it’s the wrong way for Lucee. See my original post re open and transparent involvement and how I think it should be done instead of the status quo.

There we go - this is pretty much very close to a basic mission statement that I asked for in my post. Seen from a pragmatic point of view, that’s not it though - right? In Lucee 1 you’d for instance change all tags from CFsomething to :something — and I think even this decision needs to be looked at again. Decisions like Component vs Object and many more have pretty much been already made by @micstriit and others in LAS. Some of those decisions have been discussed by some interested folks on the public Lucee list, some others in this forum, some further ones probably haven’t been discussed.

And I’m the last person saying that every little feature (change) has to be run by and discussed by every single person on Earth ever having used Railo or Lucee or ACF. However, this issue is that not even the big picture had been presented to anyone until pretty much now. Is there a strategy beyond

that anyone else but the core implementers of Lucee Language have worked on? Are there any architectural principles — referring to the discussion about adding and abort-attribute to cfinclude and how do those get weighted against “pragmatic” (and sometimes bad practice coding) requests etc.

In reality we’re not talking about a proposal for a Lucee Language that LAS is going to produce, but we’re talking about an already quite involved and quite-ready first alpha or beta of the language.

And again - LAS is absolutely entitled to do whatever they want. However, the way how I currently see things going from a language evolvement point of view, the following applies:

a) Lucee is currently NOT a real community-driven project to me. It might allow interested users/community members to voice an opinion on some things that might or not be taken into consideration by the implementation team.

b) It at the very least seems that the majority of the language-/future-related decisions are made behind closed doors by the $-paying LAS membership.

Both a) and b) are fine and a valid approach to run thing provided they’re communicated clearly, then everyone would be on the same page. Actually, I limit the statement re b) — this approach is not ok because just by paying a membership fee one is not necessarily (or at all) qualified to decided on the future of a language or platform.

As long as those and other points are not sorted, this is much less of a community-driven project than LAS is trying to sell it as.

5

And just to make sure this thread stays relevant and constructive - I’d really love to hear from others re:

a) If they think the current approach (or non-approach depending on their point of view) used by LAS re the Lucee Language 1.0 is the right way forward,

and more importantly

b) What would an alternative (presumed better) process / community involvement look like from your point of view.

6

Let’s not forgot, this project is just getting started… Anyone is free to make proposals at any time, but I assume 99% of the community is awaiting LAS to lay the ground work for the spec document – which @modius said LAS is working on – and for clarification around how features are accepted.

As for being community driven… all of the LAS members are long standing CFML community members. Every project needs leadership and I’m sure there will be non-“Member” participants who have significant say at some point. The fact that the current leadership is only “$-paying” is more of a sign of the infancy of the project than anything else, so I wouldn’t be reading too far into that.

7

The following was already communicated in the mailing list (i can find the thread atm).

In the beginning the idea of the Lucee dialect was to have an independent fork from Lucee/Railo for this, not only a dialect in the same engine.

The code name of this project was “Iris”. We had a steering committee that discussed for weeks over every possible details of this language.

We had a sheet where every participant could vote and every details. I have also published this sheet in the thread (see above) but i have removed the name of the participant in that sheet (can find that either, but i will attach here asap). So the Lucee dialect is not based on my ideas at all, it is based on the votes of this steering committee! what includes people of the current discussion.

8

Clearly we are well outside the status quo for consultation that was once Railo or is now Adobe; otherwise we wouldn’t be having this discussion at all :wink:

The practical reality is that somebody has to come up with a concept for moving the language forward. That concept has to be reasonably well realised before it is opened to wider participation; can it be done, do enough people think it has value, will anybody be prepared to build it? Otherwise its just words in the wind.

That initial conceptualisation has to start with a nucleus of people; ideally a group that cares deeply about the problem, and is prepared to fund a solution either with time or money. Without that foundation literally nothing would be possible. That nucleus is the LAS membership, and its invited representatives.

As custodians of the underlying code base, we hope to be as inclusive as possible by putting forward our ideas to the wider community once they have enough “meat”. Don’t forget that LAS is a fundamental part of the community itself, and by definition our ideas are community driven.

The LAS approach with respect to Lucee Language has been more consultative than you might realise, and has included the views of a wide cross section of the community, well beyond the official Membership of LAS, to get to this point.

Our commitment to the community should be judged by our capacity to listen and to change based on well reasoned arguments. Not by our inability to include everyone in the initial ideation phase for larger aspects of the Lucee roadmap.

I would say that ALL language decisions are decided by those with a capacity to actually implement those language decisions; ie with pull-requests or investment. That is the very foundation of open source development.

That said, LAS is very open to ideas:

  • we don’t really have any restriction to becoming a member beyond enthusiasm for the cause; of course there is a Membership due but it is less than the cost of Adobe ColdFusion Enterprise per annum
  • we welcome anyone with open arms who has the commitment to make a pull request
  • if anyone has an idea we’re happy to hear it; we’ll even consider funding it if an individual is unable to make that pull request on their own

Post ideation phase, everyone is encouraged to contribute their views.

We’re absolutely reaching this stage. There haven’t been any “set in stone” decisions for any of these questions. I for one would welcome a robust discussion about the namespace, the extension and the specific cruft that we should be putting a flame thrower to.

9

The Lucee dialect is based on the decision made by the “Iris steering comitee” where important parties of the CFML community was involved. From parties highly depend on CFML to parties not doing CFML at all in their daily business.

This are the decisions made by this parties, what was the base for Lucee:

(i have removed the names of the parties involved )

So this was not a public process, but it was a process with representatives of the community.

10

So nothing new really. Pretty weak goal IMO. This will create the (wrong?) impression to devs that Lucee dialect is just CFML with predefined settings and missing the cf prefix. Why would this draw anyone’s attention?

11

Because CFML is the best language out there, it just has no a very good reputation and a lot of package of the past.
We don’t have to reinvent the weel, we only have to clean it and take the 8 out of it.

1 Like
12

I’d disagree with this, the project is not just getting started. It’s about 6 months old and probably cooking in the minds of some people previous to that. It’s not asked too much if there’s a demand for a spec, directions etc beyond what is/was available so far.

13

So let me ask you - why are the names of the people who were involved in the closed Iris group not available. I struggle to see how this can be justified now that even @alexskinner discussed some of them on @adam_cameron’s blog in the comment thread?

Seriously - what’s the secret here? Everyone knows that it’d be for sure you, @adam_cameron and Sean Corfield. Who were the other participants?

14

I don’t think that’s the right conclusion to take. I’d strongly hope there more to it.

Personally I think it’d be unwise to release exactly those two things only as LuceeLang 1.0, but given that there’s no language spec and plan publicly available at this stage we really don’t know. Even for a 1.0 release you’d want some significant clean-up to happen at the minimum,.

15

…

I.e. Money speaks.

Sure, I won’t deny that some of the members of LAS involved have a standing reputation for being active in the community. Others might or might not have.

Still, everything happens behind closed doors. Surely there are discussions behind LAS members going on. There must be meetings via Skype, email exchanges how to do x, y, z in the language? You don’t find it worthwhile making all those things transparent on a read-only-level at the minimum? Recording of “Language planning meetings” etc?

Or provide a list of all the active representatives who currently drive the Lucee Language development. Just a list of names, that’d be it.

And again, money speaks! :smile:

So, to sum it up - if one wants to provide input and be heard in the ideation phase, one would have to pay the membership dues or shut up (expressed in a very black-and-white way, I’d grant you that).

Re the pull request — it’s impossible to do a pull request for anything regarding Lucee Lang 1.0 at this stage, you realise that? Sure I could change the tag prefixes to kk:ldap or something, but that’s entirely pointless because it won’t be accepted. Pull requests for a spec document however would be great at this stage, but given that there is none… well…

And this is exactly the issue. There haven’t been any decisions, any discussion, nothing. And that needs to change rather soon.

16

I’m not sure how my statement constitutes an “issue”.

There has been considerable discussion and consultation about this very topic, well beyond the membership of LAS. And now we are ready to bring those deliberations to a wider audience.

Are you assuming that Lucee 5.0 is about to ship with Lucee Language in its current state? It is not.

When Lucee Language is deemed ready to ship it will ship. If deliberations about the language are going to significantly delay the release of Lucee 5, Lucee Language may only ship as an experimental option that is formalised in a later release. None of this is decided, but with your help I’m sure it will be that much better for it.

17

That’s exactly what I’m assuming and what the current state of affairs seems to be given the impression of the “wider community”.

18

I was uncertain of the NDA status before, but as Sean reminded me, Alex “outed” me anyhow. Although I think I had already alluded to this (inadvertently, because I wasn’t thinking) in public prior to that.

For the record, I am “voter 1” in that doc.

I will say though:

  1. not all my votes there are representative of my actual opinion. There was an urgency to reach consensus rather than discuss things, so I just went with the flow sometimes, sometimes against my better judgement. But I hasten to add that probably 95% of my votes are representative of my opinion.
  2. What I signed-on to assist with was far more ambitious than where it ended up heading, for one reason or another.
  3. I kinda lost interest and ceased participation in the project due to 1+2.

I was also quite surprised to hear that what’s been presented as .lucee is a realisation of those Iris discussions. Perhaps it’s where .lucee is heading though, rather than where it’s at now? Dunno.

–
Adam

1 Like
19

No. Ideas speak.

LAS Members make contributions to a not for profit organisation; it has bills to pay. Membership doesn’t guarantee your idea will become a reality, although it likely means you will be aware of what those ideas are from an early stage.

Lucee Language is a concept that comes from outside of the LAS Membership.

But how is this relevant?

Lucee Language is a major roadmap idea; it has to be conceived before it can be presented for scrutiny. It is now in the process of being presented for wider discussion after having been conceived, fleshed out with a smaller focus group, and the engine primed for its implementation. We’re now talking about the specifics.

Anyone could have conceived the idea of Lucee Language and presented a specification; either directly in this forum, or by contacting LAS or one of its members directly.

20

Well then LAS have failed to communicate timelines appropriately.

Lucee 5 currently has no set release date. It is in beta. The feature set of Lucee 5 has not been finalised. While we would like it to include Lucee Language, we don’t want it to include a busted-arse version of Lucee Language.

(Note, I am only one vote among many but I’m confident this is the majority view!)