Friday, 22 August 2014

ColdFusion 2016

G'day:
Whilst some of the Adobe ColdFusion Team are pantsing about trying to take as long as possible to fix ColdFusion 10 and 11 bugs, other elements of the team must surely be planning ColdFusion 2016. Adobe have completely failed with their increased-frequency release cycle, but they are undoubtedly still moving forward.

Each CF release people blog "ColdFusion n wishlist". I've just googled-up articles such as:
One thing though - and I didn't check the dates on those articles specifically - we only tend to start thinking about what should go in this next version of ColdFusion Adobe are developing once the cat is out of the bag that they are developing it. By the time whispers of the next version of ColdFusion reach the gen. pop., I suspect most of the features and general gist of the release is already at least written-, if not locked-, down.


Adobe don't consult the community in the timeframe that they ought to be doing so: before they start doing any of their own planning. I know they do involve some of the "special people" in a subsequent round of discussion, but whilst Adobe think these people are special I'm not sure the rest of us necessarily should, and given the special people also don't discuss with the hoi polloi, I'm not sure their opinions really hold much water (same as mine, taken in isolation ;-).

So I think the time to start the discussion as to what should go into ColdFusion 2016 is... round about now. CF11 is out but hasn't really got off the ground yet (too many bugs to be viable in production, just yet), so it's yesterday's news. And also whilst it had a lot of excellent low-key features (member functions, better - if flawed - focus on CFScript, more "closure" functions), its marquee feature - <cfclient> - was, for most people, dead in the water from the outset. Let's try to encourage Adobe to take ColdFusion 2016 in a useful direction. If they won't actually ask the community... how about the community tells them?

Here's a list of stuff I'd like to see done in ColdFusion 2016, to get the ball rolling. It's in the order of "when it springs to mind", not in order of importance.

Package / Dependency Manager

This applies as much to ColdFusion 2016 as it did with any other time it's been mentioned in the past. Conveniently, I can simply link to what I said on this in my "What do I want to see in ColdFusion 11?" article, a year ago. It still applies.

In the interim, Ortus have come up with CommandBox which links with ForgeBox which kinda fulfils this requirement. Adobe should just sponsor or buy that, and ship it (or a version of it) with ColdFusion 2016. Or write their own, but why write it again if it's already there?

Modularise ColdFusion

CF is too big. Most people don't use most features of it which just makes those features bloat on the footprint. Rip out all the non-core stuff and either ship them separately, or make them optional to the install. I've looked at how drastic I'd like the modularisation to be previously, and asked you lot about it: "Survey Results: ColdFusion Modularisation". At the very least I'd like to see these bits as optional to the install:
  • <cfclient> and everything to do with client-side CFML
  • All the CFUI stuff like <cfform>, <cfpod>, etc
  • Charting
  • PDF support
  • Image support
  • Spreadsheet support

But I just reviewed my breakdown of what I considered "modules" in that survey I link to above, and I still stand by that.

Free

Make the baseline install - without all the modules - free. Not "kinda free but hamstrung", but free.

Repurpose CFML's general approach to code

This might not be a feature, but rather a product direction. The "feature" could be to deprecate an awful lot of what's current in CFML, and that is: most of the tags.

ColdFusion's approach to web application construction wherein on has a bunch of CFM pages which ultimately generate an HTML doc and send it back to the browser is anachronistic. At the very least the way CFML is position should follow some manner of concern-separation like MVC, and relegate tags to be things that are used only in the view layer. The bulk of code written in CFML should be well away from the views, and be written in CFScript.  Ideally the approach in CFML should be more providing web services which provide processed data to the view tier which is something else (HTML & JS on the client, for example).

CFML five-taggers might get all defensive about suggesting CFML moves with the times, but... well... f*** 'em. They'll ultimately just do what they're told anyhow, so who cares? We should not be Harrison-Bergeron-ing our language to accommodate those drips anyhow.

I discuss this fairly recently here: "Oh dear: tags vs script".

