Breaking away from the stigma...?

[Peter_Boughton]

Splitting out of the “arguments against .lucee extension” thread,
because this is really a separate issue to that.

I don’t yet have an opinion on the new language/dialect/whatever stuff;
my views are mixed but not yet sufficiently formed to put into useful
words. Nothing here is against that, but merely challenging the
assumption…

Breaking away from the stigma and baggage of CFML is a valid concern

Is it really?

Every time I’ve seen anyone talk about the reasons for the stigma it
has been identified as from developers who are holding on to a view
from CF5 or CF6.0 - i.e. specifically ColdFusion, and yeah, there’s
also FUD about tags and internal derision aimed at people that stick to
what they know, but is any of this actually a valid concern?

I mean beyond the egos of people that find themselves saying “I use
Lucee, it’s CFML but better than ColdFusion, yes that ColdFusion but
it’s really better now, no that was ten years ago and Lucee is
different and I AM A REAL PROGRAMMER!!!”

To be clear, I’m not saying there isn’t a stigma at all, what I am
questioning is how much it’s tied to the term “CFML” and - more so -
whether it actually matters anyway.

If Lucee is aiming to grow its user base, the easiest target audience
is likely to be those that have not yet settled on a particular language
choice yet, (as opposed to trying to wow people away from what they are
already happy with using).

How many new developers are going to say: “oh look, this Lucee thing
looks easy and fun, but wait what’s this CFML thing, oh, it seems to be
an evolution of a language that a decade back lots of people hated, so
now I’m going to forget about Lucee despite all its positives”?

I don’t think most relevant people will care about the history, and I
doubt even those that might are going to reach that conclusion - not if
Lucee actually provides a reason to attract fresh blood, and for sure
not enough to make so much effort/fuss about distancing from CFML.

shrug

It’s late here and this all might just be tired ravings which are making
too much of a fuss about not making a fuss. It’s certainly longer than
originally intended/expected to be, but hopefully it holds at least
partially valid considerations or provokes some useful thinking.

[Jason_Morris]

One of the few things Microsoft did right was to rebrand ASP to ASP.NET
when they took ASP into the new millennia. I clearly remember the
excitement and anticipation of it coming amongst all devs, including non
ASP devs… Then more recently ASP.NET MVC.

If Macromedia did something similar when CF was rewritten on Java then
maybe CF’s recent history would have been quite different.

Maybe this is a chance for the CF community to learn from some marketing
pro’s.

CFM.NXT? CFM+? CFMVC? I don’t know, but something to say that it is the
NEXT GENERATION of a well known and well evolved platform may be a better
way to go than trying to start a brand and name from scratch…

I agree that Lucee can’t be just another Cold Fusion Engine… it needs to
take CFML into the modern era, but the brand and naming needs to reflect
just that… not reflect something that (in the eyes of an outsider) has
just popped up.

JasonOn Wednesday, 11 March 2015 12:28:39 UTC+11, Peter Boughton wrote:

Splitting out of the “arguments against .lucee extension” thread,
because this is really a separate issue to that.

I don’t yet have an opinion on the new language/dialect/whatever stuff;
my views are mixed but not yet sufficiently formed to put into useful
words. Nothing here is against that, but merely challenging the
assumption…

Breaking away from the stigma and baggage of CFML is a valid concern

Is it really?

Every time I’ve seen anyone talk about the reasons for the stigma it
has been identified as from developers who are holding on to a view
from CF5 or CF6.0 - i.e. specifically ColdFusion, and yeah, there’s
also FUD about tags and internal derision aimed at people that stick to
what they know, but is any of this actually a valid concern?

I mean beyond the egos of people that find themselves saying “I use
Lucee, it’s CFML but better than ColdFusion, yes that ColdFusion but
it’s really better now, no that was ten years ago and Lucee is
different and I AM A REAL PROGRAMMER!!!”

To be clear, I’m not saying there isn’t a stigma at all, what I am
questioning is how much it’s tied to the term “CFML” and - more so -
whether it actually matters anyway.

If Lucee is aiming to grow its user base, the easiest target audience
is likely to be those that have not yet settled on a particular language
choice yet, (as opposed to trying to wow people away from what they are
already happy with using).

How many new developers are going to say: “oh look, this Lucee thing
looks easy and fun, but wait what’s this CFML thing, oh, it seems to be
an evolution of a language that a decade back lots of people hated, so
now I’m going to forget about Lucee despite all its positives”?

I don’t think most relevant people will care about the history, and I
doubt even those that might are going to reach that conclusion - not if
Lucee actually provides a reason to attract fresh blood, and for sure
not enough to make so much effort/fuss about distancing from CFML.

shrug

It’s late here and this all might just be tired ravings which are making
too much of a fuss about not making a fuss. It’s certainly longer than
originally intended/expected to be, but hopefully it holds at least
partially valid considerations or provokes some useful thinking.

[Doug_Roberson]

I’m a new developer and here’s my two cents -

I don’t have a decade invested in this language - in fact, the first 18
years of my career were spent in QA at a .NET shop. Further, I generate
very little original code. I spend the bulk of my time maintaining and
fixing old code written by some poor village’s missing idiot. To be fair,
the JavaScript this guy left behind is far worse, but nothing he wrote was
clean.

When I left the .NET shop, the lead developer asked what I’d do at the new
job. I explained and he crinkled his face and asked me why I’d bother
learning ColdFusion. I told him what I’d been told, and what is the bottom
line reason - ColdFusion is productive. Whether you’re a new guy or you’ve
been using it since it was invented, ColdFusion is easy to learn and fast
to implement. My boss likes to point out that you’ll write 3.5 lines of PHP
(or more) for one line of ColdFusion. He didn’t agree or disagree, he just
shrugged and changed the subject.

I see a lot of that from code monkeys. There are a lot of snobs in the IT
business. They’ve each got a point to hang a hat on, why their language, or
languages, is the best, and they’re invested in their points. You’re not
getting them. Period.

Then there are a lot of guys who will use whatever languages they think are
best for the specific job they’re doing. These guys pick up and discard
languages as if they were underpants. These are the guys who, instead of
crinkling their faces, will ask you to give them an example. Another one of
my co-workers at the old job, who was all things Web, asked me to give him
an example of what I’d told the other co-worker. I showed him a table in
AFC, pulling from a table in MS SQL, using CFGRID - 25 lines of code, no
need for a library or CDN, just a fast, working page. He does consulting
outside his day job and now includes maintenance work on CF sites.

You can get guys like me and you can get guys like David. You can’t get
Thomas.

The way that ColdFusion gets new developers is by doing things faster and
easier than other languages. I went with Railo because I had friends who
needed help with websites and I couldn’t spend $1500 on an AFC license. I
was able to get a fast set up on Windows Server/IIS using Helicon Zoo. I
switched to Lucee when I found out about it.

In my opinion, Lucee can best grow its user base by continuing in the vein
of doing things faster and easier than other languages, by lowering the
barrier to entry, by adding more common features, including bringing over
more unsupported features from AFC. Dance with the girl that brought you.>

[dnando]

I think Peter has good point questioning the assumption that time and
energy should be expended in distancing Lucee from a ColdFusion stigma.
Where such a stigma exists, it will be in the minds of certain
individuals, and if it’s strong enough that an individual will not judge
the merits of Lucee on facts, on the language itself, then it’s going to be
a steep uphill battle to convince this individual that their bias is
incorrect. Changing the window dressing on the website won’t be sufficient,
by a long shot. Changing these minds would likely take months of skilled,
personal one to one interactions, with limited success.

Developers with a strong stigma against CFML are not within Lucee’s natural
target market. If Lucee was a startup, and in a sense it is, it would be
quite risky to focus a marketing effort, one with a very limited budget, on
people who would need the most convincing.

Programmers easily become engaged with difficult challenges, ignoring the
more simple path, the pedestrian, as boring. There can be a flat plain in
every direction to the horizon, easy to bike or hike or drive across,
except for one sheer cliff hundreds of meters high. Programmers will
congregate at the base of that cliff, especially those that do not know how
to scale it yet.

I think having really good documentation is far more important in terms of
the impression that Lucee makes on newcomers, on everyone in fact. Good
docs will draw folks in much more effectively than any anti-stigma
“strategy” we can come up with. It may not look like it, but to me, good
documentation is our real challenge.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Wed, Mar 11, 2015 at 2:28 AM, Peter Boughton <@Peter_Boughton> wrote:

Splitting out of the “arguments against .lucee extension” thread,
because this is really a separate issue to that.

I don’t yet have an opinion on the new language/dialect/whatever stuff;
my views are mixed but not yet sufficiently formed to put into useful
words. Nothing here is against that, but merely challenging the
assumption…

Breaking away from the stigma and baggage of CFML is a valid concern

Is it really?

Every time I’ve seen anyone talk about the reasons for the stigma it
has been identified as from developers who are holding on to a view
from CF5 or CF6.0 - i.e. specifically ColdFusion, and yeah, there’s
also FUD about tags and internal derision aimed at people that stick to
what they know, but is any of this actually a valid concern?

I mean beyond the egos of people that find themselves saying “I use
Lucee, it’s CFML but better than ColdFusion, yes that ColdFusion but
it’s really better now, no that was ten years ago and Lucee is
different and I AM A REAL PROGRAMMER!!!”

To be clear, I’m not saying there isn’t a stigma at all, what I am
questioning is how much it’s tied to the term “CFML” and - more so -
whether it actually matters anyway.

If Lucee is aiming to grow its user base, the easiest target audience
is likely to be those that have not yet settled on a particular language
choice yet, (as opposed to trying to wow people away from what they are
already happy with using).

How many new developers are going to say: “oh look, this Lucee thing
looks easy and fun, but wait what’s this CFML thing, oh, it seems to be
an evolution of a language that a decade back lots of people hated, so
now I’m going to forget about Lucee despite all its positives”?

I don’t think most relevant people will care about the history, and I
doubt even those that might are going to reach that conclusion - not if
Lucee actually provides a reason to attract fresh blood, and for sure
not enough to make so much effort/fuss about distancing from CFML.

shrug

It’s late here and this all might just be tired ravings which are making
too much of a fuss about not making a fuss. It’s certainly longer than
originally intended/expected to be, but hopefully it holds at least
partially valid considerations or provokes some useful thinking.

–
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/20150311012831.00001677%40sorcerersisle.com
.
For more options, visit https://groups.google.com/d/optout.

[Dominic_Watson]

This goes back to my earlier position that trying to automate the docs,
and base them from the metadata in the source code is a fool’s errand

Entirely automating them on meta-data from the source code may be wishful
thinking, but automating them from some structured data (especially the
reference material), is a must IMO, and perfectly achievable. I’ve been
playing with some ideas with Mark to improve this situation and make this
work. Docs should contain more than just the reference material, have cross
references and be exportable to multiple formats. They should also be easy
to contribute to. Hopefully we’ll have something that meets all these
requirements soon so that we can move on with that in one direction.On 11 March 2015 at 10:37, Adam Cameron <@Adam_Cameron1> wrote:

On Wednesday, 11 March 2015 10:27:52 UTC, Jeroen Knoef wrote:

I think having really good documentation is far more important in terms
of the impression that Lucee makes on newcomers, on everyone in fact. Good
docs will draw folks in much more effectively than any anti-stigma
“strategy” we can come up with. It may not look like it, but to me, good
documentation is our real challenge.

True…! And some code examples, like node.js’s on the homepage. Snippets
that make people say ‘hey this is nice, it does what I need in 3 lines. And
I can start in 5 minutes’.

Yeah. The function/method/tag signatures that Mark’s automated docs
provide are a key part of docs, but for docs to be useful, they also
need (in order of importance, IMO):

• explanatory narrative
• examples
• community feedback & notes

I think the signatures would fit into second spot on that list.

This goes back to my earlier position that trying to automate the docs,
and base them from the metadata in the source code is a fool’s errand. It’s
handy for an initial import into [a larger body of work], but is not really
that useful as a end unto itself.

For me, the Railo docs were never particularly useful, other than as
something to be served up from a URL to make it seem like Railo had docs.
If ever I needed to know how something in CFML worked, I needed to use the
Adobe docs. I guess the automated docs were useful to make clear where
Railo did / did not implement something which differed from ColdFusion. But
from there if one didn’t understand how the functionality worked, it really
relied on googling for stuff on blogs or Stack Overflow questions, and
Railo itself was very under represented there. Basically if whatever it was
one was looking at differed from ColdFusion, one was pretty much sunk,
short of asking a question on the mailing list.

–
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/74083180-f689-4832-b6d3-a065fde70c70%40googlegroups.com
https://groups.google.com/d/msgid/lucee/74083180-f689-4832-b6d3-a065fde70c70%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

[Jeroen_Knoef]

I think having really good documentation is far more important in terms of
the impression that Lucee makes on newcomers, on everyone in fact. Good
docs will draw folks in much more effectively than any anti-stigma
“strategy” we can come up with. It may not look like it, but to me, good
documentation is our real challenge.

True…! And some code examples, like node.js’s on the homepage. Snippets
that make people say ‘hey this is nice, it does what I need in 3 lines. And
I can start in 5 minutes’.

[andrew]

I would agree with this from a marketing point of view. A message like
“CFML for the modern web” or something like that would be good. It is very
true that most dev views of CFML is based on what CFML was a long time ago.
There are still those that do the same with MySQL, basing their views on
MySQL 3.x from 15 years ago and never having looked at it again since. It
certainly didn’t stop MySQL from ploughing forward, improving and letting
the product speak for itself.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - MemberOn 11 March 2015 at 07:24, Jason Morris <@Jason_Morris> wrote:

One of the few things Microsoft did right was to rebrand ASP to ASP.NET
when they took ASP into the new millennia. I clearly remember the
excitement and anticipation of it coming amongst all devs, including non
ASP devs… Then more recently ASP.NET MVC.

If Macromedia did something similar when CF was rewritten on Java then
maybe CF’s recent history would have been quite different.

Maybe this is a chance for the CF community to learn from some marketing
pro’s.

CFM.NXT? CFM+? CFMVC? I don’t know, but something to say that it is the
NEXT GENERATION of a well known and well evolved platform may be a better
way to go than trying to start a brand and name from scratch…

I agree that Lucee can’t be just another Cold Fusion Engine… it needs to
take CFML into the modern era, but the brand and naming needs to reflect
just that… not reflect something that (in the eyes of an outsider) has
just popped up.

Jason

On Wednesday, 11 March 2015 12:28:39 UTC+11, Peter Boughton wrote:

Splitting out of the “arguments against .lucee extension” thread,
because this is really a separate issue to that.

I don’t yet have an opinion on the new language/dialect/whatever stuff;
my views are mixed but not yet sufficiently formed to put into useful
words. Nothing here is against that, but merely challenging the
assumption…

Breaking away from the stigma and baggage of CFML is a valid concern

Is it really?

Every time I’ve seen anyone talk about the reasons for the stigma it
has been identified as from developers who are holding on to a view
from CF5 or CF6.0 - i.e. specifically ColdFusion, and yeah, there’s
also FUD about tags and internal derision aimed at people that stick to
what they know, but is any of this actually a valid concern?

I mean beyond the egos of people that find themselves saying “I use
Lucee, it’s CFML but better than ColdFusion, yes that ColdFusion but
it’s really better now, no that was ten years ago and Lucee is
different and I AM A REAL PROGRAMMER!!!”

To be clear, I’m not saying there isn’t a stigma at all, what I am
questioning is how much it’s tied to the term “CFML” and - more so -
whether it actually matters anyway.

If Lucee is aiming to grow its user base, the easiest target audience
is likely to be those that have not yet settled on a particular language
choice yet, (as opposed to trying to wow people away from what they are
already happy with using).

How many new developers are going to say: “oh look, this Lucee thing
looks easy and fun, but wait what’s this CFML thing, oh, it seems to be
an evolution of a language that a decade back lots of people hated, so
now I’m going to forget about Lucee despite all its positives”?

I don’t think most relevant people will care about the history, and I
doubt even those that might are going to reach that conclusion - not if
Lucee actually provides a reason to attract fresh blood, and for sure
not enough to make so much effort/fuss about distancing from CFML.

shrug

It’s late here and this all might just be tired ravings which are making
too much of a fuss about not making a fuss. It’s certainly longer than
originally intended/expected to be, but hopefully it holds at least
partially valid considerations or provokes some useful thinking.

–
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/7002f18e-259b-4d0c-ae8e-a4f5f664167c%40googlegroups.com
https://groups.google.com/d/msgid/lucee/7002f18e-259b-4d0c-ae8e-a4f5f664167c%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

[Terry_Whitney]

instead of running it as a CFML, why not just a tag inside the body of the
file.

Now a feature would be to have a superset of cfexecute so you could run
another executable engine inside the code and have an optional memory tag
to include or exclude runtime memory objects in the same code.

Example, you could run a PHP, script along side a CFML script inside the
same page.

( its pseudo code so relax)

<cfloop x+1 until x==0>

< cfextention-PHP mem=1>
echo “hello world”;

On Tuesday, March 10, 2015 at 9:28:39 PM UTC-4, Peter Boughton wrote:

Splitting out of the “arguments against .lucee extension” thread,
because this is really a separate issue to that.

I don’t yet have an opinion on the new language/dialect/whatever stuff;
my views are mixed but not yet sufficiently formed to put into useful
words. Nothing here is against that, but merely challenging the
assumption…

Breaking away from the stigma and baggage of CFML is a valid concern

Is it really?

Every time I’ve seen anyone talk about the reasons for the stigma it
has been identified as from developers who are holding on to a view
from CF5 or CF6.0 - i.e. specifically ColdFusion, and yeah, there’s
also FUD about tags and internal derision aimed at people that stick to
what they know, but is any of this actually a valid concern?

I mean beyond the egos of people that find themselves saying “I use
Lucee, it’s CFML but better than ColdFusion, yes that ColdFusion but
it’s really better now, no that was ten years ago and Lucee is
different and I AM A REAL PROGRAMMER!!!”

To be clear, I’m not saying there isn’t a stigma at all, what I am
questioning is how much it’s tied to the term “CFML” and - more so -
whether it actually matters anyway.

If Lucee is aiming to grow its user base, the easiest target audience
is likely to be those that have not yet settled on a particular language
choice yet, (as opposed to trying to wow people away from what they are
already happy with using).

How many new developers are going to say: “oh look, this Lucee thing
looks easy and fun, but wait what’s this CFML thing, oh, it seems to be
an evolution of a language that a decade back lots of people hated, so
now I’m going to forget about Lucee despite all its positives”?

I don’t think most relevant people will care about the history, and I
doubt even those that might are going to reach that conclusion - not if
Lucee actually provides a reason to attract fresh blood, and for sure
not enough to make so much effort/fuss about distancing from CFML.

shrug

It’s late here and this all might just be tired ravings which are making
too much of a fuss about not making a fuss. It’s certainly longer than
originally intended/expected to be, but hopefully it holds at least
partially valid considerations or provokes some useful thinking.

[Brad_Wood]

Speaking of generating docs from source, we’re doing this right now in
CommandBox with the commands API using a custom ColdDoc strategy and I
think it’s worked out fairly well. (Open to feedback though)

The biggest issue is just making sure that sufficient documentation gets
put into the actual code, of course. For Ex, here’s the API doc for the
“package update” command:
http://apidocs.ortussolutions.com/commandbox/1.0.0/index.html?commandbox/commands/package/update.html

And it’s generated from the component here:
https://github.com/Ortus-Solutions/commandbox/blob/master/src/cfml/commands/package/update.cfc

This same metadata is also parsed and displayed when you type the command “package
update help” which I think is pretty cool that we’re able to have HTML and
ANSI formatted versions of the same info.

Of course, we have more narrative docs in a separate GitBook format (that
allows pull requests) but I don’t feel pressured to have to cover every
single possible option there…
http://ortus.gitbooks.io/commandbox-documentation/content/packages/installing_packages/installation_options.html

The biggest issue is just keeping them linked together so devs can easily
find the relevant docs.

