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:
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.
What I signed-on to assist with was far more ambitious than where it ended up heading, for one reason or another.
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.
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.
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!)
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.
Perhaps this is some of the clarification that people were after
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
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.
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:
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.
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.
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.
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?