number of CFML developers?

833 views
Skip to first unread message

Robert Munn

unread,
Jun 6, 2015, 5:27:56 AM6/6/15
to lu...@googlegroups.com
Speaking of these issues with Lucee and CFML, editors, etc., does anyone have any market intelligence on roughly how many day to day CFML developers there are out there?




Mark Drew

unread,
Jun 6, 2015, 5:48:45 AM6/6/15
to lu...@googlegroups.com
This is a very hard number to gather as there is a vast silent majority of developers that just do it as their job and have no involvement in the community.

Mark Drew
- Sent by typing with my thumbs.

> On 6 Jun 2015, at 10:27, Robert Munn <robert...@gmail.com> wrote:
>
> Speaking of these issues with Lucee and CFML, editors, etc., does anyone have any market intelligence on roughly how many day to day CFML developers there are out there?
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Lucee" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
> To post to this group, send email to lu...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/E1EA7D28-FB61-436D-8EB4-C1C0E421A90A%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Adam Cameron

unread,
Jun 6, 2015, 5:58:25 AM6/6/15
to lu...@googlegroups.com


On Saturday, 6 June 2015 10:27:56 UTC+1, Robert Munn wrote:
Speaking of these issues with Lucee and CFML, editors, etc., does anyone have any market intelligence on roughly how many day to day CFML developers there are out there?


It's 37. 38 if you count that bloke still doing OpenBD.

So... ah, I guess it's 37 then.

-- 
Adam 

Konstantinos Liakos

unread,
Jun 6, 2015, 6:32:10 AM6/6/15
to lu...@googlegroups.com
Hah, devs doing CFML aren't actually very proud for it. They prefer to keep it for themselves and their company...

And who blames them?

Mark Drew

unread,
Jun 6, 2015, 6:41:42 AM6/6/15
to lu...@googlegroups.com
Not that at all. There are lots of developers about there that just do it as a job. I have been in many companies where there is like one developer that is into the community and language etc, the rest just do their job 9-5 and that is the end of that. 



Mark Drew
- Sent by typing with my thumbs. 

Konstantinos Liakos

unread,
Jun 6, 2015, 6:47:11 AM6/6/15
to lu...@googlegroups.com
The analogy between 9-5 devs and my-life-is-coding devs is pretty much the same for all languages. So taking into account tha share CFML has among devs, the number of active community CFML devs should be really low, like not more than 100. But maybe it's just me being over pessimist.

Adam Cameron

unread,
Jun 6, 2015, 6:47:41 AM6/6/15
to lu...@googlegroups.com


On Saturday, 6 June 2015 11:32:10 UTC+1, Konstantinos Liakos wrote:
Hah, devs doing CFML aren't actually very proud for it. They prefer to keep it for themselves and their company...

And who blames them?

