Breaking away from the stigma...?

dev google-group-archive
21

…

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

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

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

-DenOn 3/13/15 2:53 AM, Adam Cameron wrote:

22

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 http://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…

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 15, 2015, at 4:08 PM, Russ Michaels <@Russ_Michaels> wrote: