I think that as time goes on, programmers, coders, and hackers tend to get stuck in their ways. Listening to friends and I go on about the latest fad and how horrible it is outlines that fact, and my recent trip to a Perl
conferencesolidifies it. In my high school days, I liked to write in three different languages, with varying levels of success -- Visual Basic, C, and Perl. VB was for playing with Windows apps, C was for hacking around with my BBS and attempting to do Mac development, and Perl was for the web. I didn't do a great job of coding at any of the three languages, as I lacked any formal training. They did get the job done, and I had a lot of fun doing it. Once I was employed as a Perl programmer, I effectively re-learned the language, and have been working primarily with Perl ever since. A few of the jobs have afforded me the opportunity to work with other languages, some C and REALbasic at one, some C# at another, PHP and Python at a different one. None of them became my primary languages. Most fell off my radar after I stopped being required to work with them.
A few years ago, I started to become anywhere from dissatisifed to annoyed with Perl, and started a search for my "next language", something I could enjoy programming in as much as I enjoyed Perl. I played with Python for some time, and I also checked out Ruby with the Rails web framework. I knew about PHP enough that I didn't care to deal with it any more than I had to. I actually got a kick out of Python, but lacked any real world application for it to really do something more substantial. I may still head that direction.
, and later Moose
started really building up, I started doing more work in Perl again. Moose made OO programming in Perl not only sane, but actually enjoyable. The Catalyst framework made web development structured, easy to deal with, but powerful to work with and quick to deploy. It was hard to go wrong, and I've been on that path since. My only real deviation was finally getting the chance to really learn Java beyond the theoretical by starting with Android development
, and releasing my first Android application, ElJay
In a sick sort of way, Java really clicked for me. Sure, it takes 10x the lines of code to do the same thing as I'd do elsewhere, but the great threading architecture and the strict typing really turned my crank. Unfortunately, writing Java applications generally
means that your app is slow and ugly on every platform, instead of at least having one good one. Android, at least, provides an obvious foundation for Java applications, screwing up that rule.
My latest round of experiments have been using Objective-C
. The most common application of that language is as the primary language of Mac OS X and iPhone, using Apple's Cocoa framework
. I've been hanging out mostly in the basic CoreFoundation framework using command line tasks, and really enjoying the message sending features, obvious and straightforward OO implementation, and the raw speed of a natively compiled application. My 'big project' is investigating how realistic writing a web application framework in Objective-C would be. How 'realistic' it is can be a challenge to define, but I see it as a few separate things.
* How easy is it to generate a basic framework, similar to the core of Catalyst, that can respond to FastCGI requests quickly?
* How easy is it to extend it to multiple engines, and the opportunity to plug in other models and views?
* How easy is it for the end developer to then write an application against this framework?
* How many developers would be willing to write web applications in a strict typed environment?
I've managed to get through the first and half of the second bulletpoints. I now have a loadable framework that can be plugged into an application that allows basic dispatching of pathnames to a controller via FastCGI, plugged into Apache. The FastCGI component is actually loaded as an engine, and a basic CGI engine is also available. Engines are an abstract class that acts as a simple API, and one could theoretically
write ISAPI or other types of connection engines into it. Models and views are not done yet, the controller is just spitting out HTML. I know, I know, that's a big no-no. That comes soon.
Numbers three and four are a little fuzzier. If I take the idea that a lot of newer developers are easily able to create new applications for the iPhone, one would say that Objective-C is not a terribly difficult language to pick up. In fact, the hard piece of just about any language is not the language itself but the framework. Java is easy. Android makes it tougher. Objective-C is easy. Cocoa makes it tougher. In that same vein, a developer may be willing to write a web app in ObjC as long as the framework itself makes it easy for them to do so. If I also add the idea that enterprise developers are now writing web applications in Java and C#, I can't see a reason that another strictly typed language would be an issue. I think the main issue that would need to be overcome is making it easy for people to add new components to the system. Perl has CPAN, Ruby has Gems, and while having something generic for Objective-C may not be appropriate, something specific to the framework just might be. If I follow a similar design pattern as Catalyst, it starts to make more sense. For instance, there are a few ORM systems that are available as C, C++, or ObjC libraries. One would not need to care about grabbing this generic-orm component, but somebody would certainly want an already assembled library for interfacing this web framework with that generic-orm (a la Catalyst::Model::DBIC::Schema
Anyway, that was a long introduction and explanation to show you that, yes, it's starting to actually work. :)
(click to enlarge)