[insert title here]

We hypothesized that CS50 suffered from two problems, one of perception and one of design. Although the course was highly regarded, most everyone on campus seemed to think that it should only be taken with caution, not unlike similar courses elsewhere. Opinions were mixed on whether the cause for concern was the course’s workload or difficulty, but the result was the same. The consensus was to beware.

I went to a Facebook visit day last Friday.  I ran into Mark Zuckerberg while playing some bughouse near his conference room.  My friend Jim and I talked to him about Harvard for a bit.  Jim mentioned something about taking a class from David Parkes, to which Zuckerberg responded, “Oh yeah, David Parkes… I think he wrote me a recommendation letter recommending that I not get kicked out of school.”

Yeah, that’s my story.

So this is certainly not the most original topic on the planet, but I’ve worked with both of these frameworks enough that I’d like to spew my views on the two.  For those who don’t know, Rails and Django are both web development frameworks.  Rails is written in Ruby, while Django is written in Python.  Both claim to allow the programmer to be super-productive.

In any case, before I begin, I’ll note that I much prefer doing Ruby on Rails development in theory, but in practice I end up writing Django apps these days because it turns out to just be a better idea.  And here’s why:

Verbosity. Here Rails is a clear winner.  Rails pulls all sorts of tricks that mean you have to write less.  Part of this is due to the use of Ruby as its underlying language.  While Python in theory supports many of the same “magical” attributes as Ruby does, they tend to be exploited less.  For example, while both languages have a feature that allows an attribute lookup on an object to be programmatically handled (in Python, this is __getattr__, in Ruby this is method_missing), the __getattr__ method is not really used in Django, while method_missing is utilized to make most of Rails happen.  One feature that Ruby alone has is the ability to call methods without parentheses (so simply writing a method’s name is sufficient to call it with no arguments).  This means that you can get away with typing fewer characters (which in a webapp, where the goal is to spew as much functionality out as possible, can become quite significant), but possibly importantly, you don’t have to remember what object attributes are methods and which are instance variables–in effect, all Ruby attributes are what Python would call properties.  This leaves you free to concentrate your efforts on churning out more code.

One clear example of Rails’s less verbose approach is in parameter passing to templates.  In Django you need to explicitly create Context objects to be passed to your templates to render them.  This requires a bit of work from your end, as you have to explicitly decide which variables should be accessible from your templates, write those out, and remember to update your dictionary each time you create a new variable for the templates.  In contrast, in Rails any instance variable of your controller object can be used in your view without problem.

This extends into many other areas.  In Django, one must specify a lot of the glue that holds the application together.  Initially, one specifies a template base path.  Then whenever one wants to render a template, one must instantiate an explicit HttpResponse object that is given the relative path to the template.  In contrast, in Rails after a controller does its thing (generally just setting instance variables), it automatically renders the appropriate template, using a sensible default that you want to use in the vast majority of cases.  No need to create explicit response objects–although if you’d like, you can do something different.

Built-in functionality. Here the winner is less clear-cut.  Both have features that the other really should steal.  Django comes with an admin panel, which is incredibly helpful for bootstrapping, testing, and even running a production application if you don’t mind doling out superuser access.  Rails in contrast had a plugin that provided similar functionality, but the project died off a while ago and no longer really works due to Rails’s rapid evolution.  Rails on the other hand has better code generators (it creates skeletons of your models, views, controllers, etc..; Django creates some of the files you need but doesn’t populate them at all).  It also provides better peripheral support: a task language (rake), schema evolution (through migrations, which can also do things like load data), and so forth.

On the whole, I much prefer building Rails applications.  There is a lot of magic that happens (convention over configuration is the philosophy, so many things work out of the box in a sensible way) that in Django one has to explicitly code.  This tends to be a lot more useful for the rapid iterations one utilizes during web program.

