number of CFML developers?

[Robert Munn]

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]

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]

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]

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]

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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/7cb9432a-a37a-45e5-991c-81800e39367b%40googlegroups.com.

[Konstantinos Liakos]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/c8ff495b-b8b0-4627-b7e5-0f55c6db0ec7%40googlegroups.com.

[Brad Wood]

> 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]

> 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

about.me - mso - Lucee Association Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/C36DF467-1C3D-4637-8F85-6BC8FF16CAFC%40gmail.com.

[Mark Drew]

+100

Mark Drew

- Sent by typing with my thumbs. 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijV3U%2Bv7hZViLU5qXA2V3eWKvO29HR1igUu6BYjNsA3Pnw%40mail.gmail.com.

[Konstantinos Liakos]

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]

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]

Yep, Xero, very popular accounting package have a CFML SDK and this is relatively new:

http://developer.xero.com/code-samples/libraries/overview/

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

Kind regards,

Andrew

about.me - mso - Lucee Association Member

--

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/ea776ff1-4171-406c-a920-97fad6c5eaa2%40googlegroups.com.

[Andrew Dixon]

> 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

about.me - mso - Lucee Association Member

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ea776ff1-4171-406c-a920-97fad6c5eaa2%40googlegroups.com.

[Konstantinos Liakos]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijWPw%2BvDR0dAy1LZdYRqQbdDiy_qYfeJVsLHAXaDj5_0UQ%40mail.gmail.com.

[Adam Cameron]

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]

:-)

Kind regards,

Andrew

about.me - mso - Lucee Association Member

--

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/b50f5cb3-d957-48a9-a023-40251a861944%40googlegroups.com.

[thorste...@googlemail.com]

What's the USP of coldfusion?
What's the USP of lucee?
What would you say in an elevator pitch?

[spills]

Sounds like an awesome YouTube video showing off the why we love luccee!

[Robert Munn]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ea776ff1-4171-406c-a920-97fad6c5eaa2%40googlegroups.com.

[Konstantinos Liakos]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2cd13ebd-5b50-4714-bcd9-a4e2db2e6b94%40googlegroups.com.

[Desmond Miles]

Hi Robert, your dream kinda look like Groovy, Scala, Clojure, JRuby and so on...

[Konstantinos Liakos]

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]

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]

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]

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:

https://lwn.net/Articles/641779/

https://www.youtube.com/watch?v=hIJdFxYlEKE

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com.

[Nando Breiter]

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]

Well said Nando, totally agree. 

[Robert Munn]

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.