Saturday 21 July 2012

Joe Rinehart's thought-provoking video

Joe Rinehart released a very forthright and thought-provoking video about what he perceives to be some significant issues with ColdFusion as it stands today.  If you've not watched it already, here it is:

And the URL is:

I've taken the liberty of transcribing the "script" of the video here (well: I couldn't be bothered doing a 100% transcription, so it's a bullet-pointed transliteration/paraphrase), as a basis for a discussion.  I hope you don't mind Joe, and if you do: let me know and I can work out an alternative approach.  But just to be clear, the text in the grey box below is Joe's good work, not mine.  I was just the typist.

  1. Adobe doesn't love ColdFusion any more
    • These people did:
      • Allaire
      • Macromedia
      • Ben Forta, Tim Buntel, Adam Lehman
    • Not Adobe
      • CF buried way down product list
      • In the market perception is reality
  2. We're going to two different places
    • "I spent the past four years working in Flex"
    • [swearing]
    • "For CF, this means I needed a good service tier before anything else"
    • Used to be the best under Flex
    • "With the world moving [to] HTML 5, I still have the same need: a simple, productive app server to write business logic"
    • Needs simple productive app server to write business logic
    • Don't want one thing that's going to try to be everything
    • Just want some tool I can go to to write the stuff that my UI needs to actually perform a useful function
    • In JavaScript or mobile code
    • Grails
      • core-centric, third parties focus on festure plug-ins
    • ColdFusion focuses on add-ons, but ignores the core
  3. Little things kill
    • Apple's focus on quality
    • CF should hide klunkiness of Java not introduce its own
    • It's a paid-for product, so should be smooth from start to finish
    • Installer
      • Add "Solr"? What is it? Who actually cares? Just call it "search services", just install it
      • Open office integration option
        • doesn't detect whether OO is installed upfront
        • Sloppy screen
      • Too many passwords
        • what's an administrative services password?
        • RDS password
        • Just capture one password and reuse
      • Disk space in bytes!
        • No indicator if one has enough: this check can be done upfront
      • This does matter
      • Grails install is very short
    • Code is wordy
      • Tags are great for "webmasters"
      • CFScript has a tendency to look like tags without angle brackets
      • Grails is very lean
    • Programmers use English
      • ColdFusion does not use natural language construct
        • dotNetToCfType() => convertFromDotNet() (does not take a type, it takes a value)
        • wsGetAllChannels() => listWebSocketChannels()
        • Docs are wrong
        • hmac() => createHMac()
        • imageMakeTranslucent() => makeImageTranslucent()
        • cacheRegionNew() => newCacheRegion()
        • thingDoSomething()
        • Out of date convention
      • Devs should be able to handle object.doSomething(), if not: forget 'em: they won't make it
      • "Don't tackle the least common denominator because you'll come up with the least common denominator product"
    • "Stop living in a bubble"
      • Developers use a lot of languages
      • CF needs to integrate into that
      • eg: array lengths
        • JavaScript: someArray.length()
        • CoffeeScreen: someArray.length()
        • ActionScript: someArray.length()
        • Java: someArray.length()
        • Groovy: someArray.length()
        • CFML: arrayLen(someArray)
      • eg: key in a map
        • Javascript: key:"value"
        • CoffeeScript: key:"value"
        • ActionScript: key:"value"
        • Groovy: key:"value"
        • CFML: key="value" (and CF was last to implement implicit notation)
      • CFML is a commodity
        • "you're not special enough to justify all your weirdnesses"
      • ColdFusion would still rule if it lived in the world it arose in, but it now lives in an ecosystem
      • You cannot be everything
        • will not be the HTML5 solution
        • will not be the JS solution
        • will not be the entire ORM solution
    • CF doesn't focus
      • Stop asking usergroups what features to add. Will result more stuff being "tacked on".
      • Go back to making the good features great again
        • Used to be angle-bracket syntax, back when integration into HTML was the main thing
        • These days this is the worst thing about CFML: its reliance on tags
      • "Kill anything that isn't great"
        • cfpod
        • cfwindow
        • if it doesn't work, if it's not great, and isn't up to par, and can't keep it maintained: don't do it
      • Make a plug-in architecture
        • Make note of how Grails does it
        • Don't need to wait for entire product releases
    • "Make the CF team write web apps". None of them seem to have ever used CFML.

I agree with the bulk of this. I think a lot of it had already occurred to all of us, but there's a few good points here that I hadn't really thought about.  Good work Joe.

