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?
Sounds like an awesome YouTube video showing off the why we love luccee!On Saturday, June 6, 2015 at 4:27:56 AM UTC-5, 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?
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.On Saturday, 6 June 2015 10:27:56 UTC+1, Robert Munn wrote:
–
Adam
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_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?
–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@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.
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?
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.> On Jun 6, 2015, at 12:45 PM, Konstantinos Liakos <@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.
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.
–
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+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ea776ff1-4171-406c-a920-97fad6c5eaa2%40googlegroups.com https://groups.google.com/d/msgid/lucee/ea776ff1-4171-406c-a920-97fad6c5eaa2%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.
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!
~BradOn Sunday, June 7, 2015 at 12:49:57 AM UTC-7, Konstantinos Liakos 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.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?
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.> On Jun 7, 2015, at 12:49 AM, Konstantinos Liakos <@Konstantinos_Liakos> 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+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2cd13ebd-5b50-4714-bcd9-a4e2db2e6b94%40googlegroups.com https://groups.google.com/d/msgid/lucee/2cd13ebd-5b50-4714-bcd9-a4e2db2e6b94%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.
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.
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.
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: ariamediaOn Wed, Jun 10, 2015 at 2:18 PM, Nando Breiter <@Nando_Breiter> wrote:
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:
The programming talent myth [LWN.net]
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTubeAria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Wed, Jun 10, 2015 at 12:43 PM, Adam Cameron <@Adam_Cameron> wrote:
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–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com?utm_medium=email&utm_source=footer
.For more options, visit https://groups.google.com/d/optout.
Well said Nando, totally agree.On Wednesday, 10 June 2015 17:34:01 UTC+3, Nando Breiter wrote:
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: ariamediaOn Wed, Jun 10, 2015 at 2:18 PM, Nando Breiter <na...@aria-media.com <javascript:>> wrote:
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:
The programming talent myth [LWN.net]
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTubeAria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Wed, Jun 10, 2015 at 12:43 PM, Adam Cameron <camero...@gmail.com <javascript:>> wrote:
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–
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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com
<javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com?utm_medium=email&utm_source=footer
.For more options, visit https://groups.google.com/d/optout.
Hi Robert, your dream kinda look like Groovy, Scala, Clojure, JRuby and so
on…On Tuesday, June 9, 2015 at 8:02:19 PM UTC+2, Robert Munn wrote:
On Jun 7, 2015, at 12:49 AM, Konstantinos Liakos <liakosko...@gmail.com <javascript:>> 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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/2cd13ebd-5b50-4714-bcd9-a4e2db2e6b94%40googlegroups.com
https://groups.google.com/d/msgid/lucee/2cd13ebd-5b50-4714-bcd9-a4e2db2e6b94%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
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)?On Wednesday, 10 June 2015 13:43:41 UTC+3, Adam Cameron wrote:
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
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.> On Jun 10, 2015, at 4:22 AM, Konstantinos Liakos <@Konstantinos_Liakos> wrote:
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)?
On Wednesday, 10 June 2015 13:43:41 UTC+3, Adam Cameron wrote:
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–
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+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/c18cc036-124d-468a-be15-092ae01734a2%40googlegroups.com https://groups.google.com/d/msgid/lucee/c18cc036-124d-468a-be15-092ae01734a2%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.
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.On Wednesday, 10 June 2015 11:10:56 UTC+1, Konstantinos Liakos wrote:
–
Adam
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.
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.> On Jun 10, 2015, at 5:18 AM, Nando Breiter <@Nando_Breiter> wrote:
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:
The programming talent myth [LWN.net] https://lwn.net/Articles/641779/
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTube https://www.youtube.com/watch?v=hIJdFxYlEKEAria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Wed, Jun 10, 2015 at 12:43 PM, Adam Cameron <@Adam_Cameron mailto:Adam_Cameron> wrote:
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–
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+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com?utm_medium=email&utm_source=footer.For more options, visit https://groups.google.com/d/optout 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+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D_HsqjitCGvgYy%2BJ-C0NJkX6UEJux8vHnahTX3pjm1hbg%40mail.gmail.com https://groups.google.com/d/msgid/lucee/CAGHrs%3D_HsqjitCGvgYy%2BJ-C0NJkX6UEJux8vHnahTX3pjm1hbg%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.
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/
Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland
+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Wed, Jun 10, 2015 at 12:43 PM, Adam Cameron <@Adam_Cameron> wrote:
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–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/5430fd0f-b83d-43b7-8249-946100eb8ad3%40googlegroups.com?utm_medium=email&utm_source=footer
.For more options, visit https://groups.google.com/d/optout.
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.On Wednesday, June 10, 2015 at 2:38:47 PM UTC-5, Robert Munn wrote:
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.
On Jun 10, 2015, at 4:22 AM, Konstantinos Liakos <liakosko...@gmail.com <javascript:>> wrote:
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)?On Wednesday, 10 June 2015 13:43:41 UTC+3, Adam Cameron wrote:
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–
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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/c18cc036-124d-468a-be15-092ae01734a2%40googlegroups.com
https://groups.google.com/d/msgid/lucee/c18cc036-124d-468a-be15-092ae01734a2%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.