I don't think it's that. It's just that Macromedia and Adobe never really knew what to do with ColdFusion back at the time that it could have mattered, and so they never got it onto sufficient people's radars for it to be taken up in a serious way. That and the web industry took off very quickly, and the CFML language was very very slow to evolve. Most CFML that people outside the community will see still looks like it was written for the web (and the industry's approach to same) of the 1990s and early 2000s. This is not going to be at all appealing to anyone who's used to looking at more matured and sophisticated language solutions. And - yes - I know there's a cue here for [someone] to get all uppity about the validity of tag-based code. But to head that one off, tag-based code is absolutely fine in the right place. But not as a starting point for learning the language. Tag-based code should also be taught. But in the section of the syllabus dedicated to outputting results; not acquiring what to output. The V in MVC.

Just this week I saw new CFML-teaching course material that will simply deliver a negative message as to CFML's place in this decade as all the code was still based around tags. This is is the wrong approach to teaching the language to new potentials these days.

Anyway, CFML's & its marketing's & evolution's failures aside, what I mean is that when it mattered - a decade ago - there was very very little uptake of CFML compared to other similar candidates, so we are now left with a comparatively small community amongst the PHPs, Rubys, Pythons of this world. All communities have a small proportion of outward-facing, participatory membership like our folk here, and a much larger underbelly of people who don't poke their heads above the parapet at all. It's just that the numbers for the other communities are order(s) of magnitude bigger than the CFML one. I doubt the level or active and visible participation in the CFML community is proportionately less than in other communities, there's just a lot fewer of us in general.

-- 
Adam





Robert Munn

unread,
Jun 6, 2015, 2:04:00 PM6/6/15
to lu...@googlegroups.com
The people who just do their jobs are the target market for an editor. The active users are influencers who can help create mindshare with everyone else. The active users and their managers are the people who need to be convinced to go to Lucee. Small businesses wanting a better web presence need to be convinced to deploy ContentBox or Mura instead of Wordpress. 

There is a company a few miles from me building apps on ACF. They have known about Railo but have stuck with ACF for now. The entire team is a target for an editor, as are many other teams that do not show up on the radar of the community.

As for being active through blogging, etc., if you are doing standard CFML there is very little that hasn’t been covered before. Maybe it is worth going through and doing an intro to Lucee/CFScript series, for instance, but a lot of the code is the same as it was ten years ago. This is exactly the opposite of the NodeJS world where there seems to be so much energy around it in part because so many people are just learning how to use it. 

The exception to this rule is in stuff happening outside of the core of the language and runtime - MuraCMS, ColdBox, ContentBox, LogBox, FW/1, caching, search systems, cloud deployments, automation, etc. CommandBox, for my money, is probably the most interesting thing to happen in the CFML world since the introduction of Railo, and it is only just out of the gate. I’ve been working with ColdBox for a couple of years now and there is still a ton of stuff in it that I have yet to use.

From that perspective, I think it is a very interesting time to be in this space. 

In terms of competing with other languages, let’s go back to the 10x (3x) rule. The product has to be 3x better to win. NodeJS is winning right now because it has a low memory footprint and high throughput. When you look at the stories of big companies moving to NodeJS, they cite cost savings via 70% or better reduction in hardware to run a Node application v. a Java or other application as a major reason for switching technologies. For a small site that’s no big deal, but for a company like LinkedIn, eBay, or Netflix, those are big numbers that significantly affect the bottom line. 

So, you want to see Lucee being adopted widely? Performance, performance, performance. Make the speed competitive with NodeJS and Lucee will succeed.




Brad Wood

unread,
Jun 6, 2015, 2:41:14 PM6/6/15
to lu...@googlegroups.com
> Tag-based code should also be taught. But in the section of the syllabus dedicated to outputting results; not acquiring what to output. The V in MVC.

Totally agree, Adam.

-------------

Regarding a user metric-- the only attempt I've ever seen made was in the Adobe evangelist kit they used to put out.  In 2009, they estimated the number of CF devs at 778,000 per the "EDC 2008 Global Developer Population and Demographics Report".  This evangelism kit has since been removed from their site, but you can view a copy I found here: http://www.eduardo.net/PDF/cfkit_en.pdf
Obviously that number is quite old, but Adobe quit putting out that kit quite some time ago.  I'm curious if the "Global Developer Population and Demographics Report" is still around and includes ColdFusion.

http://www.code2014.com/ was a survey completley based on the input of the develpeprs who chose to participate, but it ranked CFML 28th out of 101 languages reported.  Of course, that doesn't give you numbers, but it shows you relative community sizes.  It's on par with Groovy, Perl, Lisp, and Lua.

Thanks!

~Brad

Andrew Dixon

unread,
Jun 6, 2015, 3:31:13 PM6/6/15
to lu...@googlegroups.com
CommandBox, for my money, is probably the most interesting thing to happen in the CFML world since the introduction of Railo

Agree 100% for you on that Robert, we really need to push CommandBox. I showed a hardcore PHP guy I know CommandBox and how I could just create an empty directory, enter the directory and type "box" and then "start" at the box prompt and bang... new site up and running... type "touch index.cfm" and then "edit index.cfm" and bang, my default CFML editor opens with the file... enter some save, save and refresh the browser window and I have a CFML site running... he was blown away... then when I added the stuff about package management and the like I almost had him ready to convert!!!

Kind regards,

Andrew

Mark Drew

unread,
Jun 6, 2015, 3:38:08 PM6/6/15
to lu...@googlegroups.com
+100


Mark Drew
- Sent by typing with my thumbs. 

Konstantinos Liakos

unread,
Jun 6, 2015, 3:45:28 PM6/6/15
to lu...@googlegroups.com
On Saturday, 6 June 2015 21:04:00 UTC+3, Robert Munn wrote:
So, you want to see Lucee being adopted widely? Performance, performance, performance. Make the speed competitive with NodeJS and Lucee will succeed.

Lucee to match the speed of NodeJS just can't happen. And CFML is not about raw speed, it's about ease of development. In order to have this, you trade off speed.

I really can't think of a game changing feature that will make devs and companies come to Lucee/CFML. As Adam stated, thay ship sailed ten years ago.

Can you find any major public API that has published a CFML SDK? This thing alone is a huge minues for CFML.

Adam Cameron

unread,
Jun 6, 2015, 4:27:35 PM6/6/15
to lu...@googlegroups.com


On Saturday, 6 June 2015 20:45:28 UTC+1, Konstantinos Liakos wrote:
On Saturday, 6 June 2015 21:04:00 UTC+3, Robert Munn wrote:
So, you want to see Lucee being adopted widely? Performance, performance, performance. Make the speed competitive with NodeJS and Lucee will succeed.

Lucee to match the speed of NodeJS just can't happen. And CFML is not about raw speed, it's about ease of development. In order to have this, you trade off speed.


It's not about speed. Lucee isn't in the running as far as code execution speed goes, so I think as long as one does the "due diligence" level of attention to speed: job done. Focusing on performance is also gonna be impacted by the law of diminishing returns very quickly: it won't be a good use of people's time looking at it.

Ruby is as slow as a dog, yet it's still really popular. Why? I think it's two things: RoR revolutionised the simplification of building MVC web apps. Also the language itself is reasonably well thought out, is consistent, is extensible, and one can do quite a lot with just its native API. People like programming in Ruby. Will it scale to deal with sites the size of Twitter? No. Is that sort of scaling really something most people have to deal with? No. It doesn't matter.

Another thing that gets the word out there is... people talking about it. How many people here have written blog articles about Lucee (or CFML, or... well... anything?). If not blogs, who chatters about Lucee on Twitter? Reddit? I don't even know how Reddit works, but my understanding is a helluva lot of other people do. Can you do conference presentations? Go present on Lucee at a non CFML-friendly conference (ie: don't just preach to the choir). The best way to make people be aware of something is to tell them about it. It's not a "build it and they will come" scenario. That won't work.

