The (Missing) Lucee Language spec

[justincarter]

@agentK

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.

I’d say it’s in it’s infancy if there’s no spec and one old alpha There is a lot of work for LAS to do and, like @modius said, the spec is just one of those things that needs to be worked on.

@modius

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

Perhaps this is some of the clarification that people were after

[agentK]

@modius

@agentK

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

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!)

LAS has clearly failed to communicate this.

I know you’re one vote, but who’s the LAS voice on this? We’re running in circles here, but who makes the decision what’s being communicated and how?

[agentK]

@adam_cameron

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.

Anyone? @micstriit @modius ?

[agentK]

@modius

@agentK

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…

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.

It’s relevant because you brought up the contributions via pull request in the previous message and I said that’s impossible for the purpose we’re discussing.

[modius]

@agentK

It’s relevant because you brought up the contributions via pull request in the previous message and I said that’s impossible for the purpose we’re discussing.

I was referring to peoples ability to contribute overall, not specifically to the Lucee Language feature.

You could of course submit pull requests to assist in the overall Lucee Language feature once the way forward is clear. I don’t think its realistic to assume that every member of the community can be involved in every part of the decision making process.

We are trying to be as inclusive as we can be, and to make sure the best people are involved at the right time. Clearly we won’t get this right all the time. Neither of us were involved in the initial formation of the Lucee Language concept. I certainly wish both of us had been.

Nevertheless, I am certainly a big supporter of the feature and i think it holds great promise. I’m working hard to make sure we get it mostly right

[dom_watson]

I have raised a new topic to gather ideas and opinions around improving the language spec/evolvement process: http://lang.lucee.org/t/input-gathering-formalizing-process-of-lucee-language-evolvment/141

If you have ideas & opinions on concrete ways in which Lucee enhancements can/should be formalized, please bring them there.

[thefalken]

@modius

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.

Actually, Apache say “community over code”. I might have a good idea, even though I lack the resource or specific knowledge to implement it.

[apenhorwood]

Here is an interesting read on the Apache Way http://theapacheway.com/
Not suggesting that Lucee needs to follow their led but some of these processes are well defined and functioning in other organizations.

[jasbar]

It also says

Those that have proven they can do, get to do.

[modius]

@thefalken

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.

Actually, Apache say “community over code”. I might have a good idea, even though I lack the resource or specific knowledge to implement it.

It’s a noble sentiment that LAS whole heartedly endorses.

But even the Apache Foundation needs funding. Someone at the Apache Foundation needs to decide what idea is a good idea and what ideas are not. And only those who can write code, can commit code.

I don’t think what i said is very far from the Apache Way, so i’ll repeat it in case anyone missed it:

@modius

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

[modius]

@kliakos

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?

The goal is to have a language that can evolve independently from the glacial pace of Adobe’s CFML implementation. If we don’t create a separate dialect on the server, we have the nightmare of trying to support two different implementations in the one language.

The Lucee Language has to start somewhere; the best CFML implementation that the existing server can offer today without a massive engineering effort.

[kliakos]

Completely agree that it has to start somewhere. If it is in beta and you can safely remove functionality unitl stable v1, then it’s fine. But if it is released as v1 now, with all the UI tags for example, then it’s going to be hard to remove them later.

[dom_watson]

But if it is released as v1 now, with all the UI tags for example, then it’s going to be hard to remove them later.

Agreed. I’m personally all for slowing the release of Lucee Lang v1. Concentrate on getting Lucee 5 out of the door without the language extension while we can take the time to specify what’s there now and properly organise a structured consultation period, mission statement, etc.

[kliakos]

Follow the node’s example: Have the Lucee lang in beta for as long as you feel comfortable that no more major changes must be applied. This way you can deprecate and remove stuff every once in a while with each new version(of course warnings must be in place long time before such things happen), but you don’t have the commitment to not break backwards compatibility.

Many will say: and which major company will adopt a lang that is in beta? Well, why did they do it with node?

[agentK]

@dom_watson

But if it is released as v1 now, with all the UI tags for example, then it’s going to be hard to remove them later.

Agreed. I’m personally all for slowing the release of Lucee Lang v1. Concentrate on getting Lucee 5 out of the door without the language extension while we can take the time to specify what’s there now and properly organise a structured consultation period, mission statement, etc.

This is probably the best statement I’ve heard in the whole discussion so far.

[adam_cameron]

@agentK

@dom_watson

But if it is released as v1 now, with all the UI tags for example, then it’s going to be hard to remove them later.

Agreed. I’m personally all for slowing the release of Lucee Lang v1. Concentrate on getting Lucee 5 out of the door without the language extension while we can take the time to specify what’s there now and properly organise a structured consultation period, mission statement, etc.

This is probably the best statement I’ve heard in the whole discussion so far.

Seconded.

–
Adam