That being said, there’s one crucial blocker with Rails, which is that it’s written in Ruby.  While Ruby is a great language (blocks are so cool!), the unfortunate fact is that Python is a lot more useful, mainly because everyone is using Python.  The third-party module support in Python is such that you really can import antigravity–there’s a module for pretty much any conceivable task.  In contrast, Ruby tends to have fewer modules, which means you have to spend a greater percentage of your time writing library code rather than working on your application.

I’ve never been a fan of humanities classes.  Well, that’s not quite true.  In middle school, I had a killer English class, where the mechanics of grammar were pounded into our heads.  I walked out of that class with an understanding of how sentences are put together, a sort of hard knowledge that I could point to as the fruit of my hours of toil in that class.  And then everything seems to have gone downhill from there.  In high school, English classes essentially consisted of reading books or short stories and then answering questions about the plot to ensure we had actually completed said reading.  I never left such a class feeling that my time had been well-spent, but at least I could console myself with the fact that college classes would undoubtedly be better.

So during fall of my senior year, I took Philosophy 101 at my local university.  Going into the class, I was very excited to learn about how people actually do philosophy–I’ve always thought deeply about life, and at the time I had worked out an sort of theory-of-everything that dictated how I lived my life.  Now, this class consisted of essentially two parts.  First, we would read a philosopher, and then we would discuss how that person’s views conflict or accord with the other philosophers we had read.  I soon decided that this approach was not working for me.  First of all, there was never any indication about why we should care about the particular philosopher of the week (other than the fact that other people had cared enough about them to not burn their books).  What makes this particular person’s ramblings on the world more worthwhile than any other’s?  Secondly, if this philosopher had sat down and come up with a compelling argument in one direction, and another philosopher had sat down and worked out a compelling argument in a different direction, then at least one of them is lying to us and we really should not be reading them.  I could hardly see how we were going to find truth in all of this.  By the time I turned in my final paper, I had decided not only that I no longer wanted to pursue my philosophy major, but also that my entire system of beliefs had no more claim to legitimacy than any other.  I certainly gained no hard knowledge in that class (other than “Descartes said…” and such), and even the soft knowledge I gained didn’t seem particularly worthwhile.  But I figured that the problem here was just the particular school or the particular class, and once I was actually doing my undergrad everything would be better.

And then I found myself at Harvard.  Part of the reason I chose that school was because I did not want to sacrifice having stellar humanities classes.  I knew there was value in such courses; I just had to take the right ones.  First semester of freshman year, I did not end up taking any humanities due to scheduling.  Second semester I took the required Expository Writing class; my particular variant was entitled “Art of the Essay.”  We essentially read essays and then discussed the various elements of said essays.  I felt that about 20% of the class was useful while the other 80% was a waste of time.  The analysis of the essays’ arguments felt particularly reminiscent of the philosophy class.  We would essentially prune sentences from the work to “prove” that the essay was making a particular point.  But given appropriate pruning, one could show that the author was attempting to make any arbitrarily chosen point, and even worse, I never really understood why we should care what point the author is trying to make.  If the author really cared that much, wouldn’t it be easiest to just come out and say whatever he or she was trying to say?

My first semester of sophomore year, I decided to give the humanities classes one more try.  I took Moral Reasoning 78: Classical Chinese Ethical and Political Theory.  This class is more than partially responsible for my transfer to MIT the following semester.  Here we would read a classical Chinese philosopher, and then simply discuss what he said.  No thought about whether his assertions were true or even useful.  Needless to say, at the end of the semester, I had firmly given up on humanities.

Fortunately, transfer credit is a wonderful thing.  At MIT, I will have to take precisely one humanities class (provided it is also a HASS-D and a CI-H).  I am also taking 6.033 at the moment, which is a class where we read computer science papers and then discuss them.  Thus far the discussions have bordered on soft (“What sorts of things have hierarchy?”, “How does the Therac-25 paper make you feel?”) but I have hope that they will harden up in the future.