Regarding public comments in docs-- honestly, we didn’t add them because it
seems no one ever uses them properly. All I ever seem to see in the wild
are help requests that should have gone on the mailing list and “this doc
sucks” which serves no real purpose. A simple feedback form seems a shade
better, but we have one of those on the ColdBox wiki and it mostly gets
spam trash submitted to it.

None the less, the original comment by Jeroen was actually not about any of
this fluff, but about having nice, simple up-front examples that are easily
accessible on the home page, etc that draw people in by showing them
something short and cool. For the record, I love that idea.

[Terry_Whitney]

I’m lazy, and not that new to CFML

I am not under any circumstances renaming my projects files to
DOTSOMETHINGELSE for anyone. Too many files, too many items hard coded. The
time commitment involved becomes too much and that to me is a deal breaker.
I’ll bit ethe bullet and pay the Adobe tax 1st.

just my 2 cents>

[seancorfield]

You will not need to. Your .cfc and .cfm files will continue to work as CFML code just fine.

The suggestion for the different file extension is for the new Lucee language that the engine will support ALONGSIDE CFML. That’s completely optional, for people who want to either migrate CFML code to Lucee code or who want to write new code in the Lucee language as opposed to CFML.

Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/

“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Mar 12, 2015, at 11:36 AM, Terry Whitney <@Terry_Whitney> wrote:

I am not under any circumstances renaming my projects files to DOTSOMETHINGELSE for anyone.

[Chip_Pinkston]

I think there are two ‘stigmas’ associated with ColdFusion - one is held by
Developers, and the other is held by Customers, Companies, and Managers.

Addressing the Developer stigma to me is only something that can be done by
addressing the second. The second stigma I think is well founded. It is
also the one that Lucee can most easily address.

Regarding the foundations of this stigma, I think there are many root
causes. I can’t speak for everyone, nor why people may be opposed to CF,
but I will list a couple of points I think have always gotten in the way of
broader CF adoption.

• Cost - If it’s going to cost you north of $10k to run a server stack
• that is a mighty high hurdle to start off.
• Legacy nightmares - There is a lot of very ugly old CF code out there
  that people are afraid of touching. It works enough, but it’s an O&M money
  pit and customers don’t get what they want.
• Replacement - If someone’s going to do a replacement for these legacy
  beasts - are they going to stick with CF? There is a good chance the
  language will get the blame for problems.
• Staffing - Finding good CF developers is very hard and is also
  expensive.
• Managers - A lot of the IT managers at places will be former
  developers. If they aren’t technical people, they will probably ask
  around. So any CF proposal will probably hit the ‘developer’ stigma.

I think a lot of the ‘stigma’ for CF is that it’s too easy to do good
things badly.

What starts as the department ‘Computer Guy’ building a one page listing of
people in a department, eventually evolves into into the company phone
book. That is then expanded to be part of the job board as well.
‘Computer Guy’ is still stuck maintaining it, but ‘Computer Guy’ is not a
developer, and now he does mostly help desk work. No one’s happy about the
‘application’. No one wants to touch the code base. The company has to pay
$x,000 every few years to upgrade the server license. Everyone knows it’s
going to be expensive when it finally does have to be fixed.

That ‘application’ is not a selling point for CF. That is where I think
the stigma comes from. Why when people think of CF, they think of
applications like that, which were never really planned out, never cleaned
up, just had more and more stuff glommed onto them.

That example could as easily be applied to PHP, or any other language, I
know. But CF has been around for long enough that there are a lot of those
types of apps out there.

So how can Lucee address that situation? Personally, I think it needs to
differentiate itself from CF. It’s fine to acknowledge the support for
CFML - but I think it needs to sell itself as a ‘v2’ of the language. I
think Lucee needs to ‘win back’ the people who have given up on CF because
of the ‘stigma’.

Chip.On Tuesday, March 10, 2015 at 9:28:39 PM UTC-4, Peter Boughton wrote:

Splitting out of the “arguments against .lucee extension” thread,
because this is really a separate issue to that.

I don’t yet have an opinion on the new language/dialect/whatever stuff;
my views are mixed but not yet sufficiently formed to put into useful
words. Nothing here is against that, but merely challenging the
assumption…

Breaking away from the stigma and baggage of CFML is a valid concern

Is it really?

Every time I’ve seen anyone talk about the reasons for the stigma it
has been identified as from developers who are holding on to a view
from CF5 or CF6.0 - i.e. specifically ColdFusion, and yeah, there’s
also FUD about tags and internal derision aimed at people that stick to
what they know, but is any of this actually a valid concern?

I mean beyond the egos of people that find themselves saying “I use
Lucee, it’s CFML but better than ColdFusion, yes that ColdFusion but
it’s really better now, no that was ten years ago and Lucee is
different and I AM A REAL PROGRAMMER!!!”

To be clear, I’m not saying there isn’t a stigma at all, what I am
questioning is how much it’s tied to the term “CFML” and - more so -
whether it actually matters anyway.

If Lucee is aiming to grow its user base, the easiest target audience
is likely to be those that have not yet settled on a particular language
choice yet, (as opposed to trying to wow people away from what they are
already happy with using).

