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.

--
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/c18cc036-124d-468a-be15-092ae01734a2%40googlegroups.com.

[Robert Munn]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D_HsqjitCGvgYy%2BJ-C0NJkX6UEJux8vHnahTX3pjm1hbg%40mail.gmail.com.

[Mike Henson]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/5579A4B3.5090506%40lucee.org.

[Igal @ Lucee.org]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D_P8wPnEcrgFxKep1fNLywGgUBvD%2BcE%2BEVftzpu47nC0Q%40mail.gmail.com.

[Julian Halliwell]

I blogged many of the issues I encountered migrating from ACF9 to
Railo (which I did just before it became Lucee).

http://cfsimplicity.com/tags/83/railo

ORM was a significantly troublesome area (and still is frankly thanks
to bugs that were introduced just prior to the fork).

I did my best to make sure everything was logged in the various issue trackers.

On 11 June 2015 at 16:09, Igal @ Lucee.org <ig...@lucee.org> wrote:
> 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.
>

[Brad Wood]

+1 This was a frustration of mine back when I first started with Railo.  There never really was a complete page of incompats.  The easiest way to find them though was simply to throw your code on and try it.  Over the years, I've either submitted patches for the issues I found or entered tickets (some of which I need to port over to the Lucee JIRA) and simply made notes of others.  The only one that consistently seems to get me is the inability to treat a query column as an array directly.  I think that was always an undocumented "feature" of Adobe CF though and of course, Lucee has dedicated functions to do it.  The sucky thing about that though is that many Adobe CF to Lucee conversions have a period in between where the code need to run on both platforms.  The only other real thorn in my side is the differences in script queryies/procs.  I'd happily help update a wiki page though with all the things I've run into (not that it's really that large of a list...)

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
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/5579B99B.9070606%40lucee.org.

[Igal @ Lucee.org]

I started a document with the first issue that I bumped into back in the day

everyone who has something useful to say on the subject, please update that page:
https://bitbucket.org/lucee/lucee/wiki/Migrate%20from%20ACF

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CALbQ1o%3DVp5dkbbwijGw3ahomZUFpdNPpBd8RgXLBa4HY7ha9Yg%40mail.gmail.com.

[Mike Henson]

Sorry, I don't have any examples right now.

--
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/CAC_5VoqEWWa6wEAhMmxFdj9EkEJO0V3086op-GYgE80Ca7WP%3Dw%40mail.gmail.com.

[Robert Munn]

If I could make a suggestion, how about using this page to list known compatibility issues and include links to references such as Julian’s blog posts grouped by issue? That would create the best possible coverage, and cross-linking to blogs, etc. will help to drive search engine rankings and make it easier for people to google for known compatibility issues and get to the right place.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/5579C39B.80209%40lucee.org.

[Steven Durette]

How about this one. The CFScript version of cfstoredproc. Write code to run on Railo but had to make it ACF compatible so I had to change all my beautiful CFScript to tags. 

Sent from my iPhone

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/CAPOeHjr9%2Bw0VDcpd2wLGZJYA-zOpCszTm3_c8MEkCSs6kzxYcA%40mail.gmail.com.

[Igal @ Lucee.org]

that sounds like a different matter to me -- if you want ACF to be compatible with Lucee then you should ask the good people at Adobe.  good luck with that ;)

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/FB7B9652-EE02-4D63-87CD-A3AFD6CAF105%40gmail.com.

[Brad Wood]

Actually, I believe the issue is that Lucee doesn't have CFC wrapper for stored proc like Adobe does.  It was skipped in favor of a (different) dedicated stored proc script syntax.  What's interesting is that Lucee does have cfc wrapper for query though.  I've always wondered by query.cfc was made but storedproc.cfc wasn't.

See the Adobe reference here on the syntax that Lucee doesn't support:

http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSe9cbe5cf462523a0693d5dae123bcd28f6d-7ffa.html

Here was a ticket for Railo to support it that remains unresolved:

https://issues.jboss.org/browse/RAILO-2033

Note, there was a shim someone created for Railo that I have successfully used for Lucee as well.

https://gist.github.com/bdw429s/3003ba56073d759b39aa

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/557A03DC.7090909%40lucee.org.

[Steven Durette]

In my case you might be right. However what about the person who wrote CFScript version of cfstoredproc on an ACF box and now wants to convert to LUCEE. There is an incompatibility for the list. That's what I was trying to point out. 

Wasn't there a CFML language group that was set up at one time that was supposed to prevent stuff like this?

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/557A03DC.7090909%40lucee.org.

