Since I just got a new MacBook Pro and was having to go through setting everything up for ColdFusion development, I thought I’d document what I install both for my own future benefit as well as (hopefully) the benefit of others. Enjoy!
If you pay attention to the ColdFusion blogs at all, or if you were at CFUnited, you’re well aware of the new-found duck typing craze in ColdFusion land. While I agree with some of the sentiments behind advocating duck typing, as with most things that become a veritable feeding frenzy, there’s quite a bit being lost in the insanity in my opinion.
First and foremost, just because you can do something doesn’t mean you should. Let me state that again and extend it a bit. Just because you can do something doesn’t mean you should, and it certainly doesn’t mean it’s appropriate to do it all the time. My fear with all the blog postings I’ve been reading the past few days is that people will take on an attitude along the lines of, “Typing? Who needs it! This is ColdFusion!” Personally I think that’s exactly the wrong approach.
Let’s stop and think about why typing exists in strongly typed languages such as Java. Yes, I know ColdFusion isn’t Java, but kindly stick with me for a moment. Typing exists in Java for numerous reasons, not the least of which is that type checking makes for safer software. Why? Because in Java if you’re doing something wrong, either on purpose or inadvertently, the compiler won’t let you get away with it. If an object’s expecting a Person to be passed in as an argument and you try to pass it a ShoppingCart, that simply isn’t going to fly. No worries about weird runtime errors based on typing because you can’t even get that far. From my years as a Java programmer I’ll say this much: once you get the darn thing compiled, you’ve won well more than half the battle. Java feels solid precisely because of this aspect of the language, and many other languages both before and after are strongly typed for many of these same reasons.
Is dealing with strong typing a bit of a headache? Sure, particularly when you’re in a situation where duck typing is actually necessary. Re-read that last part. “… where duck typing is actually necessary.” Now given the fact that there isn’t, strictly speaking, a way to even do duck typing in Java, and there are plenty of Java applications out there running just fine without it, “necessary” might be a bit strong in this case. So let’s downgrade that to “… where duck typing sure would come in darn handy and I’m doing it because I know what I’m doing and actually mean to remove type-checking and all the benefits that go with it.” One of the ways Java addresses cases in which duck typing would come in handy is to use interfaces, which–and the discussion of interfaces is a topic for another blog post altogether–ColdFusion doesn’t have. (As an aside, BlueDragon 7 adds a cfinterface tag, and it was rumored at cf.objective() that CF 8 may add interfaces as well.)
Now back to ColdFusion. As many have pointed out over the past few days, ColdFusion is not Java. Fair enough. What I take issue with is the extension some folks seem to be applying to this statement. Specifically I find statements such as “ColdFusion isn’t Java, so don’t worry about typing at all” extremely problematic. ESPECIALLY if people are new to OO and they’re bypassing the proper learning of OO and jumping straight to going typeless everywhere in all their applications, this is utter madness.
Granted, because all the type checking in ColdFusion is done at runtime, we don’t get the same compile-time checking that Java developers enjoy. (Take “enjoy” with a grain of salt there; the Java compiler is a rigid taskmaster yet we are forced to seek its approval and are generally elated when we receive such approval via a successful compilation.) That doesn’t, however, completely negate the value of typing in ColdFusion.
First let’s think about the development process. ColdFusion checks type at runtime, but during development, when you change a file and fire things off again, behind the scenes things are getting compiled and subsequently they are immediately executed. So this is really a compilation step with automatic execution thereafter. Not so different. If you’re passing something an object of a type it’s not expecting, ColdFusion throws an error. During development you may absolutely want this to happen, and it can save you some headaches because you get no further than CF saying, “Hey pal, wrong object type. Try again.” This can be great for debugging purposes.
Next, let’s think about deploying an application to production. Do you care about typing once the application is complete, has been thoroughly debugged, and you’re absolutely, positively sure everything’s going to work correctly? Probably not. You don’t really care about it at that point in Java either. Once all the bugs have been ironed out you know the correct types are being passed, so conceptually at least, it probably no longer matters. Of course there are special cases where it might matter, such as if you’re writing an API and people interact with your API by throwing objects at it, a good old-fashioned “wrong object type” error might be better than something that could be much harder to debug.
The other advantage of duck typing people seem to be going nuts over is performance. In Java, type checking is done at compile time so even if you could do straight duck typing in Java, there’s no performance benefit. In ColdFusion on the other hand, type checking is done at runtime, meaning this is an additional step ColdFusion has to perform. No huge surprise then that if you don’t make ColdFusion perform this additional step, things are going to be faster. How much faster? Depends on the application. My real concern here is performance gains … at what cost? Duck typing for the sake of performance should only be done in very specialized circumstances, and I’ll probably have more to say on this point soon.
Before I ramble further, I’ll cut to the chase and summarize by saying that duck typing is darn handy when you need it, but eliminating typing altogether because it’s the new, hip thing to do, or because you think it’s the top-secret weapon that will make your CF apps lightning fast, is a big, big mistake. If you listen to ColdFusion Weekly you’ll probably recall the call we had a couple of weeks ago asking for our thoughts on the Hal Helms and Jeff Peters Out Loud episode where they discussed “GroupThink.” Duck typing is another case in point in my mind. Please, please, please, for the love of the OO gods, think about what you’re doing when it comes to duck typing. Don’t skip typing because all the cool kids are doing it.
So where do I think this is all going? I hope that we’re in another Hegelian phase of our collective development knowledge. Thesis: ColdFusion has a type attribute now, so use it. Antithesis: forget typing–duck typing all the way. Synthesis: use duck typing only when you need it. We’re currently still in the antithesis phase which is why I thought it was a good time to do my own personal brain dump on this topic.
I’ll conclude with a few bullet points that you can use as food for thought.
That’s all my quacking (har har har) on duck typing for now.
Another interesting possibility about the future of scripting languages comes in the form of Java Specification Request (JSR) 223, which describes the goal of allowing better interactivity between Java and scripting languages. Some relevant quotes from the JSR:
“This specification will introduce the basic technical background to bridge the scripting and the Java community. The specification is concerned with how to write and package Java classes that will be accessible from different scripting engines.” “This specification will describe how it is possible to bundle scripting pages into a WAR file, either stand-alone, or as part of an EAR. The specification will describe the different implications for security, resource, and class loader contexts both in the case of stand-alone WARs and as part of an EAR. The EG will also consider whether it is appropriate to deliver scripting and Java code outside of a WAR.” Sound familiar? ColdFusion is ahead of the curve once again, and since Macromedia is an official sponsor of the JSR they’ll have a hand in defining how this all plays out. This is interesting to me for several reasons, not the least of which being that the ColdFusion community, between Macromedia ColdFusion and New Atlanta’s BlueDragon, is once again ahead of the curve on things. It’s been possible to deploy ColdFusion apps on J2EE servers since the release of CFMX (and this got much better in CFMX 7), and with BlueDragon you can deploy CF apps on J2EE or .NET. Apparently other folks think this is a great idea, and the reference implementation of JSR 223 may include PHP as the example of how this is done. The other thing I can’t help but think is that this is the Java community’s response to the .NET CLR’s ability to run multiple languages. If Microsoft got anything right with the .NET architecture, this was definitely it. Giving people a choice of languages that all run on the same platform offers fantastic flexibility, and if this becomes the norm in the Java community, CF will have been way ahead of the game. I’m going to keep my eye on this JSR!Interesting article concerning the rise of popularity of scripting languages, specifically PHP. Given the recent announcement from IBM and now Oracle for support of PHP this makes for an interesting trend. The article focuses specifically on PHP, Python, Perl (the so-called “P Languages”), and also Ruby, but the points concerning power, ease of use, and speed of development of course apply to ColdFusion as well.
Interesting quote: “… more and more businesses and IT professionals are looking to these languages as a way to simplify and speed the creation of custom in-house programs, thus avoiding the now all-too-common logjam of late or overbudget applications.” Again, looks like the arguments we CF devotees have been making all along are right, it just takes the rest of the world a bit to catch up.I heard about this story on NPR today and followed up on the source’s web site, which is the Journal of the American Medical Association. To summarize very briefly, many hospitals now use a system called the “Computerized Physician Order Entry System” (CPOE) for patient prescription input. After a study they found the system’s workflows and UI were so poorly designed that at best they’re inefficient, and at worst they can cause serious problems. In one of the interviews on NPR today the gentleman being interviewed said that if, for example, you wanted to take a patient from an 8-per-day dosage of something down to 4-per-day, you had to enter the new dosage first, and then cancel the old dosage. If you just enter the new dosage and something happens or you get pulled away, then suddenly that patient’s getting a 12-per-day dosage. Yikes!
I just thought it was interesting because while we all of course strive to build systems that are user-friendly on the front-end and robust on the backend, in cases like this a poorly designed system can cause serious problems. Even though the systems many of us develop might not be this mission-critical, it’s a good case study in what not to do when we build applications.
I just realized that with everything going on I haven’t updated the blog in a LONG time, so I’ll just do a rapid-fire list of what’s been happening the last month or so. Lots of various contract gigs coming in, I’m finishing up class #7 on my MSCIS degree at the University of Phoenix (this puts me officially one class past the half-way point!), and next week I’m at i2 Planet, i2’s annual supply chain software conference. Specifically concerning my outside gigs I’ve been doing lately, in combination with my project management course I’m finishing up, I thought this made for a good opportunity to discuss bad project management.
On the programming side of my world, I’ve actually been finishing up some “Classic ASP” projects, which annoys me to no end. I don’t mind the extra work, but I really, really, really despise Classic ASP for a host of reasons. There’s still demand out there for it and since it’s all I did for a couple of years, I still know my way around it fairly well. I hope to steer clear of it before long, particularly since Microsoft has more or less abandoned it at this point. If nothing else working with ASP again has made me appreciate ColdFusion all that much more.
The project I completed most recently (URL withheld to protect the innocent) was a complete nightmare from start to finish, and it was interesting that I was in a project management course during this project, because practically every one of the “classic mistakes” we discussed and read about in this course were part and parcel of this project. I also want to recommend a fantastic book I just finished that I think ALL project managers involved with IT projects should read: Steve McConnell’s “Rapid Development”. From the title it might sound like this is a book for developers, which it is although there isn’t a single line of code in the book, but it’s equally as valuable for IT PMs.
After thinking and reading about project management in great detail for 6 weeks now, I can honestly say that the vast majority of PMs I’ve worked with simply don’t know what they’re doing, so it’s no real surprise so many projects are such a disaster. People should not just be thrown into the PM role. To do it well takes a host of seemingly disparate skills, not the least of which is a decent knowledge of how application development works, which is SERIOUSLY lacking in the case of many PMs I’ve worked with. I’m not saying PMs have to be expert programmers to be good PMs, but they darn well better know enough about development to know what goes on and MOST importantly to ask questions when they aren’t sure about something. One too many times during the project I mentioned above promises were made to the client, budgets were set, and THEN the developers were told about all of this. Sorry, but when the PM doesn’t know anything about development, they shouldn’t be promising the client anything until they consult with the developers first.
Sorry if this sounds like a rant, but between that project and another one that has dragged on for OVER A YEAR (this is something that my original proposal slated to take 90 days), I just think there is so much wrong with IT projects that many of the people involved should be ashamed of themselves. This hits on another one of my pet peeves, namely people who don’t care about their jobs enough to do them well. This may come off as sounding very arrogant, but I just have very little tolerance for people who are ostensibly professionals at what they do, but are extremely bad at it and do nothing whatsoever to improve their skills. To get back to the PM example, if someone gets thrown unexpectedly into the role of PM on an IT project, that may not be their fault, but if they don’t have the skills to do the job well, then it’s their responsibility to ramp up and learn as much as they can as quickly as possible. Otherwise the project *will* fail.
Maybe that’s the programmer in me talking, but I honestly think the principles are the same regardless of what field you’re in. If I get hit with a job that uses a technology I don’t know, you can darn well bet I’ll be feverishly learning everything I can about it so I can do the job at least competently. If people aren’t willing to put in the extra time to ramp up on things, become moderately competent as quickly as possible, and commit to improving their skills continually, then they shouldn’t accept the job. In the case of far too many PMs I’ve worked with they don’t know how to manage an IT project and they refuse to learn. Sorry, but if that’s your attitude find a different job, because all you’re doing is making the lives of everyone on the project team miserable and dooming all your projects to certain failure.
End of rant.