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.

Jason

[Andrew Dixon]

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
mso - Lucee - Member

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

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/7002f18e-259b-4d0c-ae8e-a4f5f664167c%40googlegroups.com.

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

[Nando Breiter]

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: ariamedia

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

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

[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'. 

[Adam Cameron]

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

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

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/74083180-f689-4832-b6d3-a065fde70c70%40googlegroups.com.

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: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL 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

[David Chaplin-Loebell]

On Wed, Mar 11, 2015 at 3:24 AM, Jason Morris <jason.mor...@gmail.com> 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.

They did.  They called it "Coldfusion MX" and they rebranded their production tools (Dreamweaver, Flash, Fireworks) using the MX designator at the same time.  Then they were bought out by Adobe and that branding all went away.

Digression, but... 

Community-owned food markets open to everyone. www.weaversway.coop

[Nando Breiter]

On Wed, Mar 11, 2015 at 2:16 PM, Dominic Watson <dominic...@pixl8.co.uk> wrote:

 They (docs) 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.

Looking very much forward to that Dominic! 

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

[Igal @ Lucee.org]

well then...  Lucee in the Clouds?  or better yet, Lucee in the Sky?  forget Ruby Gems, Diamonds are better... 

how about "Lucee in the Sky with Diamonds"?
https://www.youtube.com/watch?v=rGFlkcnZRFI

--

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

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

[Chris Blackwell]

and unicorns

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

[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

 

 

[Sean Corfield]

On Mar 12, 2015, at 11:36 AM, Terry Whitney <twhitn...@gmail.com> wrote:
> I am not under any circumstances renaming my projects files to DOTSOMETHINGELSE for anyone.

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)

[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";

</cfextention-PHP>

</cfloop>

[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:

[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. :)

[Adam Cameron]

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

[Nando Breiter]

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: ariamedia

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f488631e-557c-4013-b680-a991a8566b93%40googlegroups.com.

[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 Penhorwood

[denstar]

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

[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 Penhorwood

[denstar]

On 3/13/15 10:55 AM, Andrew Penhorwood wrote:
> 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.

-Den

[denstar]

On 3/13/15 2:53 AM, Adam Cameron wrote:
...

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

Well, we are coders. :)

I don't find it surprising that we make the right tools for the job.

Hammers would be cool tho-- can't wait until we can 3D print with metal
easier!

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

There's a book that's pretty old now, but is still solid gold, called
"The Pragmatic Programmer". It deals with a lot of the stuff you talk
about.

The docs and the source code relate, as the docs are about the source
code (thus they have to be linked somehow, if not directly, by version
number, etc.), and of course there's a requirement for them to be
exportable in multiple formats. I'd love to see other languages, even.

Lucee is way more active than Adobe, so there are different concerns,
especially regarding documentation. Lots of people are talking about
neat stuff like deprecation. I think that relates here as well.

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

Why do the job once, when you can do it a hundred times. =)

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

We've been down that road before, a couple times. Professing the idea
that this time it would have solved the problem is indicative of a lack
of requirement and resource analysis. Not that I'm some kind of paragon
of project management, mind you, I'm just say'n. ;)

I'm giving a golf clap for the chocolate teapot line though. =]

-Den

[Russ Michaels]

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.

[Sean Corfield]

On Mar 15, 2015, at 4:08 PM, Russ Michaels <ru...@michaels.me.uk> wrote:

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.

I agree — mostly — and that’s why I was pleased to see lucee.org be so neutral about the language itself — and not advertise itself as a CFML engine. The only caveat is a point you mentioned:

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.

As we’ve seen, suggestions to "do away with" tags in components in the new Lucee dialect have been met with resistance (even tho’ no one is suggesting doing away with tags in CFC files or CFM files!).

As someone who talks to a LOT of non-CFML people at a lot of conferences and user groups, tags are the main "hater" point — they’re fine in a templating language (Hello JSP!) but no one, outside the CFML community, thinks tags are a "real language" or any sort of serious way to write programs.

So if Lucee can continue to tread that — admittedly very fine — line between supporting legacy CFML (through .cfc and .cfm files) but promoting itself as a new, powerful scripting language for the JVM (through .lucee files — where tags are only available in templates / views) then it can really skirt around the stigma.

But no one should underestimate the amount of work involved in establishing a "new language" in this space, and getting clear communication from the Lucee Association around their plans would help sooth everyone’s nerves I think. And of course there’s all the legacy CFML discussion on this Lucee mailing list which would certainly "scare off" some of those non-CFML developers we’d like to attract.

It’s definitely a balancing act. I’m still hopeful but I really would like to see stronger leadership from the Association...