I think Lucee (and CFML in general), is completely adequate enough as a language to get more uptake. Provided some decent stuff - FW/1, ColdBox, CommandBox, TestBox, etc - can be demonstrated to actually be pretty good. From a non-framework POV... who's sharing their work in public? "I did this interesting thing..."; "I solved this common web app challenge using CFML..." etc. Even if you can't be arsed doing the work yourself (this makes you part of the problem, btw), then at least take up the role of circulating the word.

Lucee can be the fastest thing on the market, but if no-one knows about it? No-one is going to give a shit.

-- 
Adam



Andrew Dixon

unread,
Jun 6, 2015, 5:05:24 PM6/6/15
to lu...@googlegroups.com
Yep, Xero, very popular accounting package have a CFML SDK and this is relatively new:


but they are probably an exception... I'm assuming one of their customers paid for it...

Kind regards,

Andrew

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Andrew Dixon

unread,
Jun 6, 2015, 5:07:39 PM6/6/15
to lu...@googlegroups.com
As Adam stated, thay ship sailed ten years ago.

Clearly not, NodeJS didn't exist 10 years ago... Initial release May 27, 2009 (http://en.wikipedia.org/wiki/Node.js)

Kind regards,

Andrew

On 6 June 2015 at 20:45, Konstantinos Liakos <liakosko...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Konstantinos Liakos

