I just thought it was too surprising and funny not to post - http://php.org/ appears to be written completely in ColdFusion.

Doh!

In my role leading development shops, I am constantly having to learn and evaluate new programming languages and tools in order to keep us current as well as in order to discover better ways to accomplish goals. As a developer, I am also constantly learning simply because I want to get better at what I do, I love what I do, and learning new languages is a fun and rewarding undertaking. From time to time, someone writes a blog entry or gives a conference presentation about the importance of knowing more than one language... of not being a 'one trick pony'. I was reading Sean Corfield's recent blog post about Clojure and realized that I've never written about my recommendations or opinions of various languages that I've used or evaluated... until now. In no particular order, here are several of the technologies that I know and my thoughts about them:

• Python
  • I've recently been spending a decent amount of time learning and using Python - it's very fast and powerful, and is syntactically one of the most concise and elegant languages I've ever seen... it's VERY readable and the more I use it, the more I like it. Python is definitely one of my favorite languages.
• Java
  • I've used Java off and on since 1995, and somehow keep ending-up having to use it on projects from time to time. The language has gotten larger, faster, and for the most part, better over the past decade and a half - I found the language improvements in Java 5 particularly useful in that they clearly tried to make it easier to do what you want in your code. That said, I don't find Java programming particularly clever or challenging and on many projects I see, deployment is a terribly painful process. Java applications tend to have ridiculous file/directory structures and I'm not a huge fan of how strict it is. Java is everywhere and does have a huge job market, so it's worth knowing for those reasons... but it would never be my first choice of languages to use based on any merits other than the large talent pool and number of open source projects.
• PowerShell
  • Powershell is probably the coolest new thing I've seen in a long time. For those of you unfamiliar with it - it's a fully OO scripting environment for Windows (runs on .NET) and is free from Microsoft. The syntax is slick and simple, and the power you can pack into a single line of code makes it a no-brainer for anyone who needs or wants to administer a Windows network or machine. With powershell, windows finally has a shell that's better and more powerful than those available on nix systems. Bottom line: if you use Windows you REALLY should learn Powershell.
• PHP
  • PHP is yet another free technology - we use PHP and CF for most of our projects, and I like PHP a lot. A long time ago, some people called PHP "poor man's ColdFusion"... well, I think it's more true today than it was back then. It's simple, lightweight, and fast... and development times really aren't much longer than with CFML provided you're not trying to do something that CF does out of the box that there's no PHP module to do. I don't see it having many advantages over CF aside from price, the huge talent pool, and the number of open source projects. There's a good job market for PHP but those jobs don't typically pay as well, so I'd learn it because of it's popularity but I wouldn't choose a career focused exclusively on it.
• Flex/ActionScript
  • I've used Flex since beta 1, and I enjoy seeing how it evolves with each new release. I don't particularly like programming with ActionScript for the same reasons I don't like Java - but unlike Java, I do love the end result you get with Flex... enough to want to do it. No technology to date that's tried to compete with Flash has been compelling enough to use in lieu. There's also a great job market for Flex - especially here in New York City, and it's one of the top 3 or 4 technologies I'd recommend learning to anyone who wants a successful web development career right now.
• ColdFusion
  • I've used CF since the beginning and continue to use it heavily. It's not the best performing technology available but it performs well enough for most needs. No, it's not free, but development/debugging time is rapid enough to easily justify the cost. These days, CF's closed architecture and code base is a real turn-off for me personally, but it's the lack of talent (and the poor quality of most "talent") that is it's only solid turn-off from a business perspective. The native support for Flex is probably its most compelling unique feature... that, and it's rapid development nature. It's a good choice when you want a very robust user-friendly platform in a turn-key solution.
