Saturday 13 June 2015

Lucee (/CFML?): approach Lucee language decisions "properly"

G'day:
I'm having a PHP day today... testing PHP 7 alpha. This has lead me to be reviewing some of the RFCs (well: just one) for PHP 7 to clarify some behaviour I'm seeing.

For language features, PHP has docs like this: "PHP RFC: Exceptions in the engine".

I'm thinking about this situation particularly in the context of Lucee: Adobe's a waste of time when it comes to community participation in language decisions (eg: <cfclient>, which was roundly and without exception derided by the community when it was floated as an idea,  but still: there it is).



[NB: I'm shifting this from a forum post to a blog article. Sorry if I don't catch all the bits that need rewording to reflect the changed context].

For Lucee (like Railo before it), we will seem to have a poorly-attended thread on the Language Forum (I cannot believe how little attention that forum gets: it's the one interesting forum when it comes to Lucee!), then Micha does what he feels like. I'm sure there's more to it than that behind the scenes, but I don't think there's much more than that going on. From the way some tickets have been "resolved", I really don't think there's much more going into this process than "the whim of the developer", if I'm to be brutally honest.

Now. A lot of what has gone into Railo in the past has been very good. But some of it has been questionable (where the results of the questions has been mixed: some positive, some... less so). This extends into Lucee.

I think with CFML, "it is where it is", and despite my suggestion for a standard ("CFML: time for a CFML specification?", falling foul of Betteridge's Law of headlines, ultimately), that ship has sailed.

But what about the alternative "dialect", with the .lucee extension? I'll show my hand and say I think it's not a good use of anyone's time, and LAS should focus on CFML and be done with it.

But at the same time I'll be supportive of it if it's done properly (so far: not being done properly). And with a view to "doing things properly", I can't help but wonder whether "half-hearted discussion then Micha does what he feels like" is not a recipe for success.

It LAS is going to make a thing out of "the Lucee dialect" two things need to happen.

Give it a name

"Lucee" is a crap name. People are still asking how to pronounce it, and it's one character different from the well-industry-established "Lucene", so it looks like a typo. No product should be named via Micha watching a movie and then making marketing decisions based on... Scarlett Johansson. It's slightly creepy, if nothing else. It's too late to change the name of the overall project, Association, and platform. However I don't see why the new language needs to share the name of the platform. The platform is dual-purpose: it serves CFML and it serves this new thing too. So there doesn't need to be direct link between [project, association, platform] and language.

It's a language, not a dialect

Basically: piss or get off the pot. In it's current state, .lucee is a waste of time. No-one benefits from CFML spelt differently, and that's all it is. If LAS want to write a new language - even if derived from CFML - then actually do that. I think "releasing" a first revision which is solely renaming "<cf" to "<:" is just daft. It brings along with it all the rubbish that we all wish CFML never had.

It might be a place to start from, but the problem is that Lucee 5's CFML offering is very well advanced, and probably getting close to release. Whereas its .lucee offering is "embryonic" at best. Yet as soon as they release Lucee (platform) 5.0, then .lucee goes out in the wild, and that sign-posts it as "ready for use". I doubt it will happen (which is telling in itself), but what if someone does decide to use it? The problem with this is that all the rubbish LAS might want to cull from the language is now in the wild, and they have all the usual backwards compat issues one has when updating an existing language.

I think LAS need to withdraw .lucee from its Lucee 5 offering, and put it in the incubator.

Then do it properly. From the outset. Base it on CFML, sure. But have proper conversations with the community, decide what to keep and what to dump from CFML. Listen to all the really good suggestions coming through, but put them through a proper consultation process like PHP's RFCs. There's been really good suggestions from Ryan and Jesse (and here) recently,  and I think I've come up with an idea or two too. However a forum conversation is only good to throw around an idea casually in the first instance. If something's going to be taken-up, then there needs to be a more formal discussion process, a concerted effort to nut-out syntax, and then have a vote as to whether to go forward with it (or elements of it, etc).

Basically... the entire approach to this .lucee thing has been... erm... "poorly realised" so far (IMO, as with everything on this blog), and now is precisely the time for this to be addressed. Before it goes out the door. Don't let it get out the door, yet.

--
Adam