unread,
Jun 6, 2015, 5:15:45 PM6/6/15
to lu...@googlegroups.com

I meant that Coldfusion lost it's chance for getting a wider audience ten years ago, which would help the language evolve faster.

Will Lucee convince devs and companies that it's not old news? We'll see, I really hope for it.

NodeJS came out and in a couple of years outperformed java in request throughput. Does Lucee have such a killer feature to catch everyones attention?

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/0uQmQPOTYpA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

Adam Cameron

unread,
Jun 6, 2015, 5:18:38 PM6/6/15
to lu...@googlegroups.com
On Saturday, 6 June 2015 20:45:28 UTC+1, Konstantinos Liakos wrote:
As Adam stated, thay ship sailed ten years ago.


On Saturday, 6 June 2015 22:07:39 UTC+1, Andrew Dixon wrote:

Clearly not, NodeJS didn't exist 10 years ago... Initial release May 27, 2009 (http://en.wikipedia.org/wiki/Node.js)

That is not the context that either Konstantinos or myself were making that comment.

But then again... I have a strong suspicion you are fully aware of that, Andrew.

-- 
Adam

Andrew Dixon

unread,
Jun 6, 2015, 5:25:28 PM6/6/15
to lu...@googlegroups.com
:-)

Kind regards,

Andrew

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

thorste...@googlemail.com

unread,
Jun 6, 2015, 5:42:07 PM6/6/15
to lu...@googlegroups.com
What's the USP of coldfusion?
What's the USP of lucee?
What would you say in an elevator pitch?

spills

unread,
Jun 6, 2015, 7:11:18 PM6/6/15
to lu...@googlegroups.com
Sounds like an awesome YouTube video showing off the why we love luccee!

Robert Munn

unread,
Jun 6, 2015, 11:29:53 PM6/6/15
to lu...@googlegroups.com
Lucee doesn’t need to match the speed of NodeJS, but it should be as competitive as possible. JVM tuning is a skill that has been underemphasized in the space. Lucee developers might also share some thoughts on the most efficient constructs in the language, e.g. loops v. forEach, etc. In terms of the Lucee engine, the team has done a good job on performance and they should continue on that course.

Raw speed being a tradeoff for ease of use? JavaScript isn’t so much more difficult to deal with than CFML. 

CF developers can use Java SDKs, I’ve never thought having a specific CFML SDK was a big deal.

NodeJS dislodged established technologies by being better in measurable ways. Not saying that it will happen, just saying that it can happen. More importantly, if there really are ~800K CFML developers, there is a big enough market to support tools and some level of adoption of Lucee. 





--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Konstantinos Liakos

unread,
Jun 7, 2015, 3:49:57 AM6/7/15
to lu...@googlegroups.com
Robert,
 
Lucee doesn’t need to match the speed of NodeJS, but it should be as competitive as possible. JVM tuning is a skill that has been underemphasized in the space. Lucee developers might also share some thoughts on the most efficient constructs in the language, e.g. loops v. forEach, etc. In terms of the Lucee engine, the team has done a good job on performance and they should continue on that course.

Have you seen what CFML code compiles to? You can't get any decent speed from that Java code. Still I trade off the speed to not having to declare any of my variables and to have optional function arguments. That's the story.

CF developers can use Java SDKs, I’ve never thought having a specific CFML SDK was a big deal.

You stiil need to have some Java knowledge to instantiate objects from Java SDK. Not saying it's difficult, but it's not something everybody is comfortable with.

