I'm reproducing this from a post I made on the Lucee Language Forum. I'm repeating it because... well... I wrote it so I can do with it what I like, plus it'll reach a more diverse audience here, I think. And people should feel free to say what they like in response here, unlike how things will be nannied on the Lucee forum.
What do you think? What's .lucee trying to do? Where's its niche? Does it have a niche?The approach to implementing/designing .lucee
Continuing the discussion from "Redux: Rename “component” to “class” in the Lucee dialect":
Dom Watson had said:
Support for using 'class' rather than 'component' seems to be pretty strong, the hiccup here is drawing a more far reaching proposal. Anyone, cough @adam_cameron cough, tenacious enough to flesh out the breadth of what should be changed and wrap it up in a proposal that we could move forward with?
Well here's the thing. I think LAS's entire approach to "planning" and building .lucee is back to front. The approach of starting with CFML, doing a rename, and then bolting stuff on, taking stuff out, changing stuff around is entirely (entirely) the wrong approach. What's been delivered so far is - I'm afraid - a waste of everyone's time: it's just CFML spelt differently. This is of no point or use to anyone, as its basis starts with all the things about CFML which are wrong, out-of-date, only partially realised, etc. With a bunch of stuff that's good, there's no denying that too. But no-one needs a "kinda CFML, kinda not, based on a language designed in the 1990s and shows it". Where's the market for that? Beyond being an outlet for the LAS dev squad's mores to "do their own thing".
Anecdotally, Java looked at C++ and identified an OK basis, but with a lot of hoary bits and set out to create a similar language which was a bit more approachable. C# came along later and did the same thing with Java. However they didn't start with the earlier language, open the hood and start pulling things out, chucking more stuff in, then standing back and declaring some sort of Heath-Robinson-esque mishmash to be what they set out to do. No. The designers actually... well... designed the new language. From the ground up. They allowed the good bits of the earlier language to influence their design decisions, but it was a purposeful ground-up design.
What I think you should be doing is going to the drawing board and wiping it clean. Acknowledge there's a body of good work in the internal libraries of the Lucee CFML implementation, but the language that stuff implemented isn't representative of the direction you think a modern "if we had our time again" language might take.
Revisit core concepts like:
- what sort of language it ought to be? Is the historically-organically-grown weirdo mishmash of procedural and OO really what you want to be perpetuating?
- would you want to strengthen the approach to OO that it has (discussions like "component" or "class")
- what about data types? We've been talking about structs a lot recently, but do they have so much place these days in an OO language, if objects are cheap and easy? Possibly not!
- should arrays start at one or zero (personally I'm undecided, but I err towards 1)
- lists? No.
- tags for everything? Or a much smaller subset of tags for using in views?
- etc
But plan the thing, plan it in a way that yer happy with, then implement it. Don't build the thing on a platform of sand and weird & poor Allaire/Macromedia/Adobe decisions. Make it your own thing.
Or... just don't bother. Do it properly, or not at all.
Right... back to watching Japan being very competitive against South Africa...
--
Adam
