I think @seancorfield makes a very valid point about a “mission statement” for Lucee as a whole; its the age old CFML community discussion about being more Java like (structured/rigid) or more HTML like (loose/dirty?).
Lucee is a CFML engine. I believe Lucee Language should be an effort to embrace and improve CFML, not construct a new language.
I can’t help feeling that much of the “conflict” in these discussions centres around the desire to move away from the “quick’n’dirty” nature of CFML toward something different; more ordered, more structured, more opinionated.
Those of us opposed to this view are not anti-“best practice”. We are generally anti-“lack of choice”. We genuinely like working with CFML, we just want it to be better. We need to take a flame-thrower to much of the cruft in CFML, but we can’t walk away from the very nature of CFML.
For example, are you saying here that Ruby is also quick/dirty; ie. not the direction we should be taking? Does Ruby not enshrine a set of “best practices to appeal to a broader range of developers (i.e., outside the CFML pool)”?
I’m not saying that view is wrong – I just wonder whether or not we see the same vision for CFML at all.
Perhaps collectively we need to discuss and reaffirm what we want CFML to be, as there seems to be a relatively large divide of opinion on this fundamental vision. Perhaps then, we could frame and resolve many of these language discussions in the context of that vision.
What is the very spirit of what we are trying to achieve?
I agree that Sean made a very good point there, but I believe that the best solution, like most things in life, is balance. in some cases it makes sense to enhance a tag and in others it might not.
“include-template” is an execution flow tag. so is “exit-template”. so these are not completely detached concepts. but would I suggest to add “exit-template” in other tags? probably not.
sure, it wouldn’t be a “perfect” solution in the sense of purity, but isn’t Sean’s favorite quote is “perfection is the enemy of the good”?
Ruby is designed for programmer convenience, rather than any particular notions of enforced “best practices”. Ruby allows you to do pretty much anything and it often provides half a dozen (or more) ways to do the same thing. It’s a particular design philosophy.
Python, by contrast, provides fewer ways to do things, emphasizing instead the “Pythonic Way”, and it even enshrines its best practices in a number of official PEP documents:
I think it would help frame some of the discussions here – and inform some of the decisions – if LAS were to provide the philosophical guidance that these fundamental language styles derive from.
My understanding of the direction of Lucee lang is;
Cut the things that are bad form (some functions, UI tags, etc)
Improve things to provide clarity and performance (some functions, e.g. createObject)
Consolidate past syntax implementations/options (tags in script)
Enforce “strict” compiler options to avoid some CFML pitfalls and enhance performance
Allow Lucee code to run in more places (embedded scripting, CLI, etc)
Reduce the engine footprint by making it more modular/configurable (although, this already applies to CFML not just Lucee lang)
So on the philosophy of where we are headed, I think these points – some of which may have concrete implementations, some which may not – may shed some light. It’s more of a face lift than a complete change of direction. It’s an effort to have a nicer, faster, easy language to work with. It’s possible neither “quick and dirty” nor “strict, best practise” but somewhere in between with features that appeal to both ends of the spectrum
I think we’re probably mostly in agreement with this to some extent, I suspect there is not yet consensus – and LAS can help us all by providing some scope around how much “cutting” there should be (more below).
We may disagree on the specifics but these are good guiding principles.
Neither of those are really language issues, they’re engine issues. But I agree that they are good goals for Lucee as a whole.
The first point is probably the biggest point of contention. For example, there was a fair bit of discussion amongst the “Iris” folks about whether to drop all the _typename_Something() functions in favor of only supporting the typeObj.something() member functions (myArr.len() over arrayLen(myArr)). Given the vast number of array-this, struct-that, query-whatever and, oh dear, image-blah built-in functions that would be a huge cleanup (and I’d be strongly in favor of such a move). But would it be considered “too far from CFML” to be reasonable for Lucee? Would it be within @modius’s “flame-thrower” scope?
Is it a goal that CFML code could be migrated to Lucee? Right now that probably wouldn’t be too onerous assuming perhaps, a mechanical edit of <cf to <: and </cf to </: and a few other things, but should that even be a goal? Is it enough to be able to run .cfc and .cfm files alongside .lucee files? That should be more a philosophical decision than a practical code-based one…
Personally, I don’t see a necessity for that all at because the whole point is that anyone can run their traditional CFML code. I’d rather have a (maybe not completely) clean slate and getting rid of all the typenameSomething functions would be something I’d expect in LuceeLang.
Even a semi-radical cut like that could easily be migrated using some code that does an intelligent parsing of templates and replaces them with member functions being exectuted depending on in which position in the parameter list the “object” to act one is for a certain function.
My gut reaction would be member functions everywhere; arrayLen() et al can die in a fire. But I’d want to understand some of the reasoning others might have to retain the old functions. What was the outcome of Iris deliberations in this regard? (It’s not immediately apparent to me in the Iris outcomes spreadsheet.)
No, it’s certainly not clear. Two of us said “no” to the built-in functions completely (but “yes” to the member function versions). The rest said “yes” to the functions overall but mostly agreed with turning them into member functions (instead of built-in). What’s not clear from the sanitized version of the spreadsheet, is what the consensus of the group was – which was that we should have member function versions where they make sense (it’s tricky with the list and file operations). However, even from where I sit, I can’t tell – and I can no longer remember – whether the consensus was to remove the built-in functions, leaving only the member functions.
You could also say, the Lucee dialect is a different aproach to all the settings you have in the admin today.
Best example for me is the admin setting for “full null support”, i never could use that myself until today, because when i enable it, it always breaks someting in the application (mostly it breaks “structkeyExists”).
But the Lucee dialect will allow me to make use of it, without breaking my existing code.
Mostly you do not start on a green field for a new application, so you will use for example FW/1, coldbox whatever, so the lucee dialect allows you to do that, use CFML code in your Lucee dialect application.
I will disagree with you and say that this ain’t enough. I have written several microservice apps from scratch last year and enabled all the advanced options you mention. Indeed full null support is awesome, so is strict scope mode. But these features aren’t exciting anymore, at least to me since I use them for a long time now. Throw in some efficient async tasks, that’s something new.
I would personally think that Lucee 5
would be fine to ship with what is there for the new dialect as is, as
long as it is marked experimental. Tomcat does this with new features all
the time. Something to start playing with, but not recommended for
production use. Maybe it could be the dialect is an extension that has to
be installed for now? Idk.
There is so much good in Lucee 5’s CFML updates by itself that all this
dialect discussion is holding it up way too much IMO.
