Saturday, 20 June 2015

What I'd like to see in ColdFusion 2016 (redux, as is happens)

G'day:
After the news of ColdFuson 2016's pre release getting underway soon presented itself ("ColdFusion 2016 is coming..."), I decided I'd work out what I'd like to see in CF2016, and knock together an article here.

In researching this this morning, I realise I've already done this! Here's the original: "ColdFusion 2016". Not to be deterred or put off by repeating myself, I'm gonna go ahead and do a new article as well, and have a look at what I thought before and whether it's changed.



Here are the suggestions from that other article:
I don't care about the REST and Caching ones any more, so I've struck those out. All the rest are still on my list. but I have more.

I'll separate my points in three sections: Adobe, Platform, and Language.

Adobe

Bugs

Address all the bugs you currently know about. By "address", I do not mean "fix", but to simply triage and decide what to do with them, and communicate this back to your clients like professionals. But, like, obviously fix a lot of them too ;-) You've been pretty good at fixing stuff recently, I must say.

Bug Tracker

Get some of the issues raised with the bug tracker fixed. It's really in need of some love. Get the bug tracker team onto this now as we really need some of the mooted features to be able to run the pre-release and betas properly.

I also now know Adobe (and it's community-based yes-men) can't fall back on "what would you rather Adobe do: work on ColdFusion, or work on the bug tracker?". This has proven to be as specious as it always sounded, because they have two distinct teams for this. Anyway, it's work that needs to be done, so just do it.

Docs

Dan Fredericks made a very good point in the comments below:

I'd also mention they need to do a better job with the Wiki Docs...add in your CFScript blog post, steal it from you if they have to. Make the docs more accessible to everyone, not just a few people to update...there are a ton of people that talk about issues or examples of work via stack overflow or twitter or other places, do those examples ever make it to the wiki, doubt it. Also, they need to do a better job promoting the wiki docs, get more people using them, updating, them and talking about them...great they moved to a wiki, but if they never talk about them, what good are they.
Ticket: 4010693.

Free

Make the baseline version of ColdFusion absolutely free. I don't mean "IP-restricted", but free. You seem to be self-sustaining with licence re-ups as far as I can tell, but never address the potential of new "bums on seats" coming into the community. The biggest impact you could make here would be to make the core product free. I don't even think this will impact your bottom line, so it could only be a change for good.

Backwards compatibility

Move on from using "backwards compatibility" as a mantra for not moving the language forward. We'll all sick of utterly specious excuses from ColdFusion Team members along the lines of "we acknowledge that's a bug, but it's been a bug for so long people might have started to leverage it so we can't fix it for backwards compatability reasons". That's just lazy-arse stupidity, and it needs to stop. A few points here:
  • that - in theory - someone might be leveraging a feature than needs fixing and it would break backwards compatibility doesn't matter. Someone might be using it? Unless you know of someone who is using it, you don't know it's a problem. Don't invent problems that don't exist. Fix problems you do know exist, and are impacting real clients.
  • On the other hand if you know for a fact a change will break FW/1 or something, then get in touch with the vendor and warn them. Well, indeed, the vendor should be on the pre-release programme, so they should be ready to deal with any breaking changes anyhow.
  • Basically don't prevent the future from happening due to guessing what might have happened in the past.
  • Tough shit. If people write daft code leveraging bugs... f*** 'em. they can fix their code. This is what a beta phase is for... testing one's code. If these people find their apps don't work with the latest version of ColdFusion, then they don't need to upgrade. Simple as that. ColdFusion 10 + 11 are still actively supported until they get their acts together and get their code working. And if they're on earlier versions of CF than that, Adobe you have no burden to cater for them anyhow. And they'll probably not upgrade if they haven't yet bothered anyway.

Deprecation advice

Be more aggressive with deprecation. Both in the sense of getting rid of already deprecated stuff (get rid of everything that is already deprecated, in ColdFusion 2016), and marking new stuff for deprecation.

Kai Koenig had a good idea over on the Lucee forums. Split the idea of "deprecation" into two facets:

  •  "deprecated", meaning it is likely to be removed in some later release. You have been warned. Make sure to document alternatives.
  • "Avoid". An element being marked "avoid" is flagged as no longer being the recommended way of doing things, however there is currently no intent to remove it from the language. Actually Jesse Shaffer has come up with a more positive-sounding spin on this: "Superseded".
  • Obviously at a later stage it might be marked as "deprecated".

This might stop being who don't understand what "deprecated" means from freaking out if you were to suggest that something is "not the way forward any more".

Lucee and Railo

With everything undertaken for ColdFusion 2016, check to see how Lucee might have already done it, and implement it the same way. There should have to be a very good reason to not follow their lead if they are in the lead (which they are, in some areas). It's not all about the whim of Adobe or the ColdFusion Team, you are doing this work for the CFML community, so serve them well.

Anit

Give him a payrise. He's a PR blessing for you guys.

Platform

The language is more important to me than the platform, but these are significant issues that ColdFusion is currently lacking in.

Modularisation

Separate all the different ColdFusion components into stand-alone modules. And I mean this down to language level, so all the UI stuff (<cfform>, <cfpod>, etc) is in a module too. Make sure everything will work (other than the areas of functionality themselves!) if they're not present. At the very least, I would componentise these language areas:

  • UI elements
  • Doc manipulation elements (both PDF and other forms of docs)
  • Image manipulation elements (including charting)
  • Messaging (Exchange stuff)

Perhaps ship them all integrated with Enterprise, but make it possible to not install them, and have a bare bones installer which omits them.

There's a pre-existing ticket (with 31 votes) to cover this one: 3602420. That ticket mentions OSGi, but I'm not sure going to those lengths - the Java community seems split as to whether it's a good approach, and I'm not sure it's really important to a CFML engine to be that modular - but some ability to not include modules ot CFML behaviour on a server would be good.

Package & Dependency Manager

This would be a separate application, and used to manage both CF's own modules, plus other modules like CommandBox and such. Please don't reinvent the wheel here... most language platforms have very mature package and dependency managers already. Study those, and make a best-of-breed one for ColdFusion.

Also create the package repository, for both Adobe's own modules, plus community contributed ones.

Work with existing community vendors such as Ortus Solutions and Sean Corfield to make sure their offerings are ready to go on launch of ColdFusion 2016.

Ticket: 3576112.

CLI/REPL

CommandBox is already pretty good here, actually. So perhaps just ensuring it's in the package repository ready to go for ColdFusion 2016's release. Ticket: 4013832.

CFAdmin

Two things here:

  1. Make it so all administrative tasks / settings can be done via plain text file, or via application settings. I know you've already got those WDDX files for settings, but that's not really usable if yer a human (4013820).
  2. Make CFAdmin a separate module that can be optionally installed. Do not include it by default. Ideally make it so to can do its work remote to the server it's configuring (4013824).

Also make sure the install / config for CFAdmin does not encourage installing it in an outward-facing fashion by default.

Updater

Updates should be able to be done via the package manager, perhaps? It should not need CFAdmin, anyhow (4013825).

Module updates should be decoupled, and handled within the package manager.

Language

OK, now the interesting stuff. I only want language features that I can't implement already with third-party libraries. We can all already do all that shit, so it's not a good use of the ColdFusion Team's doing their own implementation of it. The ColdFusion Team needs to focus on the core language.

Deprecate all procedural functions

And by that, I mean all the actual functions in the CFML language. EG: listAppend(), fileExists(), writeDump() etc. Deprecate the lot. CFML is an OO language, so make it OO! Create classes, and put the functions in them. That way all our code can be developed in a uniform fashion, rather than using our own code in an OO fashion, but still needing to fall back to procedural for when we use inbuilt CFML stuff. This shoulda been done in CFMX6, btw!

And for all you people who don't write OO and have change paralysis: don't freak out. I said "deprecate", not "remove".

Tags

Think twice before adding any more tag-based functionality. We are where we are with tags, but let's accept that tags are only really appropriate for views, so any new tag should only be useful solely in a view. If functionality would be useful outside a view, it should not be implemented as a tag.

CFScript revision

A bunch of CFScript stuff needs a second look. There's constructs like savecontent which takes the variable being set as a parameter, rather than savecontent returning a value, eg:

Not this:
savecontent variable="content" {
    // stuff here
}


But this:
content = savecontent {
    // stuff here
}


Indeed Adobe should perhaps read my commentary here - CFML: the evolution of functionality - and reconsider their approach to "block" style CFScript constructs completely, IMO. Resulting in more deprecation of existing work. This is partially covered by 3643125, but that's more specifically focused on savecontent. The issue needs looking at generally: a mindshift away from representing tags in script in general. That approach was wrong.

Everything is an object

Everything. Including literals, and expressions. Remove uncertainty in the language due to second-guessing what can and can't be done with an expression.

Everything is an expression

All statement should be usable as an expression, and evaluate to a value. These last two are just givens in a bunch of modern languages.

Ticket for this and the previous one raised together: 4010487.

Mixins/traits

Add them in. I think PHP has a pretty good approach to these, but it'd be worth looking at how other languages do them. I think Ruby seems to have messed it up though, as there's a lot more effort in using them than their ought to be. Ticket: 4010488.

Implicit getters and setters

Implement them properly, not simply via the invokeImplicitAccessor Application.cfc setting. I recommend using the C# syntax (only because it's the one I've used, and it's simple and obvious): Accessors. Ticket: 4010489.

Expose the interfaces that dictate built-in types

Currently a struct function can only take an actual struct (well: it's some underlying Java class, but you get my point). Publish and expose-for-use the interface so we can implement "structness" on our own classes so they will work as structs (or arrays, or [whatever]). I should be able to implement an ArrayAccess interface in my class, and then use it in a for (element in array) loop, for example. make sure to change all built-in functionality to expect the interface, not the type, obviously (perhaps not "obviously", because PHP forgot to do this in places). Ticket: 4010490.

Range as a type and a literal

[1..10] should define a range which is a collection object representing the numbers 1-10. Perhaps implement it as [x..y;z] where z is (optionally) the increment. Ticket: 4010491.

More iteration methods

reduceRight() for one. I've definitely needed that. I also like the .times() method one can call on an integer. That's cool. But perhaps look what other languages are doing in this area. Look at Underscore.js for inspiration. Ticket: 4010496.

More types are iterable

Strings (iterable by character), and numbers (via a range). Others? It might be looking at recursive iterators too, for better dealing with hierarchical data structures. Ticket: 4010498.

Closures

Make sure there is no real-world performance consideration when using closures. They should be considered "first class" elements of CFML, so they should be the prescribed way of doing things. This means there can't be considerations like "I'd use myArray.each() to iterate over my array but it's so slow I always fall back to for (element in array)". Macromedia did a great disservice to CFML by implementing CFCs but made them so slow as to be unusable for versions 6-8. All these contemporary functional elements in CFML need to be quick.

Also implement IIFEs (3950736).

Futures/Promises

Having some implementation of Futures / Promises into CFML would be interesting. I've messed around with them a bit via Guzzle in PHP, and they're pretty easy, and would be a sitter for a CFML implementation, and open it up to concurrent programming possibilities. Ticket: 4010501.

Event system baked in

An implementation of the Observer Pattern, to allow code to be wired together on the basis of events being triggered, and handlers being bound to listeners. We've already tested the water here slightly with the Application lifecycle event handlers (onApplicationStart(), etc), and those have been a resounding success. Perhaps we could push the boat out more?

I think previous times this has been suggested the whole event-driven concept might have been too immature in most people's minds for them to get their brain around them, but now with everyone working with jQuery and its ilk, it's kinda second nature these days.

I've written about this in the past, actually: "Native event framework for ColdFusion 11 ?". Ticket: 4010477.

Linq

The iteration functions are cool, especially if there's a unified interface for all of them, but a more "human" querying approach for collections would also be excellent. Linq is an industry defacto here. I think it's a Microsoft trademark, but the general technique won't be. Ticket: 4010474.

Null

Sort it out, Jesus. Break any backwards compat you need to to do this. Just make it work. Null is a real thing: stop pretending it isn't, or that an empty string is a suitable facsimile of it. Ticket: 4010516.

Static and Abstract

I'm using these quite a bit in PHP now, and they're quite nice, and a bit of a long-standing omission from CFML's OO. Note that Lucee has a pretty good implementation of both, so follow their lead here.

Maybe think about "final", too, although I'm less convinced that's a useful feature.

Note: this has been confirmed as not going into ColdFusion 2016: 3756518.

Java integration

I should be able to use a Java class anywhere and in the same way I use a CFC now, eg:

s = new java.lang.String("Yeah, bad example I know");

I should be able to specify Java class types in function argument type and return types too.

I should be able to extend Java types in CFML. I should be able to implement Java interfaces with a CFC, and have be able to use these CFCs in Java method calls expecting the given parent class / interface.

Ticket: 4010514.

CFC-based custom tags

Custom tags use should be actively encouraged more to reduce the amount of CFML people need to put in views. However Lucee's implementation of custom tags is far better than ColdFusion's. Have a look. Ticket: 4010503.

Update the frickin' regex engine!

Come on guys. Join the 21st century. Although it looks like this is targeted to fix! (3037998)

Small things

  • comparison operator: <=>, and Comparable interface. Ticket: 4010512.
  • operator overloading (OK, not a "small" thing, but it's only on the periphery of things I've thought about)
  • Generators and Iterators. Ticket: 3555025.
  • Use a fluent interface on member functions which currently return pointless booleans or numerics. Just return the object itself instead. Ticket: 4013838.

That's it. For the time being.

Looking over this again now, there's a few pretty bloody marketable features here. A lot of it is playing catch-up with other languages or platforms, but being able to talk about package managers, CLI/REPLs, functional programming, concurrent programming are good features. They don't have to be superficially implemented and fairly hollow PHB-crowd pleasers like Flash Forms and CFClient to be cool stuff that people would want to use (or at least have heard the buzzwords of, and think they want to use them!). If implemented correctly, ColdFusion can return to its angle of making hard things easy. But give up on client-side code concepts: they're not hard any more, so you sound daft suggesting they are, and make ColdFusion sound backwards.

Modern coding concepts can be seen as hard to developers who haven't tried them before (how many people can't get their brains around closures, or promises, etc?), and they'd appreciate the comfort zone that is ColdFusion making it easy for them. The thing is: "just providing it" makes it easy. They don't need to exit their CFML nest to try stuff out and find out they can actually do these things. So if ColdFusion 2016 was to include features like these, it'd also be assisting CFML devs actually get better, and also it might encourage devs to not drift off to other languages that have more opportunity to do different things.

So that's my brain dump. Thoughts / additions?

--
Adam
Posted by at
Labels: ,