• LISP
  • LISP is, hands down, personally my favorite language. Five or six years ago I set-out to spend 6 months of my free time teaching myself LISP, and I enjoyed it so much that I just never stopped. The syntax took a little getting used to, and emacs takes even longer to get used to - which is probably the most annoying part of learning LISP (I haven't found a better free IDE for LISP yet). LISP is beautiful in the simplicity of its design - most notably in the interchangeable nature of code and data. It is definitely the most expressive and flexible language I've used - as well as the most powerful. Be warned; it takes a while to un-train yourself and learn how to really harness the power of LISP (particularly of macros and, if you're new to it, thinking in functional terms). I also, surprisingly, find the implementation of OOP in LISP (CLOS) much nicer and cleaner than that of any other language. I strongly recommend learning LISP. Not because there's a huge job market for it (there isn't) but because it puts other languages into perspective and because it WILL make you a better developer (I've learned more from 'tinkering' with LISP than any other language).

So, those are the main languages I've played with and developed feelings for recently (within the past 2 years). It's worth noting that there are other languages I left off for brevity. I've also been getting back into JavaScript these days - I have a new appreciation for it's functional nature and closures, and I think JQuery is pretty slick. I've taken a pretty good look at Objective C - it's a decent language but not worth learning unless you want to do a lot of Apple development. I've also played around with Clojure - which is essentially a pseudo-LISP implementation for the JVM - I liked it, but prefer to use 'pure' LISP... though it's attractive being able to write LISPy code that I can run on a JVM, since Java is everywhere. There are a few other languages I haven't had time to take a good enough look at yet but hope to very soon. Specifically, I'm interested in looking at Scala and Caml... and I've begun learning some Haskell and hope to dig into that a little deeper.

I recently wrote (http://www.horwith.com/index.cfm/2010/1/6/can-coldfusion-handle-enterprise-applications about the lack of predictable behavior in CFML - something that I think is a terrible shame and is personally my biggest complaint about the product. I was a little worried that this sentiment isn't being expressed too often or with much vocal strength by many other developers, but was happy to read Alan Williamson's recent post on the topic at http://alan.blog-city.com/cfml_conventional_wisdom.htm. Alan went a step further and created a Google Group for the topic as well.
When defining a language there are two traits to be concerned with: syntax and semantics. I'd like to see an Extended Backus Naur Form (EBNF) definition for the language syntax. This would give developers a reliable syntax specification for the language, engine implementers a specification to code off of and the ability to claim compatibility with an official language version, and IDE developers an easy industry approved method for syntax recognition. Semantics, i.e. the meaning behind the syntax, is more difficult to define and there are several languages for doing so (all essentially based on mathematical notation and logic). I don't know whether we need a formal semantics definition or if a more 'plain English' language specification or hyperspec would suffice. My guess is that a plain English language specification would serve the purpose (similar to the ANSI Specification for Common LISP or SQL).
The issue in any event, is that Adobe owns the most original and most popular ColdFusion Server on the market, so without their support I have to question the usefulness of any specification - syntactic or semantic. Remember how difficult it was to code cross-browser sites in the 90's because Microsoft and others refused to strictly enforce support for the official HTML specification? You ended up having to do all sorts of crazy hacks from browser to browser. Well, that's essentially what's happening, and will continue to happen, to server side CFML unless all the server vendors agree to support some common language definition.
It's time for Adobe to decide whether or not they want ColdFusion to be a platform that rivals the other server-side web technologies not only in capabilities but in popularity, or if they want to continue developing it as a proprietary product with a niche following. They do a fine job innovating the product and integrating it well with Adobe (and other) technologies, but in today's IT world I don't think that's enough. If the community of developers and customers is to significantly grow and thrive, the evolution of the platform must be driven by an open group. This model worked for Java and for PHP... and I believe it is the key to ColdFusion's ensured success for many years to come. I'm not suggesting Adobe gives the server away, nor that they couldn't add proprietary extensions in order to give themselves competitive edge (as I'm sure other vendors also would), only that the product should be one of a group of products from various vendors who are all adhering to one specification and who support a unified customer base. I know that, especially for Adobe, it's just not that easy... but it's also not impossible. I'd love to see someone from Adobe chime in on this topic.

A little over a year ago I blogged about the complete unavailability of ColdFusion books in bookstores in India (http://www.horwith.com/index.cfm/2009/1/16/namaste-coldfusion). I am writing again from my annual pilgrimage to 'Mama Hindustan' and thought I'd follow-up and see how the market has changed. I believe that the availablity of books about a particular programming language is a reasonably good reflection of the popularity and job market in a region, though I don't know of any real data that backs-up that claim.

One year later, the number of book stores in Delhi is about the same, but there are a greater number of much larger book stores (similar to Borders and Barnes and Noble in the U.S.) and the size of the 'computer' section in these book stores is much larger than last year. A few of them are comparable in size to the computer section in a large bookstore in the U.S. That said, I could not find a single copy of any book about ColdFusion. I found this a little surprising for three reasons:

1. I'm under the impression that there's a decent job market for CF developers in India.
2. These computer sections didn't only carry books about very common technologies - I found books about pretty much every language, theory, and computer-related topic I could think of - including very obscure and outdated technologies.
3. One large bookstore even had an entire 'Adobe' subcategory (made up of 6 large shelves of books) in their computer section

Whether or not CF has a job market here, it is clearly much less popular than in the other countries I've visited. If I had to generalize about what technologies are the most popular (and most available) in book stores, it would be (in order):

1. Java
2. .NET
3. PHP
4. Flash/ActionScript

I'm sure most people, like myself, don't find this very surprising. Also worth noting is that the most significant difference between the computer book inventory this year vs. last year - hands-down there is a significant increase in and dominance of PHP books. One other thing I noticed, which did surprise me a little, was that there are far more Oracle books than SQL Server books on the shelves... I'm not sure why, but I expected the opposite.

There are a few common reasons given whenever a company says they don't want to use ColdFusion or a developer says "Oh, ColdFusion isn't a REAL programming language". One of these claims is that ColdFusion can't handle large scale enterprise applications. The majority of ColdFusion developers, especially the fanboys, immediately take offense and dive into a passionate discourse on the merits of ColdFusion, blah, blah, blah. I've done my fare share of CF-Evangelism over the years, and I do still believe that the merits of the platform make it a great solution a lot of the time... but I'm much more technology-agnostic these days than I was in my youth, and as I fall in love with other languages because of their merits, I find myself reflecting and sometimes re-evaluating my feelings about ColdFusion. In this entry I'd like to share my thoughts about CF: the good and bad, some advice for developers and companies, and some stories about recent real-world experiences I've had.

The Good
There are some things that make ColdFusion a terrific platform. Deployment is a breeze compared to most other programming languages. CFML is not a perfect language, but it is a simple language that makes most programming tasks easy to tackle. This tends to make rapid development easier to accomplish and lends itself particularly well to iterative, agile development practices and all that comes with it (like refactoring). This, coupled with the server error reporting and a few programming language constructs, also means that debugging ColdFusion applications is relatively painless and quick compared to other languages. Speaking directly to the questions of performance and scalability, it is possible to write applications that perform very well and scale exceptionally well with ColdFusion. For example, we (at Nylon Technology) recently successfully developed and deployed a large scale content management system across multiple servers and server instances. This CMS manages gigabytes of content (tens of thousands of pages) and has a lot of remarkable features (workflows, a robust permissions based security API, etc.).

The Bad
There are a few negatives about ColdFusion that should not be ignored. ColdFusion and CFML's ease of use means that you don't have to be a rocket scientist to use it. As I said, this is a strength, but it is also a weakness. There are far too many poorly developed CF applications "in the wild" and far too many "ColdFusion Developers" aren't good "Software Developers". I'm not saying all developers should have a degree in computer science, but more CF Developers should have a better understanding of the ramifications of the code they write, the limitations of the environment they're writing software in, and how to design ("architect") and develop applications that are not just modular, but easy to read, maintain, and extend. Sub-par programmers and poorly written applications will give any programming language a bad reputation. Coupled with the relatively small pool of available talent, it's no wonder some companies want to shy away from ColdFusion, is it?
So let's assume that good developers do create a well-written Enterprise ColdFusion application and have tweaked the hardware and JVM so that they know those won't factor-in as negatives - will it scale and perform well? The three second answer is "maybe... it might and it might not".
The Adobe ColdFusion Application Server is a commercial product and, as such, is a "black box". You write your code and save it somewhere that CF can see, and it "does it's magic" and spits out the results. If you don't like the results, you can change your code and try again, but you can't change what's inside that black box (i.e. the server internals). The most you can do is optimize the Application Server (CF and J2EE) and runtime (JVM) but not the way the server actually works with your code. This is obviously a problem if it turns out that some built-in ColdFusion function or tag is what's killing performance.
Though our client is happy with the CMS I mentioned earlier, along the way we did encounter several (performance related) stumbling blocks that were not the fault of the hardware or software architecture, but ColdFusion itself. One of the things that the CMS does is work with Objects (CFCs) a lot - and constructing/populating thousands of objects comes at a price. The CMS has a caching architecture that in simple terms boils down to storing CFC instances in a structure, using the ID of the content as the key name. We found that as the number of objects in memory grew, performance crept to a complete stand still - the server eventually died, as more and more threads timed out waiting for the threads that were accessing the structure keys to complete their job. Turns out that not caching the instances was the fix - but why? Because of a bug in ColdFusion that as far as I know, was first reported by David Sheldon on his blog at http://cfdumped.blogspot.com/2006/09/bad-hash-function-causes-problems-with.html. Maybe this bug doesn't affect the majority of applications, but for applications that need to store a large number of values in a complex data type, structures are not an option. One of the few fundamental data types in CF is broken - that's a big deal. I believe this issue was addressed in a CFMX 8.01 hotfix this year, but I haven't confirmed... and I personally think it's unacceptable for that bug to be made public knowledge and not be fixed for 2+ years.
We recently had another performance related issue with the application. The unique IDs of search results from a SQL statement are stored in a string and that string of IDs persisted and used for pagination. This is necessary because re-running the query isn't an option and storing the entire recordset would use far too much memory. So, the approach is right... but performance is abysmal (to the point that internal server errors are thrown) when lists get large - sometimes they're as large as 150,000+ (remember, this is an enterprise application and we need to work with huge volumes of data). The code that kept crashing looked something like this:
OK, so you're thinking, "Remove the listLen() call from the loop condition" - right? We did, and it got a little better but would still time out sometimes and would be very slow other times. That code looks like:
Turns out that listGetAt() is just a horribly inefficient beast. Temporarily replacing the list with an array and then accessing indeces in the array worked like a charm and made an exponential difference to performance:

The example of listLen() brings up a good question - is there something wrong with that code or is it fair to say that ColdFusion is to blame? Rather than answering directly, I'll describe how I view the roles and responsibilities of CFML and the (ColdFusion) server, as well as my own complaints/disappointments with each. We'll start with the language - CFML. The CFML programming language is not the problem - in fact I think it's a good language (note that by "CFML" I mean "CFML and CFSCRIPT"). When I first heard about the CFML advisory panel, though skeptical, I did think it was a good idea - I still do. However, what I believe we truly need is a real language specification - one that states how the built-in tags and functions are to be implemented. Of course, since Adobe owns the server, though they've put together an advisory board, they have not published the language as a public specification. I would be pleasantly surprised if they did. There are several good examples of how a language specification is implemented and of the benefits that come from a public spec. One example is ANSI SQL - if a vendor says they support it, you are assured that your SQL will work. Another good example is ANSI Common LISP - the specification states exactly what (and in many cases how) vendors must implement the language. If you write your applications in Common LISP, you know exactly what to expect from implementation to implementation. Unlike CFML, for which a public specification could easily be made, the ColdFusion Server is a product owned by an entity and it wouldn't be fair (or make sense) to publish a standard defining how to write the server. Perhaps there is a solution, though. At a high level, the server is responsible for serving two primary functions: it is a compiler and it is a runtime platform. Perhaps it does not make sense to have an open standard that states how the runtime must work internally (beyond a specification for the side effects and behavior of the CFML language constructs), but a specification for how the server works as a compiler, if expressed at the language construct level and as part of a CFML specification, is plausible. For example, in my first list code snippet I pointed out that the listLen() in the for loop condition (for(j = 1;j lte listLen(daList);j++)) was causing a serious performance problem because it's evaluating on every pass... but there's no reason that the server, when compiling that CFML, couldn't have introspected the contents of the loop and determined that it was safe to compile it as byte code that evaluates a number (instead of the actual expression) on each pass. "Compiler Optimization" is something I've learned a lot about in my continuing education and experimentation with LISP - and it's something that the Adobe Engineering team should be focused on. I'm not saying they aren't (I really don't know) - I know they do focus on making the internal server code faster (the actual tags/functions) and the compilation process faster, but I do not know if they look at ways to optimize the actual results of the compilation process (rather than the code those results executes). A language specification that defines the compiler behavior for some, if not all, of the language would be a huge benefit to all.

The bottom line is that in the Enterprise, ColdFusion absolutely can perform and scale very well - but that no matter how great the hardware, how tweaked the VM and servers, and no matter how well written and well architected the code base, a very resource intensive application may perform poorly for no reason other than what can only be nicely described as "quirks in the server".

A while ago I posted several common sorting and searching algorithms implemented in CFML (http://www.horwith.com/index.cfm/2009/7/10/coldFusion-searching-and-sorting-algorithms). The code, documentation, blog entry, etc. were all written over the course of a couple of months during my 45 minute commute to and from work on the New York City Subway. As a side note - it's very interesting some of the conversations people strike-up with you when you write code on the subway. Now that I finished that, you may be wondering what my next "subway project" is? I'm writing a framework.

Yes, that's right - "a framework". I'm sure people will have a few questions - the framework is still in it's early stages so I don't want to say too much. That said, I've tried to address some of the questions that people might have about the project and/or its objectives:

• Question: Why a framework?
• I hate to call it a framework to be honest - frameworks tend to centralize control of your application whereas what I'm working on simplifies architecture without actually telling you how to glue the pieces of your project together. That said, theoretically this code base could be used as a framework that glues an entire application together, so I decided to use the "f" word.
• Question: What are the objectives of this framework?
• There are a few very specific objectives of this framework. The first objective, and reason I wrote it, is to encourage and allow CF developers to take a more functional approach to programming ('functional' in the 'functional programming' sense). There are three business needs that this framework addresses - it will have a short and easy learning curve, functionality expressed with it should be easy to test, and functionality built with it should be easy to maintain. In addition, the framework must be lightweight and fast, and it must be non-obtrusive. You must be able to drop this code into any application and use it as much or as little as you want without penalty. A more technical description of the main objective is to simplify the architecture of applications by encouraging use of 'pure' (no side-effect) functions and, if desired, an OO aproach based on using objects only to represent the business domain (data). This is realized by centralized function library management and a few encouraged practices (all documented, of course).
• Question: Why functional programming?
• The more I play with functional languages and try to build applications in a functional way, the more I appreciate the benefits attained by doing so. I've seen many projects go south and many developers produce poor product simply because the company, tech lead, and/or developer try to do everything according to the notion that Object Oriented Programming is "the best and only way". Often times they also don't even fully understand OO, which makes matters worse. Though the framework encourages a functional approach, OOP has some good qualities and I've tried to also encourage using those qualities in order to simplify the process of designing and building applications. Before any functional purists speak out, I should state for the record that this framework only attempts to offer some of the benefits of functional programming that have been enjoyed by some developers for 50+ years... ColdFusion is an imperative language, CFML is not equipped to offer true functional features, and I cannot change the way the server works under the hood.
• Question: Is there a feature list for the framework?
• There are some specific technical features and tools I have, or am, implementing - this list won't change (it could grow) but I may not necessarily push it live with everything complete. The feature list, in no particular order, is:
  • Mount function libraries which can then be called as if they were defined locally
  • Mount individual functions from libraries
  • Dynamically load libraries or functions for use
  • Allow global functions to be overridden by more local (session and request level) functions
  • Allow functions to be dynamically defined (and loaded for use)
  • Ability to chain function calls and to call function chains
  • Ability to define failover method for function/chain calls
  • Simplified domain object use by using a generic DTO base class
  • Simplify library and DTO creation via a lightweight object factory
  • Simplify testing with a simple unit testing tool
• Question: What version(s) of ColdFusion will this framework support?
• I'm writing the framework to run on CF 8 and above. There are a few language features in CF 9 that would make a couple things easier for me or faster for you, but the trade off isn't worth it.
• Question: What will the framework be called?
• I don't know - names aren't my thing. It's just some code I'm throwing out there. That said, I have to call it something (internally in the code if nowhere else) so for now it's "Framework F". No, not "F" for "functional"... the idea for this framework came to me while I was riding an F Train one morning.
• Question: What will the framework cost?
• As with everything else I code for fun and post on my blog - this code is costs nothing. I don't know if I'll release it with any license or put it anywhere special besides a link to it here on my blog. I also don't know if I'll maintain it or add to it ever. I'm writing it for my own professional use, so as I need to modify it I will, and if I do something I think others would find useful by all means I'll post an update. Otherwise, if people use it and like it and someone wants to take "ownership" of it, or simply use and abuse it in whatever way they choose, they're welcome to. I don't like the "black box" aspect of frameworks, and I have deliberately gone out of my way to make the code base for this framework as short and simple as possible so that people can reach in and pull out its guts and play.

I don't have a date in mind yet as far as when it will be done - I'm working on several side projects for fun, reading several books, and working on "real work" for clients all at once... but I'm trying to squeeze-in time for this project whenever I can. I wrote the core several months ago and then put it down for several months, but I am going to try and get back to finishing it off soon. Sean Corfield has graciously agreed to look at it, do some testing, and provide feedback as soon as I have it ready for him - I asked Sean to do the initial review because he not only has CF Expertise and Framework experience; he also has experience/knowledge of functional programming languages and functional programming as an approach. Anyone interested in gaining early access to the code base before I'm ready to release it to the wild should email me at simon at horwith dot com or shorwith at nylontechnology dot com. As I said above, I'm writing this my my own real world use, and I have no intention of making it publicly available until I've used it enough to know that the kinks are worked out, that it's useful, and that it's documented well enough.

If you're a Flex developer in New York and don't know about it yet, there's a 2 day Flex Conference called 'Flex Camp Wall Street' (http://flexcampwallstreet.com/) on November 16 and 17 that at $49 to attend, looks like a great deal for attendees (what else can you do in New York for less than $50??)

I'll be presenting on ColdFusion/Flex integration at the conference on Monday.

Fig Leaf Software (http://www.figleaf.com, an award winning Adobe Training Partner, is taking their training online - they're offering free training via the web for several Adobe products. Nice job, guys!
You can register and find out more at: http://training.figleaf.com/tutorials/

One of our staging environments is running CF 8 multi-server and has instances running CF 8.01 and instances running CF 7 - all running on 32 bit Windows Server 2003. If you look at the system reqs for ColdFusion (http://www.adobe.com/products/coldfusion/systemreqs/#coldfusion) on 32 bit windows, JDK 1.4.2_14, 1.5_13, and 1.6_04 are supported. If you want to run all instances on one JDK, using JDK 1.4.2_14 makes the most sense, as CF 7 does not support JDK 1.5 or 1.6.

After applying CF 8.01 Cumulative Hotfix 3 (http://kb2.adobe.com/cps/511/cpsid_51180.html) to a CF 8.01 server instance, the instance appears to start, but any requests for CF pages that you make result in a 500 error with the following description: "coldfusion.server.ServiceFactory$ServiceNotAvailableException: The Security service is not available.". Switching to the JVM that installs by default with CF 8 makes the error go away.

Unfortunately, the hotfix tech note does not currently mention that it breaks the CF 8 compatibility with JDK 1.4.2_14 and the system reqs doc still states that CF 8 supports this JDK. The CF 8.01 cumulative hotfix 2 did not break this JDK compatibility. My advice to anyone thinking of upgrading to CF 8.01 Cumulative HF 3 is to first confirm that the server instance(s) you plan to update are at least running on JDK 1.5_x or above.

Adobe could be the next Microsoft... and that's not necessarily a compliment. Today, ZDNet News published an article titled "Is Adobe the next (pre-2002) Microsoft?" in which they compare the rising number of security holes being found and exploited in Adobe Flash Player and Adobe Acrobat Reader with the problem Microsoft had with vulnerabilities being exploited in their products years ago. It was so bad that among many circles, suggesting Microsoft products as a solution to whatever requirements you needed to meet was grounds for public humiliation. Their products were known targets and it was understood by many that using certain MS software was risky. No software is really 100% safe, but Microsoft took it seriously and became very proactive about addressing the (technical and image) issue both internally before software is released and publicly when a vulnerability is found. The article does give Adobe credit for being proactive and doing a reasonable job addressing vulnerabilities when they're found, but doesn't hide an opinion that Adobe still has a way to go.

The ZDNet article is online at http://news.zdnet.com/2100-9595_22-329118.html