What it's like switching from ColdFusion to C#
posted under category: dotnet on August 28, 2017 by Nathan
I like to be the smartest person in a room. I've perfected my expertise in CF development over the past 19 years, and I'm really good at it, but with technology marching on, I've found myself switching to C# .NET and Windows UWP app development. To say the least, things are different!
This is going to be sort of stream-of-consciousness, free-flowing thought. Brace yourself.
ColdFusion does a lot of things for you that just don't happen easily in .NET. CFSpreadsheet, for one, is something that's not accounted for at all, and a real detriment to my bottom line as far as getting things done for my customers. CFDocument and CFPDF are likewise completely absent, as is our beloved CFSearch. Many other things made simple in ColdFusion are just much more complex and require a lot more code and understanding in .NET, like caching, sending email, ORM, web services, and much more.
Everything in Dot Net land has a nearly-catchy name, and frankly, that's frustrating when you don't know what all their names mean. Entity is the ORM, fine, but Kestrel the web server is odd. Then there's the barrage of web frameworks: ASP.NET WebForms, ASP.NET MVC, the Razor template engine, ASP.NET Web Pages, and Razor Pages. Then the desktop family, WinForms, XAML, WPF, and UWP. That scratches the surface, but barely. Maybe my challenge is because many of the names are so similar, like .NET Framework vs .NET Core.
It's not even the object-oriented design that makes things difficult, either. While many of my CF colleagues are happy with procedural web applications, I've had my hands full with OOP in ColdFusion for 15 years, but I was pretty strictly modeling business domain objects and MVC pattern objects, whereas in .NET, I have a lot more low-level objects just to accomplish many of the same goals.
The C# language really is first class. It's been designed very well. Some of the more advanced features are still beyond me. There are a lot of things I can read, but not yet write, much like my Spanish skills. Have you ever tried reading a magazine or newspaper written in Spanish? Oh, I highly recommend it just to get some practice in language parsing. Thanks to our Latin roots, it isn't too hard to work through some, until you came to a word that just doesn't match, like "gatos." Is this article about alligators? No, it's about cats. It just takes time to learn all the specifics before you really understand what's going on.
PascalCase has been an annoying adjustment, but it's well thought out and the style guide is pretty clear. On the other hand, naming things on this new platform is especially hard. Is it a gateway or a repository? Everybody keeps trying to call things a "Helper", like the "SettingsHelper" in the Xaml Template 10 library, and I keep explaining to everyone in the office that a "helper" is not a type of object in an object-oriented system. Neither is a sender, receiver, or really most verbs or words that end in "-er." Some of this is my personal struggle with teaching programmers on my team and fighting against bad practices used in popular public frameworks, but much of it is really about coming up with the best name for a thing, because there are so many more things you have to code in C#.
Some of my difficulty is transferring out of my Java thinking into .NET thinking. I was never a big Java guy, and I never wrote anything more than a few sample apps and a couple utilities, but the Java language thinking is ingrained pretty deeply in my head. I'll get through most of it after a while, right?
I've had to completely re-learn debugging. Much of that is because of my incidental transition away from web development. There's so much more code in C# just to do the same thing, and so many things go wrong. Even with breakpoints, sometimes my app just skips from one operation to the exit and doesn't give me any hints as to why. Then I call over literally anyone for help and they find and solve my problem within 30 seconds. It's been humbling.
This isn't to say that everything on the .NET platform is bad. Quite the contrary. I am having a lot of fun enjoying a wider world of programming! I feel like it's both burning me out and giving me a reason to go on even harder. The ability to run a compiler and pop out an exe file is fun. Using properties instead of accessors & mutators (get & set) is nice, though that one is available in modern CFML. I like how .NET runs a good amount faster than Adobe's CF. I also feel like I really understand the draw toward statically typed languages, though I can't say that I prefer it yet, given the magical world of JavaScript I dream about.
Something tricky to figure out has been the async/await syntax and how that works, how it cascades through an application, and thinking through the problems it can create when we don't always know if tasks are working concurrently. That's actually been a fun challenge, and I feel like it's a preview into ECMAScript 2017.
I'm not a fan of the way much of our interaction with the framework is through public static methods. This is both ineloquent, for instance in comparing java.io.File to System.IO.File, and also creates confusion with developers. In this case, Java's File is something you instantiate with a path, and .Net's File is static methods you call with a path. Is a File an object, or a string path to the object? Are we supposed to design our APIs with public static methods and classes, or as composable objects? I'm internally conflicted on the whole thing, and I keep going back and forth on designs in my head.
And then there's MVVM. Oh boy, that's going to be a topic for another day.
There's a lot more to it, and I have more to say, so stay tuned.