Is Brevity The Soul of Wit?

Therefore, since brevity is the soul of wit,
And tediousness the limbs and outward flourishes,
I will be brief:

So says The Bard. And countless others, in many areas of discipline.

Take writing for the web. What's the perrenial rule? Half the word count. Of course, there are others: uncluttered layout, highly atomic units of text, etc. All geared towards what? Brevity.

Public speaking? People just don't have the time to wait around. How about fiction? You're lucky enough to get read, let alone be allowed to go on and on...

One area where this is not preached so heavily is object oriented (OO) programming. Especially in those popular, strongly typed languages, such as Java and C#.

I know two languages really well. Perl and C#. Perl takes a lot of knocks for its syntax and the shortcuts it allows you to take. (Which, admittedly can make for spectacularly unreadable code.) But I can't help but wonder if the inclination towards rigid OOP and "readable" code doesn't subvert the value of succinctness.

I'm a developer, so keystrokes are precious to me. Not only that, but brevity of concept is important as well. I want to accomplish my task with as few lines of code and conceptual units as possible.

I recently had a project in C# to read a set of email files, parse them for tokens (text unbroken by whitespace), and generate a list of tokens with a count. Not a big deal: Use a Hashtable and store the count as the value of the token.

My first complaint came at this point. I understand the purpose and argument of strong types, but it's an annoyance to me that I have to constantly convert types in order to do operations on them.

if ( tokenHash.ContainsKey( token.ToLower() ) )
{
 tokenHash[token.ToLower()] =
  Convert.ToUInt32(tokenHash[token.ToLower()]) + 1;
}
else
{
 tokenHash.Add( token.ToLower(), 1);  
}

Perl's weak types offer a much more appealing, shorter way to do the same thing.

$token_hash{lc($token)}++;

In this case, and probably in a lot of cases, the type is going to appear and exist in a very controlled manner. Why can't they be implicit? Less work for me: less typing, and less reading later.

After calculating the counts, I filled a ListBox with the results. As the search included more email files, and the keyword list became longer, I realized that I needed to reverse sort the counts to see which tokens were appearing the most, since they were obviously the ones that were going to be the most important.

Here's where I began to wish the project were in Perl.

There's no simple method for sorting the values of a Hashtable. Try a Google search on "c# sort hashtable value" and read the results. There are solutions, don't get me wrong, but they all entail steps with added conceptual units, and extra OO verbosity. Which translates almost directly to lines of code. Here's one solution that uses arrays, which can then be sorted.

string[] keys = new string[tokenHash.Count];
tokenHash.Keys.CopyTo(keys, 0);
int[] values = new int[tokenHash.Count];
tokenHash.Values.CopyTo(values, 0);
Array.Sort(values, keys);

This is not a bad solution, but a better one, from the object oriented standpoint, is to create a class that uses a Hashtable and implements its own method for value sorting. Or even better, create a class that is derived from CollectionBase, and build everything you need. You could then reuse it, after all.

Either way, there is still much more verbosity than is required by Perl.

@rev_sorted =
   sort { $token_hash{$b} <=> $token_hash{$a} } keys %token_hash; 

Clearly, in the light of brevity, Perl is the winner. And when the solution is already this compact, there is no need to consider creating an entire class for reuse.

Now, for the object oriented objection: You should never sacrifice comprehensibility for brevity. I agree.

I do not agree, however, with what this usually implies. That somehow object oriented syntax is inherently more readable. Well, I think it is readable, but not just because it's object oriented.

In fact, I found it quite unreadable when my mind was still stuck in the paradigm of procedural programming. Once I understood the concepts of OOP, then it was a snap. But this goes for any programming language or paradigm. I've coded in Perl for a long time, so I understand how it was designed to be used.

And just like C#, it can be misused. Ever seen someone who went abstraction crazy on a project, and ended up with so many object layers that the actual function of the code was impossible to determine? Consider this comparable to someone who decided to show off their cryptic Perl skills and made their code impossible to decipher.

Because I know both Perl and C# well, I can look at all of the above code snippets with equal clarity. Neither one seems more or less comprehensible than the other, because I understand the underlying concepts of both the languages, and don't abuse the syntax of either.

However. The Perl syntax is more appealing, for one simple reason. It's shorter and more to the point.