How many new developers are going to say: “oh look, this Lucee thing
looks easy and fun, but wait what’s this CFML thing, oh, it seems to be
an evolution of a language that a decade back lots of people hated, so
now I’m going to forget about Lucee despite all its positives”?

I don’t think most relevant people will care about the history, and I
doubt even those that might are going to reach that conclusion - not if
Lucee actually provides a reason to attract fresh blood, and for sure
not enough to make so much effort/fuss about distancing from CFML.

shrug

It’s late here and this all might just be tired ravings which are making
too much of a fuss about not making a fuss. It’s certainly longer than
originally intended/expected to be, but hopefully it holds at least
partially valid considerations or provokes some useful thinking.

[Jon_Clausen]

+1 Also, I think Chip should write a full short story from his example (which is so very, very real-world) - like a “Who moved my cheese?” IT parable. :)On March 12, 2015 at 9:59:47 PM, Chip Pinkston (@Chip_Pinkston) wrote:

So how can Lucee address that situation? Personally, I think it needs to differentiate itself from CF. It’s fine to acknowledge the support for CFML - but I think it needs to sell itself as a ‘v2’ of the language. I think Lucee needs to ‘win back’ the people who have given up on CF because of the ‘stigma’.

[Adam_Cameron1]

This goes back to my earlier position that trying to automate the docs,
and base them from the metadata in the source code is a fool’s errand

Entirely automating them on meta-data from the source code may be wishful
thinking, but automating them from some structured data (especially the
reference material), is a must IMO, and perfectly achievable.

This just strikes me as a case of “if your only tool is a hammer, then
everything looks like a nail”. Except in your case your hammer is “code”.
It’s also indicative of lack of requirements analysis and any sort of
project management. The latter is the fault of the Lucee Association, I
think, for at no point - that I can recall - putting their oar in and
giving us some direction.

The requirement is for a docs site. That’s it. There is, currently, no
requirement for it to be exportable in multiple formats. There is also no
real requirement for the docs to be in sync with the source code… the
docs simply don’t change often enough for this to be a necessity: 90% (at
least) of the docs that were written for CF5 are still completely valid for
CF11. Changes can be done by hand on the very rare occasions changes need
to be made.

And the requirement is a reasonably urgent one. I don’t see how Lucee can
really be taken that seriously by anyone outside this little community who
have just accepted if they need to look something up about CFML, they need
to use Adobe’s docs.

Now I know that playing with code is far more fun than populating a wiki or
a CMSed site or something, but it’s also just a barrier to getting the job
done.

All that other crap can be done down the track, if ever the requirement
actually arises. And done by whoever it is that has that requirement.

I think doing an initial import of the method/function/tag signatures into
[something] would have been a great first step. Had this been into wiki or
a CMSed site, we could have been well on the road to loading in
descriptive narrative (a lot of which could have come form the CF9 docs)
and code examples. Instead, we’re still wringing our hands and playing with
automation scripts, and the most we’ve got to show is the luceedocs.org
site which is, I’m sorry to say, only a little more useful as a chocolate
teapot.On Wednesday, 11 March 2015 13:16:01 UTC, Dominic Watson wrote:

–
Adam

[dnando]

Chocolate teapot?!

I read Dominic’s post in a different light. My interpretation, but I
thought he said he was working on a solution with Mark to allow the
inclusion of the explanatory text and examples we need within a hybrid
automated / CMSish app, and I assumed it would be based on what Mark has
already done at luceedocs.org

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Fri, Mar 13, 2015 at 9:53 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Wednesday, 11 March 2015 13:16:01 UTC, Dominic Watson wrote:

This goes back to my earlier position that trying to automate the docs,
and base them from the metadata in the source code is a fool’s errand

Entirely automating them on meta-data from the source code may be wishful
thinking, but automating them from some structured data (especially the
reference material), is a must IMO, and perfectly achievable.

This just strikes me as a case of “if your only tool is a hammer, then
everything looks like a nail”. Except in your case your hammer is “code”.
It’s also indicative of lack of requirements analysis and any sort of
project management. The latter is the fault of the Lucee Association, I
think, for at no point - that I can recall - putting their oar in and
giving us some direction.

The requirement is for a docs site. That’s it. There is, currently, no
requirement for it to be exportable in multiple formats. There is also no
real requirement for the docs to be in sync with the source code… the
docs simply don’t change often enough for this to be a necessity: 90%
(at least) of the docs that were written for CF5 are still completely valid
for CF11. Changes can be done by hand on the very rare occasions changes
need to be made.

And the requirement is a reasonably urgent one. I don’t see how Lucee can
really be taken that seriously by anyone outside this little community who
have just accepted if they need to look something up about CFML, they need
to use Adobe’s docs.

Now I know that playing with code is far more fun than populating a wiki
or a CMSed site or something, but it’s also just a barrier to getting the
job done.

All that other crap can be done down the track, if ever the requirement
actually arises. And done by whoever it is that has that requirement.

I think doing an initial import of the method/function/tag signatures into
[something] would have been a great first step. Had this been into wiki or
a CMSed site, we could have been well on the road to loading in
descriptive narrative (a lot of which could have come form the CF9 docs)
and code examples. Instead, we’re still wringing our hands and playing with
automation scripts, and the most we’ve got to show is the luceedocs.org
site which is, I’m sorry to say, only a little more useful as a chocolate
teapot.

–
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/f488631e-557c-4013-b680-a991a8566b93%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f488631e-557c-4013-b680-a991a8566b93%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

[Andrew_Penhorwood]

@chip

This post is the best description of the stigma problem that I have ever
seen. CF just makes it easy to write bad code and lots of bad code has
been written.

Andrew PenhorwoodOn Thursday, March 12, 2015 at 9:59:43 PM UTC-4, Chip Pinkston wrote:

I think there are two ‘stigmas’ associated with ColdFusion - one is held
by Developers, and the other is held by Customers, Companies, and Managers.

Addressing the Developer stigma to me is only something that can be done
by addressing the second. The second stigma I think is well founded. It
is also the one that Lucee can most easily address.

Regarding the foundations of this stigma, I think there are many root
causes. I can’t speak for everyone, nor why people may be opposed to CF,
but I will list a couple of points I think have always gotten in the way of
broader CF adoption.

• Cost - If it’s going to cost you north of $10k to run a server
  stack - that is a mighty high hurdle to start off.
• Legacy nightmares - There is a lot of very ugly old CF code out
  there that people are afraid of touching. It works enough, but it’s an O&M
  money pit and customers don’t get what they want.
• Replacement - If someone’s going to do a replacement for these
  legacy beasts - are they going to stick with CF? There is a good chance
  the language will get the blame for problems.
• Staffing - Finding good CF developers is very hard and is also
  expensive.
• Managers - A lot of the IT managers at places will be former
  developers. If they aren’t technical people, they will probably ask
  around. So any CF proposal will probably hit the ‘developer’ stigma.

I think a lot of the ‘stigma’ for CF is that it’s too easy to do good
things badly.

What starts as the department ‘Computer Guy’ building a one page listing
of people in a department, eventually evolves into into the company phone
book. That is then expanded to be part of the job board as well.
‘Computer Guy’ is still stuck maintaining it, but ‘Computer Guy’ is not a
developer, and now he does mostly help desk work. No one’s happy about the
‘application’. No one wants to touch the code base. The company has to pay
$x,000 every few years to upgrade the server license. Everyone knows it’s
going to be expensive when it finally does have to be fixed.

That ‘application’ is not a selling point for CF. That is where I think
the stigma comes from. Why when people think of CF, they think of
applications like that, which were never really planned out, never cleaned
up, just had more and more stuff glommed onto them.

That example could as easily be applied to PHP, or any other language, I
know. But CF has been around for long enough that there are a lot of those
types of apps out there.

So how can Lucee address that situation? Personally, I think it needs to
differentiate itself from CF. It’s fine to acknowledge the support for
CFML - but I think it needs to sell itself as a ‘v2’ of the language. I
think Lucee needs to ‘win back’ the people who have given up on CF because
of the ‘stigma’.

Chip.

On Tuesday, March 10, 2015 at 9:28:39 PM UTC-4, Peter Boughton wrote:

Splitting out of the “arguments against .lucee extension” thread,
because this is really a separate issue to that.

I don’t yet have an opinion on the new language/dialect/whatever stuff;
my views are mixed but not yet sufficiently formed to put into useful
words. Nothing here is against that, but merely challenging the
assumption…

Breaking away from the stigma and baggage of CFML is a valid concern

Is it really?

Every time I’ve seen anyone talk about the reasons for the stigma it
has been identified as from developers who are holding on to a view
from CF5 or CF6.0 - i.e. specifically ColdFusion, and yeah, there’s
also FUD about tags and internal derision aimed at people that stick to
what they know, but is any of this actually a valid concern?

I mean beyond the egos of people that find themselves saying “I use
Lucee, it’s CFML but better than ColdFusion, yes that ColdFusion but
it’s really better now, no that was ten years ago and Lucee is
different and I AM A REAL PROGRAMMER!!!”

To be clear, I’m not saying there isn’t a stigma at all, what I am
questioning is how much it’s tied to the term “CFML” and - more so -
whether it actually matters anyway.

If Lucee is aiming to grow its user base, the easiest target audience
is likely to be those that have not yet settled on a particular language
choice yet, (as opposed to trying to wow people away from what they are
already happy with using).

How many new developers are going to say: “oh look, this Lucee thing
looks easy and fun, but wait what’s this CFML thing, oh, it seems to be
an evolution of a language that a decade back lots of people hated, so
now I’m going to forget about Lucee despite all its positives”?

I don’t think most relevant people will care about the history, and I
doubt even those that might are going to reach that conclusion - not if
Lucee actually provides a reason to attract fresh blood, and for sure
not enough to make so much effort/fuss about distancing from CFML.

shrug

It’s late here and this all might just be tired ravings which are making
too much of a fuss about not making a fuss. It’s certainly longer than
originally intended/expected to be, but hopefully it holds at least
partially valid considerations or provokes some useful thinking.

[Andrew_Penhorwood]

