Fishysplash

Much that I enjoy C# during work, it's still very much an 'enterprisey' language. Out of work, I've recently begun to look elsewhere for a simpler, more fun way of coding, and have begun investigating dynamic languages more.

I really digged how Rails applications are built without a fully fledged IDE like Visual Studio - and liked how developers rely on the command prompt, and various scripts. I took time out on the first weekend to try out a bunch of editors (just like the book suggested), and in the end homed in on JEdit. This to me had the best set of features for Windows machines, whilst not appearing overly bloated. A project/folder explorer proved to be vital when developing Rails applications, since a rails application is spread over many folders, and JEdit has this. JEdit also looks slick to boot.

Creating a new Rails application was a breeze. Again, it shows just how much more productive a competent developer is using a command prompt compared to mucking about in clunky drag'n drop IDEs like Visual Studio. I began reminiscing back to my DOS days, when armed with a library of DOS commands, I could do things so much faster than with a graphical shell. Scaffolding code is also really easy to build using the 'ruby script/generate controller xxx' syntax, and I began building my first app in minutes, following the book. Everything seems really fast and really rewarding.

Another thing really well though out is the 'migrations' aspect. This lets you incrementally modify the database through database-agnostic change scripts. Using the rake tool, you can then apply, rollback and reapply these versions. Microsoft is completely silent on how to manage database versions, and it is up to the individual developer to devise some kind of process.

There were some things though I didn't like (at least initially) with Rails. Firstly, when I started with the models, I got a big surprise when I saw the first model class was completely empty. I'm used to explicitly defining the model's attributes as properties on an object. The Rails way is to just imply them and let the ORM and database resolve it all. The more I played with the demo, the more I realised that this was simply down to how you view the benefits of statically-typed languages vs the flexibility of dynamically-typed languages.

Another thing that irked me was Rail's implementation of Javascript. It appears (although I've not really played with it that much) to be an abstraction of Javascript. Having used Web forms for 5+ years and being bitten time and time again by its leaky abstraction, I'm always very wary when a framework tries to hide some thing from me that I don't consider should be hidden. I've spent time learning Javascript and JQuery and would rather use them than Rails' implementation.

Despite early successes with the Depot application, as I ventured deeper into the book, I didn't get many more 'aha' moments, nor did I feel I was understanding the framework any better at a deeper level. Rails is very impressive when you first see it, and the demos show how simple it is using the scaffolding to knock up initial prototypes of applications very quickly. However, I soon stopped getting those positive reinforcement feelings the more I went into it. Rails seems to have a fairly steep learning curve once you get past the basic 'blog in 15 mins' example. 

The problem is that Rails seems to implement just a little too much black magic, and a little bit too much convention via tenuous rules. I can see the value in convention, but I feel Rails goes a bit too far sometimes. I can understand what is meant by the 'average technical ability of Rails developers' being high. I actually suspect something slightly different. I suspect there are lots of Rails developers who are 'hacking' Rails, and only a few Rails developers who actually understand and use it properly.

Also Rails does not seem to require a massive knowledge of Ruby (at least to get started). I've heard this elsewhere - that many Rails developers jump straight into Rails without learning Ruby first. It just seems strange to me that a framework should be bigger than the language it is built on, but this seems to be the case with RoR. To be honest, I really like Ruby - however, I don't like being tied to a framework, and it seems that when using Ruby, you are tied to Rails. I would much rather be free to use the underlying language and select individual libraries to build applications rather than use an all-in-one framework. With Ruby, the power of Rails seems so strong that not using Rails does not appear to be an option. Ultimately, the feeling of using an all-knowing framework like Rails felt not a lot different to my experience with Web Forms, so I begun looking elsewhere.

The next obvious place to go was to Python, so I begun researching and comparing the two. As I started to compare, so I began realised how well suited the Python way was to the way I personally think and approach programming.

Whereas Ruby preaches TIMTOWTDI, Python preaches 'There should only be one, and preferably one way to do it'. Python values explicit over implicit, which again contrasts to Ruby. These things are important to me. Python is a slightly older language than Ruby, and is a lot simpler. Again, I value simplicity. The more I contrasted the two, the more drawn I was to Python.

Python is very much embedded in the Linux community - another factor. I'm increasingly using Linux at home, and Python seems the most natural choice. Ruby although available on all major operating systems, has no real 'home' os. If anything it seems to be drawn slightly more to the Mac community.

Installing Python was a cinch using the Ubuntu Software Centre. There is also IDLE, which is the defacto IDE (at least for starting Python). Python may not be as glamorous as Ruby, is a little older, and arguably less object oriented and functional-programming focused (although Python 3.x appears to narrow the gap compared to Python 2.x). However, what Python lacks in glamor, it makes up in bucket loads in the simplicity stakes.

Ultimately, it's the overall warm cozy feeling I get when coding Python compared to Ruby which has made me choose it. Nothing's particularly wrong with Ruby / Rails, it's just as Matz says - Ruby's philosophy is about making programmers more happy. It's just with me, Python makes me  bit more happy :)