More importantly, if there really are ~800K CFML developers, there is a big enough market to support tools and some level of adoption of Lucee. 

How did you get this number? 

Brad Wood

unread,
Jun 8, 2015, 7:08:46 PM6/8/15
to lu...@googlegroups.com
Konstantinos, that number came from an old ColdFusion evangelism kit from Adobe.  I linked to it earlier in the thread.

For what it's worth, I pinged Evans Data (who makes the Global Developer Population and Demographics Report) and asked them if they still track CFML.  Their response today was this:

"We actually stopped asking about CFML four years ago."

Thanks!

~Brad

Jesse Shaffer

unread,
Jun 9, 2015, 8:40:59 AM6/9/15
to lu...@googlegroups.com
Is it possible to get stats from LinkedIn as to the number of people that have CFML (or related) skills listed? It won't give you the number of active devs, but it gives you a target number of devs who may be interested (or persuaded) to give some of the new features in lucee and related editors a look, especially in 5.

Terry Whitney

unread,
Jun 9, 2015, 9:51:35 AM6/9/15
to lu...@googlegroups.com
I always get a kick out of people trying to compare a language to another language by what they think adoption rate is of a language.


Here are some oldie, but highly sought after skills, ADA, Fortran, Cobol

Granted these are not usually taught in any normal school, they are still used and highly sought after in the right markets. You wouldn't find much of a peep about any of them online, even though some of the biggest of the fortune 100's, governments and infrastructure for countries rely upon these every day.


I can easily say there are over 30K people employed writing code in these languages, yet you do not see a Comdex style welcome for the skill. 

There are other languages that easily fall into the same place, and ColdFusion is one of those languages.   

If you want to blame who has failed at marketing it, its Adobe.  They have been half heatedly kicking the can down the road with their enterprise level application.  They failed at marketing 101, which is what is the need. What is the appeal, why does everyone have to have it.  Instead of marketing as such, they have marketed to us technical folks,when the real target audience is the consumer. 

As for ColdFusion needing this or that, what it needs is marketing. Its not feature X,Y,Z that draws people to a language, its marketing, marketing & marketing.

While there are plenty of others who have been great at drawing in the geek crowd, the practicality has been, CF is not seen as a problem solver for business.  That is what needs to change. Instead of applications than can only be written by a team of programmers spanning months to years to create, it needs to be sold as, you can do it, good bad or indifferent  here is the frame work to build your dream.  

You create the idea that a child, a banker, and a stay at home mom all can create the application of their dream, solve a problem with their office, it will feed into itself.  









Robert Munn

unread,
Jun 9, 2015, 2:02:19 PM6/9/15
to lu...@googlegroups.com
On Jun 7, 2015, at 12:49 AM, Konstantinos Liakos <liakosko...@gmail.com> wrote:

Robert,
 
Lucee doesn’t need to match the speed of NodeJS, but it should be as competitive as possible. JVM tuning is a skill that has been underemphasized in the space. Lucee developers might also share some thoughts on the most efficient constructs in the language, e.g. loops v. forEach, etc. In terms of the Lucee engine, the team has done a good job on performance and they should continue on that course.

Have you seen what CFML code compiles to? You can't get any decent speed from that Java code. Still I trade off the speed to not having to declare any of my variables and to have optional function arguments. That's the story.

That’s why I was saying Lucee developers might chime in with thoughts on what the most efficient code style is to produce the best possible code in the current engine.

Improving performance by a significant margin would require that Lucee produce Java code that is fundamentally different from what it produces today. It would be a major engineering effort. Could it be done? Yes, it could be done. It would involve re-thinking the Lucee engine from the ground up, and that would require significant time and money. 