So what's the "feature" here?
  • Deprecating all tags which don't relate to views.
  • Rewriting the documentation to be CFScript-centric and marginalising tags into the view-tier documentation

Continue improving member functions

ColdFusion 11 did excellent work with the first round of member functions, but there's still plenty of room to continue this. I think a lot more of CFML's procedural functions can be shifted into an object-oriented approach. File functions already have the notion of a file object, but no member functions. PDF operations could be done on PDF objects with member functions, etc. Basically I think all current procedural functions ought to be homed in a class or as a method on an object. This would make for more consistent code: our own CFML is OO, but CF's own code is not still.

CLI / REPL

In other languages I dabble in, I use a CLI and or REPL all the time. More often than I do save code to a file and run it. It's just handy to do stuff quickly, as well as automate stuff. We should not need to make an HTTP request to execute CFML on the same machine as the code is sitting on!

Move CFAdmin, and don't install it by default

It's never really belonged in a /CFIDE directory anyhow, and it's a known vector for hackers. Put it somewhere sensible, and do not expose it at all by default. The CFUI stuff needs some stuff exposed to the public, but that should be in a completely separate and unrelated location. The two concepts are not connected.

Overhaul REST

The ColdFusion implementation is a pain in the arse to develop with, has a very arcane approach to REST, and is unreliable. I suspect - like a lot of the stuff that goes into ColdFusion these days - it was not developed by people who are accustomed to developing REST APIs, nor were they then required to use the fruit of their labours in the real world to see how well it works. Have a look at how Adam Tuttle does Taffy, and start again. REST services should be the cornerstone of CFML, and accordingly should be slick and competently implemented.

Use the updater properly

Release bug fixes as quickly as possible, and release them all the time. Also revise the approach that all updates are roll-ups. Being a Windows user I should never have to install a fix which is for Mac-only. Continuously release bug fixes, and then once every six months or so roll them all up in an updater. But keep the updates coming.

Back-port this approach to ColdFusion 10 and 11.

Caching

Instead of tightly integrating with Ehcache, instead modularise this so CF offers a bridging tier to all the common caching solutions. I see the currently caching implementation being like if CF offer DB connectivity, but was hard-coded to use Oracle.

LINQ or some facsimile thereof for CFML collection types

It speaks for itself: Language Integrated Query.

Everything an object

In Railo, a literal is an object, and can have member functions called on it, eg: "abc".reverse(). This would be a good architectural approach for ColdFusion to adopt also.

More iteration functions

myString.each(), someNumber.times(), etc. There's plenty of room for expansion with these functions.

Null

Get it sorted out. Once and for all.

Static and Abstract

Especially static methods... I'd use these rather a lot. And occasionally our API could have benefited from abstract classes and methods.

Java compat

I'd really love to be able to implement Java interfaces / class inheritance with my CFCs sometimes. So I can then use the a CFC instance where Java is expecting some specific type of object.

Break backwards compat

Adobe would need to declare this well up-front, but there's a bunch of stuff that ColdFusion only does because of a slavish adherence to "backwards compat" (which Adobe are completely happy to break if it makes their life easier when addressing something).
  • Stop passing arrays by value.
  • Stop looking around in other scopes for variables. The "closest" scope should be addressable without explicit scoping, but no other should.
  • Stop creating all literal simple values as strings (eg: x=1 will give x a value of "1", not 1, under the hood).
  • etc... there's millions of dumb things CFML decided to do which has proven to make it annoying to use, all of which could be sorted out if we didn't give a shit about someone possibly maybe somewhere having leveraged whatever poor practice ColdFusion has encouraged / forced.

Bugs

Fix the damn bugs.

You?

What would you like ColdFusion 2016 to bring to the table? Let's get some sort of consensus and get some tickets into the bug tracker...

--
Adam

NB: I have updated historical references to "ColdFusion 12" to use its actual name: "ColdFusion 2016".
Posted by at
Labels: