> > or otherwise). It's not even a reasonable excuse to have a weak stab
> > at Adobe for the sake of it, AlanW.
>
> At what point did i make a weak stab at Adobe? I merely posed the
> question. So let's not get personal here Adam.
No, mate, you didn't. *This* is a (weak) dig at Adobe:
{quote}
Is the marketing that Adobe push out, promote it as a language? The
last time I went to the Adobe site you could be forgiven for thinking
it
was a design package not dissimilar to how they market Flash.
{quote}
Your editorial is firmly positioned from the perspective of "Railo and
BD are doing something right, and making up for where Adobe are doing
wrong".
{digression}
The tone of this forum is quite often along the lines that the "third
party" CFML engines are somehow being a bit hard done by Adobe, so
perhaps your approach is to be expected. This irks me (albeit only a
bit, and only in a "oh... here we go again..." sort of way). People
seem to forget that their (BD, OpenBD, Railo) entire raison d'être is
Adobe's CF product. Without that there'd be no BlueDragon, so no
OpenBD. And no Railo either. Adobe provides the lion's share of the
marketting for the product (and accordingly product awareness),
training for the product, documentation for the product, and the
lion's share of the community. Not one person in the industry would
know about BlueDragon or Railo in their own context, outside that of
those products being a knock-off of Adobe's product. I am far (FAR)
away from being an Adobe yea-sayer, but "know your place".
{digression}
FWIW, Adobe's strapline for CF is currently:
{quote}
Adobe® ColdFusion® application server and software enables developers
to rapidly build, deploy, and maintain robust Internet applications
for the enterprise. ColdFusion 9 allows developers to condense complex
business logic into fewer lines of code.
{quote}
I think that's pretty developer- / code- / programming-language-
centric, yes? Perhaps it was different last time you looked.
> Also, another point that you all seem to have missed, is that this is
> not an isolated case -- you did catch the bit where agencies are also
> categorizing ColdFusion incorrectly. yes?
No, I didn't miss it. I just don't think you have a point. I don't
think you don't have a point from either the perspective I single out
above, nor do you have a point where it comes to the industry
perspective of CF.
I think you've made an observation, and I don't dispute its veracity -
ie: you saw what you saw - but I don't think the extension you make
here is a valid one. Well not from the perspective I am seeing,
anyhow. As someone else said: perhaps this is regional?
I think most people (in the IT industry, I mean) don't know CF from a
bar of soap. I think that most people who do know something about CF
probably know it as "some web thing... it's like PHP isn't it? Tags
instead of code, or something" or "is that still around?". This is
what *I* hear. I think people who actually have some awareness of CF
do know what it is, and don't make any mistake along the lines of
suggesting it's a design tool. It's outside my remit in my current
position, but I have a past of doing a moderate amount of recruiting,
and I don't know a single recruitment agent who hasn't known what CF
is. Their most common observation is "oh, bugger... I've got three
good PHP developers on my books, but there really isn't that much CF
out there, mate. Can I interest you in a PHP developer?". However I
only ever use agencies that I know to have successfully placed good CF
developers in other shops I have dealings with, so perhaps I am
dealing with good agencies.
Equally, when interviewing people, unless they have CF has the *top*
skill on their CVs, I don't even bother talking to them. And I
instruct the agencies to not waste my time sending CVs that don't meet
that requirement. I know other shops that will take PHP developers in
the hope of cross-training them to CF, but that doesn't seem to work
out so well: any PHP developer who's any good is going to have an
opinion about PHP (and sometimes also how it relates to CF), and
that's difficult to shake. I don't want someone on my team that would
rather be using a different language.
> The reality of the situation is that the CFML community is small, and it
> is not growing any where near the same speed as other languages. So we
> have to look at this and wonder why. Why is recruiting for it
> problematic, why is the image still of that where its not cool to be
> doing CFML.
The reason why our community is small is that one has to pay (quite a
bit, if we're speaking "Enterprise") for CF, whereas the competition
is - on the whole - free. Whilst I know there are free CF
alternatives, those don't have even the market awareness that CF
itself has, so are very very niche in an area of the industry which
itself is niche.
One can spout the "but the total cost of ownership of CF is lower than
[insert alternative here]" line, but I think that's a factor that is
far less important to a lot of companies than the CF marketeers would
like it to be. For one thing, up front cost and ongoing costs usually
come from different budgets, and one is not going to get the lower
total cost of ownership if the initial purchase gets vetoed. Also,
TCoO is difficult to measure because there aren't the tangible
metrics, so I could understand a CFO going "really? How do you know?
Where's the evidence? I mean the actualy *numbers*?". Whereas the
numbers on a price tag are difficult to dispute.
And, as things stand, I don't think BD or Railo are even part of that
conversation. This is no sleight on either product: they're fine, but
they definitely seem like "cheap knock-offs" than "the real thing".
Again: no sleight... I mean "cheap" as in "cost", not "cheap" as in
"quality". I think there is very little compelling reason - if I was
starting a project from scratch - to pay for CF rather than using one
of the freebie ones instead. Indeed the project I am currently
working on (not my day job, the other job) has just made the decision
to go OpenBD over CF (mostly on the basis of cost, but also
performance).
In the past I have been hesitant about BD (this predates OBD... my
hesitation was with the New Atlanta product) because it was so far
behind CF as far as functionality goes. This certainly tainted my
opinion of BD, but I think OpenBD does 99% of what I expect from a
CFML engine: I either don't care about the features it doesn't
provide; haven't *noticed* the features it doesn't provide; or am
prepared to work around the shortfalls. And a lot of the latter stems
from me being fluent in CF's flavour of CFML, and I sometimes get
caught out by minor incompatibility issues. Of course those issues
get dealt with very quickly by the OBD bods... usually a fix, but
sometimes a "won't fix", but at least I know. You certainly lead
Adobe in this regard (although that is damning OBD with faint praise,
I think).
--
Adam
--
tag/function ref: http://www.openbluedragon.org/manual/
mailing list - http://groups.google.com/group/openbd?hl=en
Get to Texas in Feb for OpenCFSummit http://www.opencfsummit.org/
