Not that I was at CFSummit, but thanks to Tony Junkes, I saw some interesting slides about ColdFusion "2016" (yeah, the next version, not 11) which can only lead one to speculate...
But first a gripe (hey, this is me, remember). Dazzle? Are you trying to make a mockery of ColdFusion, Adobe? This is like some programming newbie who gives themselves the handle "ProgrammingNinja!" or something. It's not up to you to decide how cool you are; it's up to the audience around you. Rethink that bloody name to something less self-aggrandising. And less like something out of TAoPQotD.
Anyway, the interesting stuff...
Road Map
(yeah, sorry, the links are gonna be links to the photos of the slides that Tony took sorry).Here we have (time to get my table-based layout skill ready):
| Future of the web - vertical | Areas | ||||
|---|---|---|---|---|---|
| Mobile | Enterprise Mobility | ||||
| Responsive Multi Screen Content | |||||
| Modernized Platform | High Performance Runtime | ||||
| Modular Nimble Engine | |||||
| Enterprise Class Package Manager | |||||
| Language Revamp | |||||
| Horizontals | |||||
| Peformance | Security | HTML5 | |||
OK, so I'm going to ignore the mobile stuff as it'll still be as wrong to be doing it in ColdFusion 2016 as it is in ColdFusion 11, so I simply don't care.
Modular nimble engine
But "modular nimble engine" sounds interesting. Well forget "nimble": that's marketing-speak. But very pleased they're modularising things. But I wonder to what extent? This conversation has done the rounds a lot of times, and I've posted my own take on it as well: "Survey Results: ColdFusion Modularisation". It can only be a good thing though. ColdFusion has become such a cruft-filled monster that it's time it shook some stuff out of the core. I'm all for leaving stuff like <cfform> and <cfclient> as deprecated options, but they should not be part of the core install. People can install them if they want them using the...Enterprise class package manager
Here's Tony's photo of the slide (I'll spare you my design skills this time). Cool! Hopefully this is like Ruby Gems or Node.js's NPM system (not that I've used the later... I've not touched node.js, but I've heard great stuff about NPM). It's high time for this, and something people have been clamouring for. It seems to have all the key points:- A portal/registry to list all packages available
- an organization (excuse my ghastly American spelling... I'm quoting this) - a custom package registry
- CF Developers - easily contribute to this registry
- info about package exposed as a REST webservice
- Configure multiple registry URLs
Language revamp
(Tony's first photo; second photo; third photo).This is a monster. Check out all the bullet points:- Focus on optimized performance on JVM
- Breaking backwards compatibility
- Anything with quotes is a string, scope search
- Increased support for OOP - retain simplicity
- Tighten interface implementation
- Collection datatypes
- New logging framework
- Create WAR and deploy anywhere
- Image manipulation revamp
- Extending the language
- Concurrency
- Existing support - CFTHREAD and CFLOCK
- Synchronized functions and blocks
- Concurrent data structures
- Atomic variables and non blocking IO
- Inherently concurrent - Actor model
Breaking backwards compatibility
I wish I had the Photoshopping skills to come up with some Walter-White-based image (as has been people's wont, recently) to go with this. But I don't. So I shall spare you, and you'll just need to imagine it.So is ColdFusion 2016 going to be CF's Python 3.0? Hopefully. And hopefully Adobe are going to do this right. They should hastily revise the docs now and mark a bunch of stuff deprecated, and make it clear that come ColdFusion 2016, that stuff will be gone. So that gives people a coupla years to get their house in order. I guess this is why Rakshith did that "Feature usage survey" a while back. He said he'd give us the results, too. I must chase that.
Anything with quotes is a string, scope search
I dunno what this means. Isn't that the case already? Or perhaps it means to imply that things without quotes will actually be [not strings]. So we'd have this:notANumber = "42";
actuallyWillBeANumber = 42;
And under the hood these things will be given suitable data types? A better example might be that "10/26/2013" will get treated as a date by CF, but I really only mean it to be a string and for it to not treat it as a date. So perhaps tightening-up their loose-typing a bit. This would be a good thing. I'm all for dynamic typing, but I'm not so sure about loose typing. I do generally want to have control of the data type of my variables, because they're seldom really used in a multi-purpose fashion. It'll either be a date or a string or an integer, but a given variable will generally not be used as more than one of those, so I'd actually like to be able to say to CF "it's a date. Leave it as a date unless I tell you otherwise, which I will then explicitly do; but for the time being, it's a date, OK?" Probably with more succinct sytax though ;-)
As for "scope search", I hope the context there was "get rid of it". That would be the best thing to do. An unscoped variable should be a reference to something in the "nearest" scope, and that's it (ie: it's function local, or it's variables). If I want to reference the URL scope, I should have to explicitly do so. If I want to be ambiguous about URL and FORM variables (an awful practice initiated by Fusebox), then I should have to DIY that, not have CF do it for me.
Increased support of OOP - retain simplicity
"Good" to the first one. I dunno what they were specifically meaning there, but it can only be good. Maybe abstract classes? Static properties and methods? "Retain simplicity" sounds like Adobe being patronising to its developers, eg "well we're going to do more OO stuff, but don't you worry you five-taggers (is it five or 12? I can never remember), it'll still be easy for you too". F*** 'em I say. They don't need to be specifically catered for. They can stick with their five/12 tags.Tighten interface implementation
More like "fix the bugs in it", I'd say. But who really uses these? I haveCollection datatypes
Hmmm... interesting... I thought they already had those: arrays and structs. I am guessing this is more for our own code, eg: being able to create our own collection classes with CFCs? I must see if this presentation has been recorded and then watch it, so I can get where they're coming from with this stuff.I can see how they could add some functionality to the language to better handle the notion of collections (dev-written CFC implemented ones, I mean), so that's cool.
I shall seek out more details.
New logging framework
Hopefully this is just exposing more of log4j for us. Currently we can writeLog() to a text file, and that's about it. There's quite a lot of other stuff one can do with log4j, which wouldn't be exciting, but would be handy. The ability to easily read the log files would be a start!Create a WAR and deploy anywhere
Again... I'd need some context for this. One can already make a WAR file with ColdFusion, I believe (I've never tried), but I think it either packages up all of CF with it too, or requires CF installed on the target to run or something. Being able to WAR-up just one's code and the requisite subset of CF to execute it would be a win for ColdFusion.Image manipulation revamp
Shrug. Never used CF's existing image functionality. I have nothing to add.Extending the language
This could be quite cool... being able to drop custom tags or functions [somewhere], or import then or something, and then have them work as native tags/functions would be bloody handy. This would work nicely with the package manager to be able to install language extension packs. And could conceivably revolutionise the way we write CFML apps. Depending on what they are planning here, this has huge potential. My old mate Dave McGuigan (you still alive, old son?) will like this: he's been suggesting it for years.Concurrency
There's six individual points under this topic alone, and it all looks like great enhancements to CFML's inner workings:- Existing support - CFTHREAD and CFLOCK
- Synchronized functions and blocks
- Concurrent data structures
- Atomic variables and non blocking IO
- Inherently concurrent - Actor model
But this sort of thing is just the tip of the iceberg. Have a look at the CFConcurrent project that Marc Esher has written, or the whole notion of Concurrency in Java. It's a big topic, and it brings a lot of power.
My conclusion
This is seriously developer-friendly (as opposed to IT-Boss-friendly, like ColdFusion 11 is seeming to be) stuff. It's pretty exciting.The thing is... ColdFusion 11 is still in alpha apparently... it was initially going to be released in 2013, and ColdFusion "12" in 2014, but this is no longer the case. So I guess ColdFusion 11 will be in late Q1 or early Q2 of 2014, and on that basis, it'll be Q2 / Q3 of 2015 at the earliest before we see any of this...
... in ColdFusion. I bet we see a lot of it in Railo trickling in over the next year or so.
It's all exciting stuff, but it's way too soon to get excited about it. That said, there's also a bunch of really good stuff coming in ColdFusion 11, it's just been eclipsed by some of the dross that Adobe think is more important. I think ColdFusion 11 will be pretty good too, but what they're planning for ColdFusion 2016 could be an actual game-changer for ColdFusion, and could have the web industry sit up and pay attention to CFML again. Although if Railo play it right, it might be their flavour of CFML that the industry pays attention to, not Adobe's.
Interesting times.
Sorry to write a fairly vague article about a conference presentation that I was not even at, and to use Tony's photos as a resource. But I was pretty pleased by all this stuff, so wanted to jot down my thoughts. And make a pretty <table> ;-)
Righto...
--
Adam