[Mike Henson]

I don't use the 'client side stuff.' I generally don't even use the cfm extension. HTML and JavaScript on the client side, CFML server side. Like I said earlier, I don't have any ready examples. I made the migration from ACF to Railo a while back, and was an early adopter of Lucee. We still have quite a bit of legacy code running on ACF 8 (for internal use only), but I wouldn't expect a smooth transition from ACF 8 to anything current.

[Shawn Oden]

Come on, Adam. Everyone knows the proper answer is 42.

On Saturday, June 6, 2015 at 4:58:25 AM UTC-5, Adam Cameron wrote:

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 

[Shawn Oden]

I recently spoke with a senior developer about a completely unrelated position. He knew of ColdFusion, he saw it on my resume, and when he asked me about it, he asked me what my front-end developer skills were like "since CF is a front-end language". _THAT_ is the misperception that we are dealing with in this language. And unfortunately, Adobe isn't really doing much to help with that poor impression of what the language is really good at. Can it do it? Absolutely. And that's part of what makes it an interesting language in my opinion. I don't need 10 different dependencies to build a good application from front to back and connect to a pretty wide range of databases in almost no time at all. Now that doesn't mean that I _SHOULD_ be building an entire site in ColdFusion. But the fact that I can do it is sometimes helpful. 

Anyway, I still say the language needs to go back to focusing on its roots: making hard stuff easy. There are a bazillion ways to do any of the UI stuff, which several people on this board have already taken their time to demonstrate. We don't need any more CF_BUZZWORDs in this language that end up not getting used. 

[Adam Cameron]

On Saturday, 13 June 2015 00:23:20 UTC+1, Shawn Oden wrote:

Come on, Adam. Everyone knows the proper answer is 42.

No-one in their right mind would ever think CFML is the answer to life, the universe and everything ;-)

-- 

Adam 

[AJ Mercer]

Maybe if they installed CFML on Deep Thought it would not have taken seven and a half million years to calculated the answer

--

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/1d360826-6602-4cce-9aff-3a73a71c2085%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

AJ Mercer
<webonix:net strength="Industrial" /> | <webonix:org community="Open" />
http://twitter.com/webonix

[Adam Cameron]

On Saturday, 13 June 2015 13:15:34 UTC+1, AJ Mercer wrote:

Maybe if they installed CFML on Deep Thought it would not have taken seven and a half million years to calculated the answer

 True.

They'd get the request timeout after 60sec.

;-)

-- 

Adam

 

[Steven Durette]

Or in this case after 42 seconds...

Sent from my iPhone

--

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/629bbf72-0d52-49f7-bd46-fe3ce31e2377%40googlegroups.com.

[Phillip Senn]

@Steven:

The cfscript verson of stored procedures is so sweet in Lucee:

storedproc

procedure='OrderHeader.[get]' {

procparam value=form.OrderHeaderID;

procresult resultset=1 name='OrderHeader';

procresult resultset=2 name='Cust';

}

I'm singing the praises of using stored procedures in cfscript.

[Mehdi B]

I never embraced the UI component in CF, as I found them always too limited and requiring more code to work correctly while bringing too much dependencies. And if you check ACF11 from the main CF house Adobe and see the bloatware shipped over mobile, what we can do? or say?

I love CF since it did ALL what I wanted even if in the old times CF 4.5 or 5.0 crashes were a pain once you start to push it a little but the language, logic, syntax, simplicity was ahead of the time. Since macromedia take over we ve seen some improvements but few. Hopefully we got railo project, as it offered it offered an open source solution community driven. 

I got many dev's who abandonneed CF mainly as there is less demand for it and currently in my area you sell CF dev only in 2 cases:

1. maintenance for existing CF dev's ( and some time customers are preparing the shift for another plateforms as they feel abandonned and no more dev's).

2. You have a new project without language requirement hardcoded in the specs and the customer will look for result rather than the tools.

We can't ignore too that .net have evolved well and they finally understood that bloatware UI are not the solutions and offer more support for open standards or more clean MVC support. CF is more facing tought competition from .net rather than nodeJS, also CF didn't bank the JAVA roots to push more the big java community to embrace it.

[Phillip Senn]

OK, let me ask a stupid question but has been bugging me for a very long time:

If you wanted to do:

SELECT * FROM Table1

in one of these newer languages, how would you do it?

--
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/b70b736d-9586-4722-8cc3-0aa1c5e90311%40googlegroups.com.

[Adam Cameron]

On 16 June 2015 at 21:48, Phillip Senn <phill...@gmail.com> wrote:

OK, let me ask a stupid question but has been bugging me for a very long time:

I'd focus less on this question and put effort into working out how to use google.

-- 

Adam 

[Phillip Senn]

That's funny Adam. 

I guess that's why I've never bothered to post it as a question on stackoverflow.

Afraid of getting downvoted like so many of my questions do.

But I know the people in the cf community are a kinder, gentler people.

Seriously, how do you SELECT * FROM Table1 using any other web authoring programming language?

I looked at node.js for a little while but couldn't understand how to do the same thing that cfquery does.

And I don't think I want to jump from ColdFusion to php.

From the outside looking in, it looks like php is just another scripting language so why not stick with the one that I already know?

If anything, moving from cfquery to using stored procedures has moved most of my logic out of ColdFusion, so if I ever do decide to transition, there will certainly be less to do than there was a year ago.

--

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/CAOPrabUFrhPEuObz_%2B%2BQBBRe_bcWUuY1qX0WD27Xs4%2Bjc%2BVUrQ%40mail.gmail.com.

[Igal @ Lucee.org]

@Phillip --

I think it's a perfectly valid question. 

I'd be interested in seeing such comparison as well, but not interested to the point where I go research PHP/Ruby/Python/node.js -- on my priority list this item is #16,384 (I'm currently at item #32 so I might get there on my own some day).

Igal Sapir
Lucee Core Developer
Lucee.org

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/CANWT4JMUTi%3DvrdB99gzbTCXGnYvA9sgKz-DZyTyg45Mtim55qw%40mail.gmail.com.

[Mark Drew]

This is *one* node.js way of doing it: https://www.npmjs.com/package/node-mysql

User.Table.find(conn, 'select * from users', cb);

Mark Drew


develop • deploy • deliver
http://charliemikedelta.com

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/558190E5.9020104%40lucee.org.

[Mark Drew]

OR maybe a better example: 

https://www.npmjs.com/package/mysql

(being the main package it seems) 

var mysql      = require('mysql');

var connection = mysql.createConnection({

  host     : 'localhost',

  user     : 'me',

  password : 'secret'

});

 

connection.connect();

 

connection.query('SELECT 1 + 1 AS solution', function(err, rows, fields) {

  if (err) throw err;

 

  console.log('The solution is: ', rows[0].solution);

});

 

connection.end();

Mark Drew


develop • deploy • deliver
http://charliemikedelta.com

[Jon Clausen]

Phillip,

It’s still SELECT * FROM Table1, but in Coldfusion the datasource connection is configured at the server leve, and the methods are native. In NodeJS, for example, you need to add the library to connect to the specific database type. Example for MySQL:

npm install node-mysql

Then:

//You can always scope this part globally in your application, but this is the connection config.
var mysql      = require('mysql');
var db = mysql.createConnection({
  host     : 'localhost',
  user     : 'root',
  password : '',
  database : 'my_database'
});

db.connect();
db.query('SELECT * from Table1', function(err, rows, fields) {
  //if no error, do stuff with your query result rows
  if (!err){
    for(var i in rows){
        console.log(rows[i]);
    }
  } else {
    throw err;
  };
});
connection.end();

It’s a different approach. PHP is the same way, but the connectivity modules are installed explicitly when installing the PHP packages (In PHP 5.6+, on many Linux distress, they’ve stopped including MySQL by default). It’s one of the ways in which CFML is a more integrated and mature language, as database connectivity is assumed at the application server level.

Update: I saw Mark posted pretty much the same thing when I was typing this so apologies for some duplication. :)

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/CANWT4JMUTi%3DvrdB99gzbTCXGnYvA9sgKz-DZyTyg45Mtim55qw%40mail.gmail.com.

[Adam Cameron]

On Wednesday, 17 June 2015 16:18:11 UTC+1, Phillip Senn wrote:

That's funny Adam. 

I guess that's why I've never bothered to post it as a question on stackoverflow.

Afraid of getting downvoted like so many of my questions do.

But I know the people in the cf community are a kinder, gentler people.

It's reasonable advice, and I did test it before suggesting it. You made no indication of having tried to do anything to answer your own question before asking it, so I figured an answer with about as much effort was probably appropriate. Also as it's completely off-topic for this forum, I wanted to keep it short. And, yes, dismissive.

But here we are again.

I did not know the answer to your question, so I googled "python execute sql statement" (I picked Python at random: it was the first language to pop into my head), and all the matches pretty much gave the answer. Try it. This is the first match: http://www.tutorialspoint.com/python/python_database_access.htm

I'm now going to google "groovy execute sql statement". Again... the very first link explains it: http://docs.groovy-lang.org/latest/html/api/groovy/sql/Sql.html

How about Go? "golang execute sql statement". The first link is the API. At the top of that there's a link to here: https://github.com/golang/go/wiki/SQLInterface. Examples.

Ruby? Second link goes to a stackOverflow question entitled "How do you manually execute SQL commands in Ruby On ...", and the marked answer has an example. It's specific to a DB vendor, but you get the idea. And bear in mind I stopped at the second answer... there might be a better answer further down the page.

[etc]

So you're interested in node.js. For the same search except for node.js the fourth match ("fourth" chosen arbitrarily) - https://www.npmjs.com/package/mssql - has example code.

So - you see - it's really not that hard to apply yourself for a few min to help yourself.

And you'll learn more from helping yourself than asking other people to spoonfeed you.

Does this give you enough to go on?

-- 

Adam

 

[Igal @ Lucee.org]

It’s still SELECT * FROM Table1

yes, we realize that ;) 

we're referring to the boilerplate code that is required in order to connect to the database, and possibly to iterate over the returned record set

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/etPan.5581933b.671bf557.54c6%40jonclausen-mbp.local.

[Jon Clausen]

I know, Igal…  ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/55819490.70100%40lucee.org.

[Mark Drew]

The problem here is that if you do some kind of self contained “how do I do SELECT * FROM BLA” it will look longer but a lot of these things are now handled by ORM’s or behind some kind of generator/service etc. 

In meteor you use mongodb, but there is a package to use mysql. IT might not be as concise as CFML but the fact that it has full stack reactivity (i.e. if something changes in the db, all the clients are told about it and without reloading, they update) with meteor that you can’t do with CFML (yet)  is a boon

For example Rails is not about doing SELECT * FROM People, it’s about doing (for example) Person.find() instead. 

Mark Drew


develop • deploy • deliver
http://charliemikedelta.com

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/55819490.70100%40lucee.org.

[Nando Breiter]

Phillip, 

I find Datomic very interesting as a database. It is fundamentally different than relational databases in that the base unit of data isn't a table row, but a datom, which is defined as a tuple of entity, attribute, value and transaction. Null values aren't stored - they simply don't exist. Datoms are not overwritten when values change. Instead the old value is "retracted" and the new value added. Thus you automatically have a complete history of all data modifications that have occurred. Datomic uses Datalog instead of SQL, so there is really something to sink your teeth into if you want to be confused for awhile! ;-)

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

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

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/etPan.558195ae.1f1f057c.54c6%40jonclausen-mbp.local.

[Mike Henson]

It really depends on the language, but for most of the ones I have worked with you create a sql connection object, add the sql statement, and execute. We can talk specifics to a language if you are interested in one that I am familiar with.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CANWT4JMUTi%3DvrdB99gzbTCXGnYvA9sgKz-DZyTyg45Mtim55qw%40mail.gmail.com.

[Phillip Senn]

Thanks everyone!

I didn't know about node-mysql, partly because I've been a 100% Microsoft SQL Server person, and partly because it might not have been around when I was investigating node.js awhile back.

I just keep thinking "What's everybody using if not ColdFusion? Is there something that a new person would be guided to the way that I was guided to Adobe ColdFusion 10+ years ago?"

But these answers have all been very helpful.

I think I'll stick with Lucee and try to build a true community. That's another thing that's been kicking around in my mind quite a bit.  You may have read some posts from me in the cfml craftsmanship group about a rating system. I've been writing the code with the thought of rating HTML, CSS, SQL Server, Lucee and JavaScript keywords.

I honestly think that I can make a contribution through writing a community driven rating system.

I hired a couple of interns but the first thing that I found was that they know 0% of even HTML. So I realized that they don't need to learn 100% of HTML - if I could show them the 20% that I use  80% of the time, then that's better than asking them to learn everything. So then apply that to every technology that they have to learn, and you've saved a tremendous amount of time getting someone up to speed (at least 80% up to speed).

So how do you define the top 20% of HTML? That's where the rating system comes in, but it's complicated enough to warrant it's own thread.

I call it "crowdsourcing education". It's the uber of education, baby!

(That last line was kind of an inside joke).

(Inside only to me)

(But I'm laughing).

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/etPan.5581933b.671bf557.54c6%40jonclausen-mbp.local.

[Judith Barnett]

SELECT from Table1 is SQL, not any of the other languages, and the
correct syntax is SELECT fieldname(s) from table1.

Doing this is any language requires setting up a database connection,
and passing information to it. The syntax varies but it is not
necessarily any harder to this in any language as it in CFML - which
requires a datasource and a query.

i write in a lot of languages and my methodology for doing queries is
pretty much the same. Define the connection, build the query string,
pass the query string to the database and handle the results.

Productivity increases greatly when the focus is on building and using
algorithms and functions correctly instead of on syntax. You can
always look up the syntax.

> 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/CANWT4JNUDftdH-mUQcw87atDfjxM%2B%2BxFc8cCRvLyT3F8oBSdQg%40mail.gmail.com.

[Phillip Senn]

By coincidence, I just got this from slant:

http://www.slant.co/topics/25/~what-is-the-best-programming-language-to-learn-first

So this raises another issue. Let's say we all want to promote CFML:

Q: Should I add CFML as an option at the bottom of the page, or should I add Adobe ColdFusion or Lucee?

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CACtg%3DU%2BdO%2BjrPG1ohNJMVXo7ECE%2BAkuf5BF5TG_6rPU0%3D_3V3g%40mail.gmail.com.

[Judith Barnett]

CFML is the language. I would use that.

[Adam Cameron]

You beat me to it.

ColdFusion and Lucee are... app server products? Platforms?

But whatever one wants to call those two things, the language is CFML.

-- 

Adam

[Phillip Senn]

OK, I added CFML to the list.

http://www.slant.co/topics/25/viewpoints/36/~what-is-the-best-programming-language-to-learn-first~cfml

I put http://lucee.org/ as the "get it here" link and then added http://www.adobe.com/products/coldfusion-enterprise.html as a separate source.

I'm not sure how popular Slant is.

Is it worth creating an account in order to vote? Meh.

--
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/CACtg%3DULahFhe%2B12Ob-TPH-LwK9SEsx3ptun3OX7bR5qfutBUnw%40mail.gmail.com.

[alexande...@xogito.com]

Hi guys, how can i get access to that document?

On Thursday, June 11, 2015 at 8:22:03 PM UTC+3, Igal wrote:

I started a document with the first issue that I bumped into back in the day

everyone who has something useful to say on the subject, please update that page:
https://bitbucket.org/lucee/lucee/wiki/Migrate%20from%20ACF

Igal Sapir
Lucee Core Developer
Lucee.org

On 6/11/2015 9:52 AM, Brad Wood wrote:

+1 This was a frustration of mine back when I first started with Railo.  There never really was a complete page of incompats.  The easiest way to find them though was simply to throw your code on and try it.  Over the years, I've either submitted patches for the issues I found or entered tickets (some of which I need to port over to the Lucee JIRA) and simply made notes of others.  The only one that consistently seems to get me is the inability to treat a query column as an array directly.  I think that was always an undocumented "feature" of Adobe CF though and of course, Lucee has dedicated functions to do it.  The sucky thing about that though is that many Adobe CF to Lucee conversions have a period in between where the code need to run on both platforms.  The only other real thorn in my side is the differences in script queryies/procs.  I'd happily help update a wiki page though with all the things I've run into (not that it's really that large of a list...)

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

On Thu, Jun 11, 2015 at 9:38 AM, Igal @ Lucee.org <ig...@lucee.org> wrote:

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

On 6/11/2015 9:22 AM, Nando Breiter wrote:

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

On Thu, Jun 11, 2015 at 5:09 PM, Igal @ Lucee.org <ig...@lucee.org> wrote:

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

On 6/11/2015 8:05 AM, Mike Henson wrote:

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.

--
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/5579A4B3.5090506%40lucee.org.

For more options, visit https://groups.google.com/d/optout.

--
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/CAGHrs%3D_P8wPnEcrgFxKep1fNLywGgUBvD%2BcE%2BEVftzpu47nC0Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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/5579B99B.9070606%40lucee.org.

For more options, visit https://groups.google.com/d/optout.

--
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/CALbQ1o%3DVp5dkbbwijGw3ahomZUFpdNPpBd8RgXLBa4HY7ha9Yg%40mail.gmail.com.

[Brad Wood]

I assume this is the new link.  Note it's editable via pull request so please update it with anything you think is missing.

http://docs.lucee.org/guides/updating-lucee/migrate-from-acf.html

Thanks!

~Brad