CF made it easy for people without programming experience to write stuff
that worked. Since it worked they say no reason to change it which
produced the sigma around CF. Frameworks cleaned up a number of these
issues but did not fix the stigma issue.

Lots of CF developers I have worked with never spend time developing their
skills beyond what is needed to pay the bills. They have never been to a
conference. Don’t know there are other CFML engines. Don’t know the
difference between JRUN and Tomcat, etc. This is from direct interaction
in a half dozen shops.

Andrew PenhorwoodOn Friday, March 13, 2015 at 12:12:51 PM UTC-4, Denny Valliant wrote:

On 3/13/15 8:03 AM, Andrew Penhorwood wrote:

@chip

This post is the best description of the stigma problem that I have ever
seen. CF just makes it easy to write bad code and lots of bad code has
been written.

It is easy to write bad code in any language.

I use the word “language” for emphasis. Nigh on everything revolves
around it. “It” being communication.

I don’t think /where/ coders come from matters much. If you’re willing
to learn (embedding with smart people helps tons), you’ll go from static
web monkey to dynamic programming demigod, same as any other entry point.

The stigma seems to be around non-coders transforming into coders, and
that’s a silly place to put a stigma, as only Mark sprang from the womb
grok’n teh IFs THENs 'n ELSEs.

Remember how some folks used to look at JavaScript? Some may think it
is a kiddie language, but that doesn’t stop others from making cool
stuff with it. Thinking we’re special, as far as being bad, is futile,
as there is no good without bad, and thus let’s move beyond-- into yin
yang land or whatnot.

Tao,
-Den

[denstar]

It is easy to write bad code in any language.

I use the word “language” for emphasis. Nigh on everything revolves
around it. “It” being communication.

I don’t think /where/ coders come from matters much. If you’re willing
to learn (embedding with smart people helps tons), you’ll go from static
web monkey to dynamic programming demigod, same as any other entry point.

The stigma seems to be around non-coders transforming into coders, and
that’s a silly place to put a stigma, as only Mark sprang from the womb
grok’n teh IFs THENs 'n ELSEs.

Remember how some folks used to look at JavaScript? Some may think it
is a kiddie language, but that doesn’t stop others from making cool
stuff with it. Thinking we’re special, as far as being bad, is futile,
as there is no good without bad, and thus let’s move beyond-- into yin
yang land or whatnot.

Tao,
-DenOn 3/13/15 8:03 AM, Andrew Penhorwood wrote:

@chip

This post is the best description of the stigma problem that I have ever
seen. CF just makes it easy to write bad code and lots of bad code has
been written.

[denstar]

CF made it easy for people without programming experience to write stuff
that worked. Since it worked they say no reason to change it which
produced the sigma around CF. Frameworks cleaned up a number of these
issues but did not fix the stigma issue.

I’ll give you that CF makes hard things easy, but this general sentiment
can be said about every language, and generally is.

Lots of CF developers I have worked with never spend time developing
their skills beyond what is needed to pay the bills. They have never
been to a conference. Don’t know there are other CFML engines. Don’t
know the difference between JRUN and Tomcat, etc. This is from direct
interaction in a half dozen shops.

Sure, but again, this is kind of how the world of computers is these
days. It hasn’t been tiny communities of like minded folks for easily
two point five decades, if ever it was. It’s all relative… much as
the the ideas of “easy” and “hard” are.

-DenOn 3/13/15 10:55 AM, Andrew Penhorwood wrote:

[Snake]

All the stigma I have ever seen has always been against ColdFusion, never
CFML, in fact the people I have generally seen bashing ColdFusion as a
language have little more than a passing knowledge of it from many years
ago, and hate it because they were forced to use it or work on an app which
was outside their comfort zone as they did not know CFML, in fact most of
those people do not even know the term CFML, they think the language is
called ColdFusion.
Most of the haters I have seen do so because of the tag syntax, but then
that was also why most people loved it originally.
The rest of the stigma is against ColdFusion the platform due to the
various well known security issues and hacks.

I do not think any of this is relevant to Lucee and thus do not really see
any need to try and avoid that irrelevant outdated stigma. None of those
old CF hating dinosaurs are ever likely to come into contact with Lucee ,
it doesn’t suffer from any of ColdFusion’s historic security issues which
stemmed from the CFIDE, and as long as appropriate care is made to make
sure the railo admin is properly locked down by default then it never
should. So as long as Lucee doesn’t go out of its way to promote/advertise
its ties to ColdFusion, then I think it will manage to avoid the ColdFusion
stigma without having to do anything at all.
Anyone new to the Lucee platform/language is going to be oblivious to the
past so is unlikely to ever need to utter the word “ColdFusion” to anyone,
and any veterans are simply not going to care.
The whole “so easy to learn it promoted bad code” is completely moot these
days as well, as there are plenty of other platforms/languages which are
just as easy to learn and could just as easily be accused of the same thing
as a result.

Think of all the bad stigma Windows has had over the years with their
shitty releases, but it has never stopped people using Windows and you
wouldn’t avoid the latest version just because someone told you they hated
windows ME some 10+ years ago. In the same way I really doubt that anyone
cares about comments some dev makes about some ancient version of
ColdFusion he used 10+ years ago.