There's a coupla things I want to comment on.
  1. It is very clear that Adobe doesn't give much of a rat's-arse about ColdFusion.  The guys on the CF Team (devs, and people above them) might be completely behind it, but I can't see that Adobe is, for the reasons Joe cites.  A recent example here is that recently ColdFusion 10 was released, and there was no fanfare on Adobe's website at all.  In fact there was not a single mention of it that Google could find on the site.  The best they mustered was a generic press release.  What message does that give to the industry at large, and the CF community?  To be honest, I think they should do with ColdFusion what they did with Flex: give it to Apache.  That said - not being part of the Flex community - I have no idea how that move has affected Flex.
  2. One point that hadn't occurred to me is that Joe points out that CF used to be the top of the game for HTML-generation, and really positioned itself there. Things have moved on, and the playing field is different.  Just being slick at generating HTML isn't enough now.  Whilst my current position is far more front-end-focused (ie: I work on an actual website) than I am used to, an awful lot of the code I write is based in the tiers behind that.  And it's not all HTML now either.  Joe makes a good point that JS is very important to websites now, and ColdFusion's foray into JS is pretty limp, and it is out of date before the CF version is even released.  And what about mobile app code generation?  Should ColdFusion be looking at doing to mobile app code what it did for HTML generation.
  3. I pored over the installer on CF10 when it was in pre-release, and found a bunch of spelling and grammar errors, but obviously missed some.  So any errors there are as much my own fault as the guys at Adobe.  Although they should probably not have to rely on a volunteer ColdFusion developer who happens to be able to string a sentence together to do their proof-reading for them.  But my own particular blame aside, you're dead right: polish like this is very important to market perception.
  4. Agree completely regarding all the password nonsense in the CF installer.  Most ColdFusion installs will be dev ones, so to enforce three passwords during install is dumb.  "Being all secure" should be an optional install activity that one opts-in to, not something that's enforced for all installs.
  5. I always chuckle when I see that I have 301,219,782,656 bytes left on my disk, but fortunately CF only needs [whatever] of that.  What are they thinking?  I imagine it's just the default of the install packager they use.  A minor thing, but sloppy.
  6. Good call regarding function-naming.  That said, what's done is done, and there's something to be said for conforming to an established approach, rather than adopting a newer better one as things progress.  Look at PHP: there's no sense of cohesion in its approach to function-naming-strategy, and the language is a mess.
  7. Still, there's no excuse for just getting things wrong, as you point out with dotNetToCfType().  It's not converting types, it's converting values.  This counts as a bug to me.
  8. The bulk of CFML's inbuilt function library was created back when it was procedural rather than OO, which explains why we have arrayLen() rather than myArray.length.  That said, there's no reason why CFML can't go this way now, I guess?  I have to say I really dislike the new Query.cfc and its ilk though, because it adds another way of writing CFML code that conflicts with the bulk of the rest of the language.  However this is because those "service" CFCs are outliers compared to the rest of the language.  If the rest of the language was re-tasked to take an OO approach, I could get behind this.  It would need to be an all or nothing undertaking though.  It'd be a nice one, though.  Note: I would advocate deprecating everything that had been replaced, but not obsoleting it (ever).
  9. That said, I think the examples with the array-length thing were selective to demonstrate a point (not - like - I don't do that on a regular basis myself!).  Let's look at the top ten languages on everyone's favourite list, Tiobe:
    sizeof array
    sizeof array
    This is based on 5min googling, so I might have not got it 100% best-practice or current, but it demonstrates the point: there's plenty of ways of getting an array length.  ColdFusion's approach is not so out of place.
  10. You're dead-right about Adobe needing to wake-up to the idea that CF is no-longer the playmaker in its sphere, it's a niche, inconsequential player which is actively derided by a fair chunk of the sphere it plays in.  Whether this is "fair" or "justified" is neither here nor there, it's reality, and to be frank: a lot of this is Adobe's doing, I think.  Adobe needs to work with that.
  11. I disagree about Adobe not asking user groups what they want in CF, however they need to choose who they listen to.  I would hate for Adobe to be solely in charge of the direction ColdFusion takes.  There are a number of people in our community that would have a more informed opinion on where CF ought to go than anyone currently at Adobe would.  IMO.  That said, they should not shoot for the lowest-hanging fruit that the loudest people (I just excluded myself, there ;-) clamour for.  But the community should have input.  Not all of the community, but some of it.
  12. I'm all for "documentation-level" deprecation of elements of CFML that are rubbish. What I mean by that is that the deprecation is implemented by putting a notice in the docs - loud and clear - "this functionality is deprecated - it is recommended that you do not use it" (with a suggested alternative).  And that functionality should continue to be present in the language, and even perhaps have serious bugs fixed, but it should no longer be actively developed.
  13. A plug-in, community-driven architecture is a must have.  It seriously is.  People have been asking for it for I don't know how long, and I cannot understand why it's not been delivered.
  14. I agree that it does not seem like the bods in the ColdFusion Dev Team have ever actually either built a web app, or used CFML.  They seem very disconnected from the actual real world sometimes.  The people who write the sample code in the docs are - likewise - disconnected.

Now for some further thoughts that Joe didn't touch on:
  1. Coupled with the plug-in architecture, I'd release a cut down version of ColdFusion for absolutely free.  It should have the core language, but none of the bells and whistles (charts, ORM, etc).  And it could possibly be thread-throttled?  Not sure about that.  I dunno what ought to be done about DB drivers as they are licensed from DataDirect?  Someone else can work that out.  But removing the pricing barrier is needed to re-establish interest in CF and build its community back.
  2.  Adobe need to participate in their own ColdFusion forums.  The community expects this, and - from someone who has sunk a lot of time into helping there - it's embarrassing to tell people they can expect no help from Adobe there.  This is especially poor when a new release of CF has come out, and people are naturally going to be having issues with it.
  3. Senior people in the community could stop by and help out there too, actually!  Getting other community member's problems solved quickly will build up the community.  We can have blogs coming out our arses, but most ColdFusion developers don't read 'em, in my experience.  We need hands-on help where it's needed.
  4. The docs should be "open-sourced" or whatever the term is for allowing the community to maintain them (like  ColdFusion's docs are appallingly superficial in places, and I'd go and fix 'em if I could.  I know other people would too.
  5. Actively look at what the top languages do, and consider whether it'd be a good fit for CF.  I don't mean stuff like ehcache and Hibernate, but language constructs (stuff that can't be plugged-in).
There'll be more - if you're reading this and have an idea, please a comment - but that's enough for now.

Enjoy your weekend.