Thursday 2 January 2014

ColdFusion: contempt of court

Be forewarned. If you're the sort of person who reacts poorly to me being a meany, then can I just refer to this this right now: "Why weI fight" (and this blog's communication policy), and perhaps you oughtn't bother reading this. I do call into question someone in our community's professional capabilities here. And some of you might not like that. [shrug].

I am reproducing this here, as some of it has already been redacted by Adobe. I understand why they have done this: fair enough.

Here's an exchange in the comments (OK, not the best place for me to have posted some of this, I know) against bug 3648781: "Closures cannot be declared outside of cfscript".

Rupesh Kumar (RK):

11:02:55 PM GMT+00:00 Jan 1, 2014

It is not about half implementation at all. Outside cfscript, functions are declared using cffunction tag. Now how do you define the closures in tag syntax? The only way to do that would be using an ugly mix of script and tag which would look like

<cfset c = function(){
    var a = something;
    var b = foo();
    return a * b;

To me, this syntax looks confusing. Given that more and more new code is being written in cfscript, I feel we should not mix script and tags in this way. Deferring it for the time being and we will revisit this later.

Adam Cameron (AC):

3:01:16 AM GMT+00:00 Jan 2, 2014

It's just an expression like any other sort of expression, Rupesh.

You can't say "oh, this sort of expression is OK in a CFSET statement, but this other sort of expression? No, can't do one of those". That's ridiculous.

By way of comparison, this already works fine in Railo. But then again they're not quite so judgemental/patronising as to what will / won't look "too complicated" for CFML developers.

I think if it looks complicated *to you*, you probably should not be making decisions as to what does and does not go into the language.



4:18:33 AM GMT+00:00 Jan 2, 2014

@Adam, of course it is an expression but with closures, things become different. There is no other language construct where an expression body has statements. The Closure body will have statements. Now should those statements be written using the tag syntax or script syntax? Is it ok to have the Closure body always in the script syntax and only allow declaring the Closure in tag? One can argue that since he/she is not inside cfscript and he/she should be writing the statements in the tag syntax using cfset.

Considering these things, we had decided to have Closures only in script. Closure in tag, if really required, needs to be thought out properly.

p.s : I would really appreciate if you can tone down your aggressive stance, avoid any personal attacks and focus on having a meaningful discussion.


4:41:05 AM GMT+00:00 Jan 2, 2014

Yeah, obviously (?) the expression can only be expressed in non-tag syntax. That's a bit of a no-brainer.

As I referred you to previously, Railo have already implemented this, so you can simply use them as the reference implementation. Their implementation works, and makes sense.

However if you are specifically speaking of functions using closure, then there's no reason a function using <cffunction> cannot be compiled to leverage closure, just with an attribute flagging as such. However I think you're actually only referring to function expressions?

As for your last para: I single you personally out for derision because I think you are - more often than not - a negative impact on the development and progression of ColdFusion and - less so now that Railo has taken up the reins of leading CFML's direction - CFML in general.

I think your positions on a lot of things raised on this system are ill-conceived, lazy, and the worst representation of the work-avoidance malaise that has fallen over Adobe's approach to ColdFusion.

And I think this needs pointing out. And I will continue to point out when your attitude is complicit in a general approach to holding CFML back.

I absolutely *won't* sit back and just blithely accept any half-arsed ignorant justification you make for not doing work, without actually assessing its veracity (you will note that when you actually have a valid point, I'm quick to agree with you). I would be doing our language a disservice if I just let you go with your deflections.



5:41:25 AM GMT+00:00 Jan 2, 2014

@Adam, I have removed the last personal comments and unfortunately I will have to report this.


6:12:13 AM GMT+00:00 Jan 2, 2014

Sure, it's probably good that it comes to "their" attention anyhow. But they weren't personal comments, they were entirely directed at your professionalism. That I happen to think you lack in some areas in that regard is not "personal". I don't care (and will not pass judgement on ~) what you're like in your personal life, I only care what you're like in your professional life, and I'm afraid to say I think a major element of that is that your professional conduct detriments ColdFusion. And I am passionate about that because I rely on ColdFusion to feed, house and clothe myself (for better or for worse). Feel free to report that too. I certainly will be reporting ("on ~") all of this.

Back on topic though: let me "conjecturise" a bit.

Talking to a former Adobe (well: Macromedia) employee... is it a case here that the main blocker is not the explanation you offered (which is, as I noted, a weak, patronising and dismissive one), and as much that the ColdFusion code parser is split into two different "systems": one for tags and one for script, so compiling a statement that has elements from both the tag lexicon and the script lexicon will require not insubstantial re-engineering on your part? And Railo doesn't suffer from this as they approach code compiling differently (probably due to recognising CFScript as a first class citizen early in the piece)?

If so... entirely fair enough that this gets sidelined for the time being. I do believe it should have been dealt with properly in CF10 (this was first raised during CF10 development, remember), when the situation arose, but - so be it, "we are where we are". Does the way the parsers work completely negate this sort of thing without a major overhaul, or is it just too much to take on at this late stage?

Like I said: this is just speculation on my part, so could be completely wide of the mark.

I realise I am "pushing the envelope" there (and "pushing the envelope" is perhaps an understatement, yeah, I get it), but I am so utterly fed-up with the patronising, basically contemptuous tone Rupesh takes in this and many other areas of his communication to the community. At the same time coming across as really just offering hollow lip-service by way of - seemingly - trying to get out of doing work.

And - sorry mate - I'm gonna call you on it. Every time you are patronising, dismissive, or I suspect dishonest, I'm going to call you on it.

I would have let all this slide had this not landed in my inbox via shortly after I posted the 4:41am comment (not actually posted at 04:41 GMT+00; it was 12:41 GMT+00, but hey), and just before Rupesh's notice of redaction / reporting of me to Sir:

There are two Adam Cameron inside you - one who has a talent to find things that is incorrect or inconsistent, who can find really great bugs, who will not accept things the way they are, who is quite vocal and the other one who is a complete moron, an ass hole, an idiot, who never stops at spitting venom and the worst human being one can ever see. The world would be a much better place without the second Adam Cameron.
Now... this could be coincidence. However I'm not exactly flooded with feedback on, this is the first for more than a week, and only the seventh in total, so it does seem like a mighty coincidence in its timing here.

I welcome feedback on (I have been meaning to blog about it, but forgot until just now), and it makes for interesting reading. I'll discuss this separately.

However if this was Rupesh's reaction to my observations, you could have just emailed me, sunshine.

If it's not Rupesh's own feedback, then it was a mighty timely coincidence, wasn't it? Interesting.

Anyway, there you go. Some bile to start the year.