Caffeinated Coder

Not too long ago, someone asked me to explain the fundamental differences between static languages, such as C# and Java, and dynamic languages, such as Ruby and Python.

Although I knew that duck typing and not resolving method references until runtime allowed for some nifty metaprogramming tricks that translated into not having to write as many lines of code, I was not able to provide any concrete examples of how this was done. This left both me and my friend feeling unsatisfied with my explanation.

Although learning about something at a high level through books, blogs, and podcasts can be useful, I often find that it tricks me into thinking I know more about something than I actually do. I’ve just had way too many experiences where I thought I understood something only to be proven wrong when I finally had the opportunity to roll up my sleeves and tackle some concrete examples and problems.

This is why I have recently been on the look out for some more concrete examples of how dynamic languages allow for some nifty feature that just aren’t possible in static languages (or at least too difficult to be feasible).

I finally found a good one this last week while reading about Dynamic Finders in the book Agile Web Development With Rails. These are convenience methods provided by Rails that allow you to query on various columns by simply following a naming convention for methods that concatenates Find_By or Find_All_By with the column names you want to filter on.

So, instead of having to create and implement a method like this (example from Castle’s Active Record):

   1: public static Card[] Find_By_CardType_And_ExpirationDate(int cardTypeId, DateTime expirationDate)

   2: {

   3:     return FindAll(Expression.And(Expression.Eq(“CardTypeId”, cardTypeId),

   4:                                Expression.Eq(“ExpirationDate”, expirationDate)));

   5: }

   6:

   7: …

   8:

   9: Card[] cards = Card.Find_By_CardType_And_ExpirationDate(cardTypeId, expirationDate);

All you have to do is make the call to the non-existent method that contains your column names and Rails will dynamically generate the method for you.

   1: @cards = Card.find_all_by_cardType_and_expirationDate(cardTypeId, expirationDate)

How does this work?

Unlike with static languages, Ruby doesn’t require that this method actually exists at compile time. Instead it just throws a MethodMissing exception at runtime if the method you called doesn’t exist and then allows you to react to this condition by simply defining\overriding the required method_missing signature in your class.

In order to provide Dynamic Finder functionality, Rails uses something like the Regex logic below to parse the method name that was passed in to the method_missing override and then use the resulting tokens to dynamically generate the method and its implementation, “spot weld” it onto your class, and then execute it.

   1: def method_missing(method_id, *arguments)

   2:   if match = /find_(all_by|by)_([_a-zA-Z]\w*)/.match(method_id.to_s)

   3:     # find…

   4:   elsif match = /find_or_create_by_([_a-zA-Z]\w*)/.match(method_id.to_s)

   5:     # find_or_create…

   6:   else

   7:     super

   8:   end

   9: end

Neat, huh?

I found this example particularly compelling because I am working with both frameworks right now and so far find Castle’s implementation to be remarkably similar to Rail’s Active Record even though it was created using a static language (C#).

The fact that Dynamic Finders aren’t available in Castle’s Active Record and that they are implemented by a decidedly dynamic feature leads me to believe that this was one of the areas that dynamic languages outshines static languages. However, I am a self-avowed newbie in this area, so I welcome anyone with a deeper knowledge of either framework to correct me if I’m wrong.

I would also love to hear about any other concrete examples of metaprogramming magic that is made possible (or much easier) by a dynamic language feature.

If you’re interested in learning more about dynamic languages, then I highly recommend Steve Yegge’s recent blog post, Dynamic Language Strike’s Back. It’s a rather lengthy transcription of a recent talk he did at Stanford on the topic, but it addresses some questions I had about dynamic languages in terms of tooling, performance, and maintainability in some very novel and comprehensive ways so it was well worth the reading investment.

I’m currently en route to Seattle to attend my second ALT.NET conference, so I thought I would take the opportunity to organize some pre-conference thoughts.

ALT.NET in a Nutshell (at least by my reckoning)

Alt.NET is a nascent, loosely organized ideology that started as a vibrant blogosphere reaction to this post by David Laribee and has since evolved into a number of conferences, user group meetings, and mailing list discussions.

Alt.NET conversations I’ve followed tend to focus on…

• Shifting the emphasis away from the latest and greatest API and towards a discussion of sound principles and practices that transcend specific technologies.
• Shunning “Demoware” and visual designers that offer quick, flashy functionality at the expense of long-term maintainability.
• Taking a “best of breed” approach to tools and frameworks and frequently looking to the open source community or competing vendors rather than the traditional Microsoft fare to enhance the .NET development experience.
• Fostering a healthy debate regarding the best way to develop software, thus shifting learning away from a vendor-centric, how-to learning experience toward a more interactive dialog.

The canonical example of an Alt.NET view of the world is the vocal criticism by many in this community of the Entity Framework. Most Alt.NET’ers prefer open source ORM alternatives, such as NHibernate or Ibatis.NET, because unlike the Entity Framework they follow the principal of persistence ignorance, which removes database dependencies from the code thus allowing business objects to be tested more easily and cheaply. While this position may seem like common sense to many, it is considered “Alternative” to most because it challenges the default behavior of many executives and mainstream developers who are more comfortable with following Microsoft’s lead on all technical issues.

If you want more information on the question of “What is Alt.NET?”, I recommend reading this short MSDN article by Jeremy Miller . If you have some free slots in your podcasting queue now that lawn-mowing season has started, then I also recommend the Hanselminutes episode with David Laribee or the recent DNR episode with Laribee and Jeremy Miller. You can also read about some of my own impressions of the first conference in Austin along with a humorous pictoral retort that I put together in response to some of the public criticisms of the conference being too elitist.

Why am I in the cheap seats?

A quick glance at the participants list reveals a high number of well-known speakers, authors, tool creators, and bloggers. I was a little bit star-struck by being surrounded by such a high concentration of geek fame during the last conference and this time around the participant list is even more impressive. I would consider this group to occupy the box seats in my little sports event analogy and I’m not even close to being there. In fact the guards would probably beat me mercilessly if I even deigned to stare wistfully at this section for too long.

Next comes the middle seats. These are the ones occupied by the B-List bloggers and dedicated open source contributors. I hadn’t heard of many in this group before, but was duly impressed last time with their extensive experience with topics that I only had a cursory knowledge of, such as Domain Driven Design, Behavior Driven Development, DSL’s, IoC Containers, MVC Frameworks, and Mocking containers. Unfortunately, I’m not in this group either.

That leaves the cheap seats. That is where those of us who are seasoned developers and agree with the alt.net principles, but have little experience with most of the tools and practices discussed at the event sit. Last time I mostly just shut up, listened, and tried to learn a few things while sitting in this section. Although lurkers are not generally appreciated at an open spaces event like this, I was at least comforted by the thought that I might eventually help spread the good word to my fellow Joe-developers back in the trenches.

I’m afraid I am destined to sit in the same section this time around. I’ll do my best to be a more active participant in conversations, but realistically I still don’t have enough experience with most of the popular ALT.NET tools and concepts to shed my lurker ways just yet. So, if you see a little unobtrusive speck high up in the nose bleed section of the conference, that is probably me.

What am I hoping to gain from the cheap seats of the conference?

1. Feel more stupid than I do now - My primary professional growth strategy so far has been to surround myself with really smart people in hopes that I will learn something by osmosis. I’m pretty sure this will be one of those situations. One unfortunate side effect of this approach is that I am perpetually humbled, which makes it really difficult to bask in the glow of a good old fashioned geek superiority complex. However, it is a small price to pay for all the fancy new developer tricks I learn.
2. Improve my criteria for evaluating tools and products - The one thing that prevents this type of gathering from devolving into a geek popularity contest based on which tools you use is the genuine attempt by most of the participants to define somewhat objective criteria by which to judge technology. For example, if I explain to my coworkers that we should use NHibernate instead of the Entity Framework and or the MVC Framework instead of WebForms, then I want to be able to articulate that these products are inherently more testable, which will help us modify our applications more quickly and with less risk. This type of approach tends to hold much more sway in the IT world than the old standby “all the cool kids are using it” argument.
3. Explore the development landscape - The .NET open source community may be relatively young and small compared to the Java community, but it nevertheless represents an overwhelmingly enormous amount of information for one person to sift through. When you throw on top of that the deluge of technologies being released by Microsoft as well as all of the relevant competing vendor products, then there is simply no way to adequately survey the development landscape other than through a sharing of ideas by passionate developers with diverse experiences in conferences like this.
4. Finally meet people I know - Huh? It sounds weird, but in the last year I’ve corresponded with a large number of people through blogging and tweeting. It seems that most of them will be in attendance this weekend. The small, open space format of this conference is ideal for making and strengthening professional contacts and becoming more engaged with the developer community. While google is still my fallback research tool of choice, I’ve been amazed at how valuable the daily conversations I have over email, twitter, and blog comment sections with like-minded developers all over the world can be. Hopefully this weekend will help me begin to tune into and use the developer community even more effectively.

In conclusion, I’m obviously excited about this weekend, despite my relatively lowly status on the ALT.NET food chain.

If you’re new to ALT.NET, I highly recommend attending one of the upcoming conferences or joining one the main mailing list to find out for yourself what all they hype is about.

I’ve spent much of my free time over the last few weeks learning Ruby on Rails and thought I would record a few first impressions for anyone else who is thinking of dipping their toes in the RoR waters any time soon.

First…My Motivations

1. Curiosity - I’ve made a few snide remarks about Ruby over the past year in response to what I felt was the overuse of hyperbolic and cultish language by prominent Rubyists. After a while, I decided the only way to know for certain whether the buzz was more hype or more reality was to experience it for myself.
2. Project - I promised my wife I’d get a simple PayPal integration e-commerce site up and running for her soon. Since my hosting site only supports PHP or RoR and I’ve already played with PHP enough through WordPress tweaks for my blog, I decided to go the Rails route. This gives me a vested interest in giving it a fair shot because if I can’t get it to work, then the wife won’t be happy. Everyone knows that if the wife ain’t happy, then nobody’s happy.

Learning Curve Milestone

1. Over the Motivation Hump: In the beginning, I languished for several weeks in a state of motivational limbo. The pure Ruby language stuff wasn’t that interesting to me and I hadn’t quite invested enough time in Rails to understand what was going on yet. The “Aha” moments finally came once I got all the CRUD operations working for one of the pages of my eCommerce app (sample apps only get you so far) and then got it deployed to my hosting site. Every since getting past that hurdle, I’ve noticed that the time I’ve spent reading my Ruby book has increased dramatically along with my reading speed because I am suddenly much more interested in it now that I am starting to grok the potential.

Concepts I’m Sold On

1. Convention Over Configuration - As a .NET developer, I’ve written my share of data access code and SQL over the years and feel perfectly comfortable with it. But I have to admit that it was a nice feeling to have ActiveRecord (the ORM package for Rails) be able to glean the table structure based on my naming conventions and dynamically generate the SQL and plumbing code behind the scenes for me. I didn’t even have to look at a bunch of ugly generated code in a code-behind page. It just worked. I haven’t had any experience with Hibernate\NHibernate mapping XML files, but I imagine that it is still much more laborious than the Rails approach.
2. MVC structure - When I first tried debugging into CruiseControl.NET, which uses its own home-grown MVC style architecture, I was discombobulated because the url didn’t directly map to a code file. It seemed like an unnecessarily complex way to structure a web site. However, after experiencing how the url maps to a Controller/Action/Parameter in Rails, Django, and the .NET MVC framework, I am finally becoming a fan of this approach. Once I got used to where to look for everything, code suddenly seemed like it was much more organized and manageable than before.
3. Having Development Lifecycle Built Into Project Structure - The fact that Rails creats a Dev\Test\Prod folder and configuration files, thus embedding the natural development lifecycle into the project structure from the very start, is such an obvious improvement that I’m surprised that not everybody does this.

What I’m Excited To Try

1. Migrations - I’ve heard about this for a while, but only read about its full capabilities today. Managing database schemas and data across environments is one of the biggest pain points where I currently work. Having a tool that can manage incremental changes to databases and then automatically roll versions back sounds too good to be true.
2. RAKE - This is the Ruby version of Nant/MsBuild but it uses code syntax instead of XML. I’m not as much of an XML-hater as some people, but if given a choice I always prefer code because it usually means much better debugger support.
3. RSpec - This is the testing tool that encourages Behavior Driven Development by enforcing certain naming standards and the transforming executable tests into human readable documentation. I saw the .NET port of this last fall at the ALT.NET conference in Houston and finally saw this demonstrated at the last KC Ruby User Group Meeting. I’m still not convinced that it can simply be handed to users in lieu of documentation as many claim, but it is still the best effort to merge the world of tech specs and executable tests that I’ve seen yet.

What I Haven’t Made up my Mind on Yet

1. Documentation: I’ve read several complaints that the English documentation for Ruby, which originated in Japan, is lacking when compared to other languages like Perl or Python. As a beginner, this hasn’t been an issue for me yet because there are plenty of books and web-based tutorials available, but this is something I’ll watch out for down the road.
2. Complex data models: I’m curious how ActiveRecord will handle the traditional problem of impedance mismatch that all ORM systems face when trying to reconcile conceptual differences between how information is represented in a relational database versus an object model (it’s what prompted Ted Neward to call ORM the Vietnam of Computer Science). So far I have been impressed with Active Record, but the approach in all the Rails tutorials so far has been to start with the database tables, which seems to be the opposite approach of what noted architecture gurus like Rockford Lhotka have been recommending for years. I also saw a few references to things like composite keys not being supported by ActiveRecord, which makes me wonder how it will handle large, complex data models from legacy systems. Once again, I’ll just have to wait and see how this turns out.
3. Ruby & Rails vs Django & Python - I’ve seen some excellent debates, like the ones in this Bitwise article or this blog post, on which of these two popular web frameworks is better. Both frameworks rely on the MVC pattern, dynamic languages, and ORM magic to reduce boiler plate data access code. Django boasts faster speed, a more popular and widely applicable language, a more plugable architecture, and some extra administrative interfaces that help out for content management sites. However, since my hosting site doesn’t currently support Django, I’m going to have to wait and do a comparison for myself later this year.
4. Speed & Scalability - I don’t even want to open up the can of worms that Rob Conery did by suggesting Ruby is slow and has scalability issues. However, the general consensus is that Ruby is indeed slower than Python and both are much slower than most static languages like Java or C#. Rubyists contend that Rails is fast enough for most scenarios and that you can always drop down to C when performance is needed. I agree that performance isn’t something that most apps need to worry about these days, but I am more skeptical about the viability and ROI of dropping down to C for most development shops when performance is an issue. On the other hand, Rails is still pretty young, so I can only assume that future versions will improve in this respect.
5. Tools - The general consensus seems to be that tool support for Rails is lagging behind the powerhouse IDEs used in the Java and .NET worlds. Although I do think that Visual Studio is a bit bloated these days, I see Intellisense and visual debuggers as major productivity boosters and see it as a significant downside to doing development in Ruby. So far the attitude I’ve run into from Rubyists has been the equivalent of “real programmers don’t use tools”, which I’ve never agreed with. I did see an article about Ruby In Steel that has both intellisense and a visual debugger, so I plan to try that out. For the time being, Notepad2 will work.
6. Beauty? - Call me a cynic, but I’m afraid I side with Jeff Atwood here when I say that I just don’t feel comfortable using the word beautiful in reference to code syntax. I definitely have aesthetic preferences when it comes to code, but they seem a little too subjective to be able to definitively say that one language clearly reigns supreme over all others in this respect. To be honest, from what I’ve seen so far, I like about half of the syntax in Ruby better than C# and half of it worse. For example, all those end keywords that litter Ruby code give me nasty VB.NET flashbacks, so I’m not partial to them. I am willing to believe that my sense of aesthetics will change over time and that I might suddenly find Ruby syntax more appealing a year from now. However, I am also suspicious that there is an emperor’s new clothes phenomena at play here. This means that a few smart and influential people proclaiming that they see beauty can suddenly cause everyone to convince themselves that they also see beauty, not because it is really there, but because they don’t want to look stupid or feel left out.

Please remember that I am very new to Ruby on Rails, so I welcome any corrections or helpful insights that readers who have more experience in this area can offer.

As for the rest of you, I wisely chose to clip my section on “Tips for People Just Starting Out” because this post was so long, so tune in next time for some tips on how to avoid stumbling blocks early on in the Ruby learning path.

In case this post rides a reddit or Dzone wave, let me start out by saying that I am both from the United States and a .NET developer. Now on to my regularly scheduled point…

I’m fairly certain that most people would agree that Microsoft as a company is despised by a sizable segment of the software industry.

Since corporate politics bore me, I’m going to skip the part about why this is the case or whether this view is justified. Instead, I’m going to focus on the following corollary:

The same segment of the software industry that dislikes Microsoft also views developers who use Microsoft tools and languages as inherently less skilled and less capable.

That is a nice way of saying that when the typical Java\Python\Ruby developer conjures up an image of a .NET developer, it probably looks something like my esteemed blog sponsor on the right sidebar. In other words, I believe that the prevailing stereotype about .NET developers is that we wouldn’t know a software best practice or sound computer science principle if it recursively bit us in the arse.

Why does this stereotype exist and is it deserved?

Some harsh reddit feedback on one of my recent blog posts prompted me to seriously ponder this question and after going through various phases of anger, denial, and rationalization, I finally settled on the following theory.

Developers who don’t earn their living from Redmond-based technologies dislike Microsoft developers for some of the same reasons that people from other countries dislike Americans.

For any of my fellow countryman who are surprised by this, it is true. Most people in the world don’t like you. I’m sure books could be written on all of the social, political, economic, and cultural offenses that we unknowingly dole out on a daily basis, but I’m just going to focus on the one psychological offense that I’ve observed first hand numerous times in my travels.

Americans are inherently annoying because we rarely invest any effort into learning anything about the external world.

For example, If you are an American and meet someone who is well educated from another country, then statistically speaking the chances are good that:

1. You will not speak their language even though they will probably speak English.
2. You will not be able to locate their country on a map even though they could probably name all 50 states.
3. You won’t know who their national leader is even though they will not only tell you the name of our President, but also give you a nice summary of his foreign policy exploits over his last two terms in office.

You don’t have to have a political science degree to understand the psychological effects of this interaction. How did you feel the last time someone completely blew you off because you know they didn’t think you were important enough to bother with? Needless to say, it doesn’t help much on the diplomacy front.

I think a similar dynamic occurs with .NET developers who are so busy drinking from the firehose at Microsoft that they forget about the rest of the development world entirely.

The reddit comments that drove this home the most for me was the one said my opinion should be discounted because I “break the programming languages world into “languages by Microsoft” and “other languages”. Not a bad point.

Then there was my favorite wickedly sarcastic comment from Lepton3 (…come on reddit…you really need to de-anonymize this process a little). In response to my stated desire to learn finally learn Python, he quips… “Steady on there tiger! You wouldn’t want to rush in too soon.” A damn good point considering how long Python has been popular.

They both made me realize that despite my great efforts to study software best practices and learn no less than a dozen new Microsoft technologies in the last few years, I was still being pretty myopic in my approach to software development.

So, I hereby relinquish any guilt that I may feel for not keeping up with every new technology coming out of Redmond in the next several years. Instead, I’m going to do the programmer’s equivalent to a little world traveling so I can get better clued into what the rest of the software world has to offer.

I’m sure all the other kids will still make fun of me for feeding at the Microsoft teat, but at least I won’t stand out like a typical American tourist anymore.

Oh, and for all you .NET readers who may get inundated with posts on Ruby, Rails, Python, Django, and MySQL in the near future (at least that’s what I’ve been spending all my free time on in the last few weeks), hang in there. A little foreign culture is good for the programming soul. Also, since there’s no place like home, I’m sure I’ll continue to churn out .NET content as well.

I’ve been noticing my interest in non-Microsoft languages has been on the rise lately. I’ve been actively playing with Ruby and PHP and have been blog surfing for information on functional languages like Lisp and Erlang.

I guess that’s why I suddenly became curious about the current popularity ratings of programming languages and started to search for some hard data. The most comprehensive rating system that I found so far is the Programming Community Index published by Tiobe Software.

Here’s an excerpt from their February 2008 results:

Position Feb 2008	Position Feb 2007	Delta in Position	Programming Language	Ratings Feb 2008	Delta Feb 2007	Status
1	1		Java	21.483%	+2.50%	A
2	2		C	14.859%	-1.24%	A
3	5		(Visual) Basic	11.604%	+3.24%	A
4	4		PHP	9.890%	+1.04%	A
5	3		C++	9.274%	-1.49%	A
6	6		Perl	6.205%	+0.13%	A
7	7		Python	4.763%	+1.20%	A
8	8		C#	4.510%	+1.32%	A
9	12		Delphi	2.798%	+0.72%	A
10	9		JavaScript	2.334%	-0.65%	A
11	10		Ruby	1.862%	-0.67%	A

The list led me to a few surprising conclusions:

1. .NET isn’t as popular as I thought - It’s easy to lose perspective when you are surrounded by a single technology. For some reason I had assumed that C# and Java were equally popular. Although Java has declined about 5% on this survey over the last six years, it is still almost 5 times more popular than C#. In fact, C# is 8th on list behind C, C++, Perl, and even Visual Basic (oh the scandal!).
2. Ruby didn’t make the top 10 - Although there has been somewhat of a backlash against Ruby in the blogosphere over the last few months, I still assumed it was popular enough to be in the top 10. I suppose I should have guessed as much after the last recruiter I talked to told me that she never heard of the language.
3. COBOL refuses to die - I was saddened to see that COBOL is still 15th on the list. Some languages just don’t know when to quit. This shouldn’t surprise me since the bank I used to work at was at least 3-5 years from retiring their last COBOL program when I left and they were further ahead of the game than the vast majority of other financial institutions (they adopted .NET when it was still in Beta).
4. Python was language of the year for 2008 - Apparently Tiobe awarded Python this status at the end of last year due to its surging popularity. I noticed this right after I got an impassioned endorsement of the language from someone whose opinion I respect. I guess it’s time to check it out.
5. Functional languages are still on the fringe - DotNetRocks has had about a dozen shows on various functional programming in the last several months, so I thought that was a sure sign that the paradigm had gone main stream after a mere 50 years of relative obscurity. However, Functional Languages as a whole come in at a paltry 1.4% compared to the whopping 98% dominance of Object-Oriented and Procedural languages combined. LISP tops out the list at number 20, while Haskell is 36th, Erlang is 46th, and Scala barely made the top 100. Given the fact that we have hit the wall on processor speed and are well on our way to scaling out to a gajillion cores, I’m surprised that functional languages haven’t achieved a Ruby like cult status yet. Do you really want to spend your golden years debugging multi-threaded programs in Java or .NET? I didn’t think so. On a brighter note, Functional language searches rate quite high on reddit as indicated by this other poll. Perhaps there is still hope.
   

   Category	Ratings February 2008	Delta February 2007
   Object-Oriented Languages	54.8%	+3.1%
   Procedural Languages	42.9%	-1.9%
   Functional Languages	1.4%	-0.4%
   Logical Languages	0.9%	-0.8%

6. Dynamic languages are coming on strong - Rails has definitely proven the value that dynamic languages can bring to the table in terms of meta-programming magic and generally making life easier for the programmer, but I was surprised to see that dynamic languages were already almost as popular as static languages in overall usage. I obviously forgot about the prevalence of PHP, Python, and Perl.
   

   Category	Ratings February 2008	Delta February 2007
   Statically Typed Languages	57.2%	-0.2%
   Dynamically Typed Languages	42.8%	+0.2%

As an interesting side note, there were some languages that didn’t show up on the list because of the “Turing Complete” requirements that the site used.

A language is considered a programming language if it is Turing complete. As a consequence, HTML and XML are not considered programming languages. This also holds for data query language SQL. SQL is not a programming language because it is, for instance, impossible to write an infinite loop in it. On the other hand, SQL extensions PL/SQL and Transact-SQL are programming languages. ASP and ASP.NET are also not programming languages because they make use of other languages such as JavaScript and VBScript or .NET compatible languages. The same is true for frameworks such as Ruby on Rails, Cocoa, and AJAX. Finally, we have also excluded assembly languages, although Turing complete, because they have a very different nature.

No matter how you look at it, there are a lot of options out there that are being taken seriously these days and the number seems to only be growing.

It reminds me of a quote that I recently heard from Steven Forte. He stated in an interview that he won’t hire candidates if they have too much experience in any one language. He suggested only spending about 2 years on a language before moving on to something else. I was skeptical of his career advice at first, but now I’m starting to think that he had a point.

We are clearly entering the era of the polyglot programmer, which means that diversification is becoming more and more of a career asset.