I initially wrote this on the Lucee Google Group, but it probably better belongs here. There has been discussion about the number of CFML devs (and by extension, Railo/Lucee devs), and what can be done to reach out to more people, and basically what tactics could be employed to turn more developers onto Lucee. Be those converts from the existing CFML base, or enticing new developers.
The whole thread is worth a read, btw. Even if you don't give a rat's arse about Lucee.
This is another one of those "CFML is dead/in decline/in maintenance mode/irrelevant" observations by the way. Feel free to disagree. Obviously it's why I write these things ;-)
Context:
Hi Robert, your dream kinda look like Groovy, Scala, Clojure, JRuby and so on...
I was gonna say the exact same thing. It seem that too many dev teams are trying to reinvent the wheel again. But what the hell, if it wasn't for many languages, there wasn't gonna be any competition. At least this way everybody is trying hard to evolve the language and make it better.And my response:
Well it's easy for us as individual devs to just go "screw this, I'm gonna go do [Groovy / Scala /Clojure / JRuby] instead". Any personal limitations we might have notwithstanding... it's possible.
But that's not a prospect for Lucee and for all intents and purposes not an option for LAS either. So they need to come up with a USP that will sustain assertions of "yeah, but why would I not just start with [Groovy / Scala /Clojure / JRuby] instead". TBH, I think they are shit out of luck there, and there simply isn't a USP to be had for CFML. And even less one for .lucee, which the more I think about it, the more it seems like "not a good use of anyone's time... LAS's or the Lucee community's.
Sitting here in 2015, I cannot think of a single reason to start using CFML. For the likes of MSO.Net / Pixl8 [ed: major supporters of Lucee, and dedicated CFML shops], I'd guess they continue with CFML because they've already got CFML resources, and switching to a "better" language has a cost & risk associated with it. So if one is already embedded in CFML, it's perceived as adequate enough to not take the risk to move into something more "contemporary". This and the language knowledge the decision makers have is firmly "CFML", so it's probably wouldn't know the best option to migrate to from CFML anyhow. I reckon this - and change aversion or just outright laziness - is pretty much why CFML devs (as opposed to dev shops) stick with it too. It's not because it's specifically good, it's because it's good enough.
But good enough isn't good enough for a new dev, with all the [Groovy / Scala /Clojure / JRuby] options in front of them as well for them to pick up CFML.
Seen in this light, I dunno what the USP for Lucee could ever be other than to position it as an alternative for CFML shops/devs who question mark the price tag on ColdFusion, and want a free option (or an open source option, but I think the most appealing thing about Lucee is the £££, not the libre). With a sideline of it being quicker (although I'm less sure about this being much of a consideration when compared to CF11... my more recent tests have been inconclusive there), and certainly more responsive to support issues.
It's a puzzling one.
Outside the context of Lucee and its "challenges" (and let's face it... if they actually want to increase their relevancy, they have a "challenge" ahead of them), this applies equally to ColdFusion.
I'd say almost all the new CFML devs out there will be graduate devs who have little to no real experience, and are more after a development job of any description, and not particularly married to a given solution, nor already have negative preconceptions of CFML. I know a couple of CFML dev shops that don't look to hire CFML devs - they're too scarce, and really a lot of them aren't any good anyhow - they just hire devs who are prepared to learn CFML. This often works, but I also think ppl are likely to be treating that role as a stepping stone to get some field experience, but leave to do better things once they have a bit of experience on their CV, but before they get "typecast" as a CFML developer. That's my instinct, anyhow.
Can anyone think of real reasons that might make CFML a compelling option for someone who is not already a CFML dev? Would you actually recommend CFML to anyone for a new project, if they were asking for professional advice?
Hmmm.
--
Adam