I’m not suggesting it is going to happen tomorrow, or next year, what I am saying is that if LAS finds itself in the position of having significant funding for such an effort, it would change the landscape for Lucee and for Lucee/CFML developers, and for every organization that runs a CFML app. All it takes is an app or set of apps with enough traffic to make the case that improving the speed of Lucee by 2x, 3x, 5x, etc. would pay for itself through savings in computing power, which translates into savings in raw materials, manufacturing, transportation, electricity, etc. So Lucee needs a big enough sponsor who has a stake in that outcome, or enough smaller sponsors who in aggregate could provide the funding.

Maybe that’s a big dream, but the big dreams are the best dreams. My dream is that I could write a Lucee application and under the covers the Lucee engine would produce an optimized Java application. That dream is worth a lot of money to the right group of people who have the vision to understand the consequences of such an improvement. I would also suggest that re-writing the engine is far less expensive than re-writing all of the installed Lucee/CFML apps in another language.



CF developers can use Java SDKs, I’ve never thought having a specific CFML SDK was a big deal.

You stiil need to have some Java knowledge to instantiate objects from Java SDK. Not saying it's difficult, but it's not something everybody is comfortable with.


Of course. Often you’ll see someone in the community write a CFML-based wrapper for the biggest Java SDKs, but that’s not a task everyone will undertake.


More importantly, if there really are ~800K CFML developers, there is a big enough market to support tools and some level of adoption of Lucee. 

How did you get this number? 

As Brad said, that’s an oldish number, which is why I wonder if there are that many people. 



--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Desmond Miles

unread,
Jun 10, 2015, 5:35:27 AM6/10/15
to lu...@googlegroups.com
Hi Robert, your dream kinda look like Groovy, Scala, Clojure, JRuby and so on...

Konstantinos Liakos

unread,
Jun 10, 2015, 6:10:56 AM6/10/15
to lu...@googlegroups.com
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.

Adam Cameron

unread,
Jun 10, 2015, 6:43:41 AM6/10/15
to lu...@googlegroups.com


On Wednesday, 10 June 2015 11:10:56 UTC+1, Konstantinos Liakos wrote:
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.

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, 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.

-- 
Adam

Konstantinos Liakos

unread,
Jun 10, 2015, 7:22:35 AM6/10/15
to lu...@googlegroups.com
Well Adam, you are probably right, and this is kind of disappointing to admit. If Lucee/CFML devsc doesn't attract any new devs, then it is a matter of time that the existing ones will get old or switch to another language and there will be nobody to use Lucee/CMFL anymore.

How on earth can we change this? Or better, should we change this, or is it for the best of all of us(switching to a widely used language)?

Nando Breiter

unread,
Jun 10, 2015, 8:18:50 AM6/10/15
to lu...@googlegroups.com
There is no mystery here regarding a USP for Lucee. In fact, there are several:

  • CFML is and remains a simple language to use and learn. You can start with a few simple tags, and you're off.
  • There are many, many legacy apps written in CFML that continue to need an app server to run on. With Adobe's obvious lack of tangible support for ACF, the the poor quality of recent releases, Lucee is the go-to option for the future.
  • There are many developers who know CFML, and stick with it. Perhaps a lot of that comes down to developer limitations, and whether or not you judge these limitations as bad, the fact remains that for a lot of us, CFML is the language we develop in because that's the language we know best. But look at World Singles, for instance, with Sean Corfield as the lead developer. He's probably one of the most accomplished developers you'd find, proficient in C++, Java, Scala, Groovy, Clojure and CFML. They continue to use CFML for their view layer, last I heard. Part of that is for legacy reasons, I'm sure. But part of it is also because the templating engines they looked at available to use with Clojure wouldn't be as easy to use. They may change that in the future, but this accomplished team made a choice to stay with CFML.
  • It's open source and free to use, and the developers are very responsive to bug reports.
Now, there are those that will argue that the fact that CFML is easy to learn and use is not a good thing. This only leads budding developers to write shitty code, and ruins the possibility that they will become a "real" developer. I don't buy that. The recent ACF 11 release proves that developers can know a more complex language like Java and still write shitty code. The fact that my iPhone became unusable yesterday because a dialog kept popping up every second asking for my FaceTime password, no matter how I responded, proves that even a very well financed team of crack developers still write shitty code on occasion. I wanted the throw the damn thing through a brick wall!

The actual story is much more complex and nuanced than the generalizations we create in our minds to label things. Just because we have the tendency to generalize when we don't precisely understand, and have created negative labels associated with "CFML dev", doesn't mean that Lucee doesn't have a unique selling point. I'd simply say the labels and generalizations are inaccurate.

I'm a very ordinary programmer. But even as an ordinary programmer, I've never delivered anything near as bad as the initial release of ACF 11 in terms of broken fundamental functionality, and I've never locked users out with a circular dialog box that kept popping up. Maybe it's because CFML is too simple, and my skills too ordinary, to fuck things up that badly. Or maybe it is just because I care. People can still care about their craft even with an ordinary skill set. 

References:









Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Nando Breiter

unread,
Jun 10, 2015, 10:34:01 AM6/10/15
to lu...@googlegroups.com
By the way, I'm not implying that developers should remain content with a very limited skill set and not learn anything new. Far from it. But I am saying that the vast majority of developers cannot manage to keep up with the cutting edge of the multiple technologies one can use to write and maintain a web application these days. Either we can't learn fast enough, or we don't have the time to invest because of other commitments or interests or whatever. There's nothing wrong with that. You find the same in any profession or endeavor. 

And maybe the pressure to be extraordinary holds some of us back from learning, because we all then don't expose what we don't know openly. I don't have to be an "extraordinary" developer to deliver a functional, useful, well designed web application to my clients. I certainly need to keep learning things, day after day, and I need to really care about what I produce. But I find the pressure to be constantly on the cutting edge somewhat harmful in that it is unrealistic. CFML remains a very good fit for a wide swath of developers who would like to be productive without needing to master complex programming topics. It's a language one can grow a skill set with. And I find Lucee's approach to be particularly useful in this direction, more than ACF's, because Lucee is taking the lead in introducing more advanced programming concepts to the language. 







Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

Konstantinos Liakos

unread,
Jun 10, 2015, 10:42:17 AM6/10/15
to lu...@googlegroups.com
Well said Nando, totally agree. 

Robert Munn

unread,
Jun 10, 2015, 3:38:47 PM6/10/15
to lu...@googlegroups.com
Even if there are no new developers or projects written in CFML, ACF is old enough that there is a very large installed base of CFML applications. My proposition is that, if a big enough chunk of the people running those applications committed to migrating to Lucee, improving the speed of the product would pay for itself many times over. So who benefits?

- CFML developers

Anyone with the skill set who wants to continue building apps in CFML should want the product to be as good as possible so their skill set is valuable.

- Organizations running CFML apps

Let’s say you have a hosting service that hosts CFML apps on 1,000 nodes of your cloud. Imagine being able to cut that to 200 nodes. Interesting? How could it not be. Depending on the cost of electricity, each node in the cloud costs somewhere in the range of $500-$1,000 per year to run. That’s hundreds of thousands of dollars per year saved by improving the performance of the engine. Honestly I don’t know why the big cloud companies are not pounding on the doors of the application server organizations demanding these kinds of improvements, because there is real money at stake.

- Everyone else

Reducing the hardware footprint of a large set of applications equals big savings in electricity, which is a very positive move, and benefits everyone.


If no one else picks up this ball and runs with it, maybe I will.





--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Robert Munn

unread,
Jun 10, 2015, 3:50:48 PM6/10/15
to lu...@googlegroups.com
There is a very significant value proposition in Lucee over let’s say a generic NodeJS installation. Lucee has a built-in Web-based admin system that takes care of a vast array of settings and configuration options for your application. It also has a very large set of functionality that is targeted at the things Web developers do:

- connect to databases
- authenticate against external systems (LDAP, etc )
- cache data in caching systems
- manage state

And to top it all off, because it runs on the JVM, it has access to the entire world of Java-based libraries on the Interwebs.

Basically everything on that list in Node is accomplished through Node packages. Yes, there are frameworks in the Node ecosystem that package things together, but there is still nothing as complete and mature as what Lucee packages natively. 

There are projects like OpenStack that are geared around easy provisioning of services, but their version of easy is not nearly as easy as setting up and running a Lucee system, even a cluster of Lucee systems, although the cluster space could benefit from more work.

When you work in the CFML world all the time, it’s easy to take for granted how simple things are. Not just coding, but installing servers, deploying apps, and monitoring deployments.




Mike Henson

unread,
Jun 11, 2015, 11:05:39 AM6/11/15
to lu...@googlegroups.com
Part of the problem with migration is the incompatibilities that exist between Lucee and ACF. Some of these incompatibilities seem to be intentional, and sometimes when they are noticed Lucee devs just say, "Yep, but our way is better." The incompatibilities make migration more difficult than it should be, and that holds people back. If migration was simple, we would likely see more people make the transition.

Igal @ Lucee.org

unread,
Jun 11, 2015, 11:10:12 AM6/11/15
to lu...@googlegroups.com
Mike,

can you tell us about the issues that you are aware of?  at the very least we can put them on one document in the wiki for the benefit of future users.

Igal Sapir
Lucee Core Developer
Lucee.org

Andrew Penhorwood

unread,
Jun 11, 2015, 12:14:38 PM6/11/15
to lu...@googlegroups.com
I have heard this a number of times but I have no idea what incompatibilities they are talking about that aren't already documented.  If you are using client side stuff in your CF code then there are better ways of handling that.  Things like cfinput, cfselect, etc. I found using JQuery better suited.  For PDF stuff I jumped shipped from cfducment after the first go around.  Flying Saucer handles PDF stuff better.

Andrew Penhorwood

Nando Breiter

unread,
Jun 11, 2015, 12:22:49 PM6/11/15
to lu...@googlegroups.com
Igal,

Not practically very helpful, but just to say, I've tripped across issues in odd corners, and it's my impression that over the entire range of what is possible to code successfully in ACF, there might be many of them. 

From memory, I've run into trouble repeatedly with blocks of code that use group with cfoutput, something like the below:

<cfoutput query="rc.qLocationSchedule" group="month">
<cfoutput group="week">
<cfoutput group="startDate">
<cfoutput>

I've seen ordering not what I'd expect, grouping messed up, and no display at all, compared to ACF. I've read that Micha thinks poorly of this construct, and I can understand his reasoning. 

Another odd one I've run into is query of querys forcing a datatype to decimal when the type on the database column is varchar. The problem was that the decimal was a unique identifier, like a product number, and 43.3 because equal to 43.30 and 43.300. I had to work around the issue by introducing an extra column that eliminated the decimal and added, I think, a character to the front so that I could make unique comparisons again. 

A main compatibility issue for me is PDF generation / layouts. I understand Lucee uses a different library from ACF, so there isn't much to do about that. 

There's certainly more I've run into and don't remember off the top of my head ... in the past, I've tended to run through working around compatibility issues quickly to get it working.





Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Igal @ Lucee.org

unread,
Jun 11, 2015, 12:39:23 PM6/11/15
to lu...@googlegroups.com
I am not arguing that there are some discrepancies, which are IMO minor and affect very few users.

I just think that if we can maintain a wiki page with the known issues then it would make migration easier -- which is my primary goal here. 
so each known incompatibility can explain briefly the issue, possibly with the reason behind not "fixing" it, and a recommended solution.


Igal Sapir
Lucee Core Developer
Lucee.org

Julian Halliwell

unread,
Jun 11, 2015, 12:39:28 PM6/11/15