CodeMash 2012

I had the good fortune of attending my first CodeMash a couple of weeks ago. CodeMash is a conference in Sandusky, OH in the middle of winter at an indoor waterpark/convention center. All 1200 tickets were sold out in 20 minutes and the registration rush brought EventBrite’s servers to their knees. There weren’t any Perl talks (maybe I’ll submit one next year), but there was a wide range of topics to choose from.

Building For the Cloud at Netflix

Carl Quinn from Netflix gave an excellent talk on how Netflix uses Amazon Web Services. They have a really slick setup where a deployment involves simply firing up a new, pre-baked instance and redirecting traffic to it through the load balancer. The new version runs alongside the old version and a rollback simply involves telling the load balancer to send all traffic back to the old version. By pre-baking images they avoid having to do any scripting on the instance as part of deployment. Pretty slick. And their so redundant with their Cassandra instances, they put them on ephemeral storage, which means that the data disappears if the instance is shutdown.

Becoming a Ruby Gemcutter

I only caught the second half of Nick Quaranto’s talk on building ruby gems, but what I did see was a good outline of best practices for creating and managing your own gems. I was also interested to learn of GemTesters, which is basically CPAN Testers for Ruby. I often hear Perl mongers mention that no other community has something like CPAN Testers and that makes Perl better. Well, Ruby has it.

Cooking Environments With Chef

I was really looking forward to this talk by Colin Gemmell and wasn’t disappointed. Colin went over the basics of knife, roles, recipes, and cookbooks, while making it all seem so easy. I’ve even started playing around with Chef at work already and am hoping to automate a good chunk of our infrastructure management with it. Nothing like a developer pretending to be a sysadmin. I think we call that devops now.

Cross-Platform Mobile Apps With jQuery Mobile

I had the misfortune of fumbling around with jQTouch this summer, so I was looking forward to hearing about how the 1.0 release of jQuery Mobile was working out. Apparently a lot has changed since the summer and it is now on a path to becoming the dominant browser-based mobile framework. It’s even got Visual Studio 2010 and Dreamweaver CS5 integration, which indicates some serious momentum to me. I’m hoping to get the opportunity to play around with this some more on a side project.

Information Overload

Scott Hanselman is one of the best speakers you will ever see at a tech conference and this talk did not disappoint. He went over how to deal with information overload. Scott gets hundreds of emails a day and can never hope to give everybody the slice of his time that they wish they could have. Dealing with this has led to him developing a number of techniques for coping. For example, he splits his inbox by whether the message was sent to him or he was just CC’d. If you CC him on an email, he may never read it. If it was important you would have sent it to him. The talk was a blend of many time management and organization techniques and I highly encourage you to check it out once it’s up on InfoQ within the next few months.

Beautiful Front End Code With Backbone.js and CoffeeScript

Backbone.js and CoffeeScript are two tools that I’ve been interested in, but have not had the motivation to actually check out. I’ve been through the quagmire of trying to understand jQuery eventing gone wild. And I’ve been the one writing the code. At some point ad-hoc event handlers just gets to be too much to manage and that is where a tool like Backbone.js comes in handy. Backbone.js is just a client-side MVC framework. That’s it. And coupled with the expressiveness of CoffeeScript you can get a lot done with just a little bit of code. I see myself using this judiciously in the future. For many sites it would be overkill, but even those sites often have certain pages which are more JS-heavy than others.

It was a great conference. Many attendees consider CodeMash to be the best conference they attend every year. I was just about the only Perl guy there, but it was great being immersed with developers with a wide variety of skills. And it’s very satisfying to play in a waterpark in January while it snows outside.

The Wow Factor

One thing that I find Perl to be lacking is a “wow” factor. Something so easy and awesome that within 5 minutes you’re sold on it. I was reminded of these after starting a side project with Ruby on Rails and Heroku.

This is my 3rd foray into Rails. I briefly worked on the initial version of OrgSync in 2007 with Rails 1.2. I came back to do a small website (since switched to WordPress) in 2009 using Rails 2.3. Now I’m back on the train in 2011 with 3.0.7. Every time I’ve ventured in I’ve come out deeply impressed and this time it is even more so because of Heroku. I went from never having read anything about it to having an app up and running in hours. And a lot of that time was spent just browsing their documentation. I could have done it in 15 minutes. The pain of Rails hosting I experienced in the past is simply gone. And it is free to get started. Everything about the process is designed to minimize the amount of friction a new user experiences, all the way from creating a Rails app, creating some scaffolds, and installing it on Heroku.

Maybe Stackato or DotCloud can provide some “wow” for Perl. Until then I’m pretty stoked to be riding the Rails again.

Perl From The Outside

I’ve been a Perl developer for almost 6 months now, so I thought it would be good to step back and document what the community looks like to an outsider. Before moving to Perl I worked professionally with C# as my primary language for 3+ years, so I have a bit of a different background compared to the average Perl monger. I also have varying amounts of experience with JavaScript, Python, Scala, Ruby, Java, and C/C++. Keep that in mind. You’re journey to Perl has probably been different then mine. Also keep in mind that this is what the community looks like to an outsider, not what it actually is.

People Still Write Web Sites in Perl?

If you’re heavily invested in Perl and the surrounding community, I probably already angered you with that statement. Unfortunately, that is the prevailing view of amongst my developer friends. Most of them use C# as their primary language on the job, but have also used VB6, Java, C++, JavaScript, Python, and PHP (and probably more I don’t know about) at some point in their professional career. It was also the first thought I had when I saw a job posting for a Perl web developer. I had been looking for two months and that was the first one I could remember coming across. I didn’t match the requirements, but it was local and I knew I could learn a language quickly. I didn’t know any C# before my first job. Why not go into my second not knowing any Perl?

One rebuttal to the “nobody writes web sites in Perl” argument among Perl mongers is that pigeon holing the use of the language to only how prevalent they are in web programming is unfair. I sympathize with them, but that doesn’t change the fact that the perception of a language among young developers is almost entirely driven by its adoption (and the visiblity of that adoption) on the web. Currently, when a fresh graduate enters the workforce most job postings are very web-centric. The hobby projects most students have usually involve games or web programming, two areas where Perl has struggled to gain traction.

The Learning Process

Back to my learning process, I got an interview and afterwards drove straight to the library to pick up Programming Perl (the camel book). I didn’t know anything about Perl, but I knew the camel book was the de facto guide. Unfortunately, the camel book hasn’t been updated since 2000, but outside the Perl community it is really the only book anybody is familiar with. Combined with the lack of new Perl books in general and their absence from bookstore shelves, this is a big contributor to Perl appearing dead to an outsider. I have heard rumors that an update is on the way, but I couldn’t find any confirmation on O’Reilly’s website.

So, beyond the camel book, what other resources does a newbie come across? Coming from C#, StackOverflow had become my standard reference for any .NET question. The site is written in .NET and the team behind it is well known in the .NET community. Unfortunately, the Perl community hasn’t been as enthusiastic in its embrace of StackOverflow. There are several good reasons for this, most having to do with the community already having established mailing lists and the prior existence of PerlMonks. For the outside developer though who already uses StackOverflow as a standard reference for a multitude of languages and tools, the dearth of Perl questions gives the impression of little use. A quick glance at the StackOverflow tags page lets us see that there are ~17x more questions tagged with C# then Perl. Is C# usage really 17x greater than Perl? Probably not, but the initial perception it gives is not good.

The Pain of TIMTOWTDI

Perl has embraced the motto “there’s more than way to do it” since it’s beginnings and in many ways the philosophy was served it well. The language itself is very extensible and that extensibility has encouraged many developers to have the hubris to think “I can do X better”. This philosophy has given us diversity in things like OO frameworks, where you are free to choose from several excellent choices depending on your needs. However, it also creates a sense of chaos and the lack of any sort of ranking system on CPAN makes it difficult to know which modules to actually use. The worst example I have seen with this is error handling.

Perl predates the widespread adoption of exceptions as the de facto way to handle errors and many developers have stepped forward with modules to fill this void. The problem for the Perl newbie is that there is no easy way to determine which one to use. The fact that such a fundamental, and in other languages simple, question is complicated by so many choices is overwhelming when learning the language. A newbie is confronted with at least the following choices:

There is no easy way for someone just learning Perl to choose between them. The first result from Google for the search “perl error handling” is an article from 2002 for the now deprecated Error module. It’s a shame that such a concept that is so easy to pick up in other languages can be so frustrating to a new Perl monger. I ended up just using the built-in handling, which felt (and continues to feel) clunky compared to the ease of exception management I was used to.

They Can’t Even Ship a New Version!

At some early point in my learning process I started hearing about Perl 6, a subject that seems to cause confusion even within the Perl community. Unsurprisingly, this confusion is magnified for newbies. I now know that Perl 6 is to be treated as an entirely separate language, but outsiders do not know this. To them the decade long (and still going) process to create a production quality implementation seems like a joke. When an outsider sees the names “Perl 5″ and “Perl 6″, the completly natural assumption is that “Perl 6″ is the next version of Perl. And the natural conclusion after seeing that Perl 6 was announced over a decade ago and has very little adoption, is that Perl is a dead language. I have read that Larry has spoken the final word on this issue, but that doesn’t mean it was the correct word. It just means the issue has been closed for debate. The name Perl 6 will continue to hurt the perception of the community from the outside.

Beating the Java Strawman

Most developer communities have a favorite whipping boy. Perl (like many) has chosen Java, but seems to have thrown the baby out with the bath water by vilifying everything associated with Java as well. Now, I’m not here to defend Java. The language has serious warts (crippled generics anybody?) and the late 90′s “enterprise” framework rush crippled the Java community in ways it is still struggling to break away from. But I found the wholesale rejection of everything associated with Java distasteful in many ways. First, it felt childish, but more importantly it has left the community behind the curve in many ways, most notably in object oriented architecture and standard design patterns. As a developer with a strong background in these areas this was a bit of shock. My fears were at least partially eased when I discovered Moose, but overall the Perl community comes off as too cavalier in its dismissal of these ideas.

On a related note, yes, I know that many important OO design principles did not originate in the Java community, but it’s status as the dominant enterprise language at the time the internet took off put it in a unique position to be a test bed for many design ideas on large projects as businesses rushed to retool their infrastructure.. Consequently, most influential architecture and design books released in that time period generally assume Java.

Shaking Things Up

At this point, outside developers have little interest in learning Perl. Any exciting new developments tend not to break out of the Perl echo chamber. For example, the fact that Perl now has several nice OO framework implementations is nice, but doesn’t attract any new Perl developers (although it does seem to have brought some old Perl developers back into the fold).

Looking in from the outside, I see two possibilities for attracting widespread interest in Perl again. One is widespread adoption of Perl 6. It doesn’t really matter if anything is gained technically from this. As I stated above it would remove the specter of decay that surrounds the community. The buzz from some notable adoption of Perl 6 could be the push some developers need to take a look at Perl. In a similar fashion, for the lack of a better comparison, Perl needs it’s killer app/framework. The best example of this in the past decade has been Ruby on Rails. Ruby is a very nice language, but Rails gave it the momentum it needed. I, and many others, would never have given it a chance without Rails. I have no idea what this project would be for Perl, but it wouldn’t hurt to take chromatic’s recent advice and brag about interesting Perl projects.

Conclusion

Overall, my journey to Perl has been worthwhile. I had been concerned about being typecast as a .NET programmer and getting stuck in Microsoft-land for my entire career. Being able to program in multiple paradigms (static vs. dynamic in this case) has certainly made me a better programmer and expanded how I approach certain problems. Plus, it confirmed to me that I can learn and become productive in a new language in a very short period.

However, the problems with the perception of the Perl community aren’t going away and at this point it is probably too much to hope that they ever will. The community itself is too fragmented and pulled in too many different directions to expand it’s core niche as a text processing language. Perl certainly isn’t dead and does seem to be gaining some momentum internally, but none of this has reached the outside world. Until it does the community will not grow in any significant way

Games::Tetravex

After much gnashing of teeth, I got Games::Tetravex working earlier this week. This a Perl implementation of tetravex using SDL and MooseX::Declare. As my first foray into both SDL and Moose, as well as the first game programming I have done since college, I thought it would be useful to lay out my impressions.

SDL

I’m pretty ignorant when it comes to graphics libraries. I did a little bit of game design in college in Java, but nothing with any depth. My crowning achievement was a half-working, four player, networked pong that I wrote in a two night code flurry. Then we got our grade and I never looked at the code again. With such little experience my first task was locating some tutorials. Luckily, I stumbled on SDL_Manual which, while not great, gave me enough of a primer to get started.

As far as actually using SDL for Games::Tetravex, it was pretty easy. It required me to start thinking in terms of (x, y) coordinates again, but, armed with some scrap paper, I was able plot out most of my canvas fairly quickly. It’s by no means pretty, but it does the job. I was quite happy with the SDLx::App and SDLx::Controller wrapper modules, as these made writing the actual game loop a piece cake. It becomes as simple as creating the app, registering some event callbacks, and calling run. Very nice.

Games::Tetravex screenshot

Moose

To me, Moose is what gives Perl a future. Without a full featured OO framework it will be difficult to attract young developers to the language and Moose delivers the goods. My usage in this project is primitive, but I still came away with a good impression. I started the project as just one big script until I got a handle on what exactly I wanted to do. At that point I started refactoring using MooseX::Declare and was very pleased with the final result. In truth, the use of MooseX::Declare was complete overkill for a project of this size, but I figured I might as well jump into the deep end of the pool and see what happens.

It wasn’t all fun though. The big issue is the stack traces MooseX::Declare returns whenever you have some sort of parse error. They’re awful. Very rarely did they give any information about where the parse failed. I had to resort to commenting out large blocks of code until the program would run again. That was the only pain point I ran into, but it was a doozy. I’m sure there is useful information buried in there, but a stack trace of over a hundred lines with no useful summary is a problem.

To Do

There is still a lot left to do. The big one is that you can only play a 3×3 grid. After that it needs a lot of spit and polish, such as

  • timers
  • configuration
  • top times
  • better piece swapping animations
  • improved graphics

and a bunch more I’m forgetting right now. We’ll see how much I actually get to before my eye starts wandering to some new piece of shiny I want to learn.

Code available on github at https://github.com/CuriousCurmudgeon/Games–Tetravex.

From C# To Perl: Performance

Caveats

Let’s talk about the performance of C# vs. Perl. First, let me just say that a performance comparison of a staticly-typed, pre-compiled language vs. a dynamically-typed, scripting language is inherently unfair. Yes, .NET does not compile to native code, but the comparison is still unfair. A static, type-safe language avoids the overhead of compilation on startup and allows for more optimization, particularly removing virtual calls when not needed.

Comparison

With that being said, how much faster is C# in benchmarks? My usual source when comparing the performance of programming languages is the The Computer Language Benchmarks Game. Here you can see the comparison of C# vs. Perl. One thing to note is that I am comparing the performance of the Mono implementation of C# vs. Perl, not the Microsoft .NET implementation. The performance of Mono is comparable to that of .NET these days and the benchmark game runs the benchmarks on Ubuntu, so I’m just going to run with it. Also, while small benchmarks have severe limitations, they will serve the purpose here.

We can see three metrics in the comparison: time, memory, and code size. Various benchmarks stress each differently, but the trends are clear. First, C# is a hell of a lot faster than Perl. As I stated above, this shouldn’t surprise anybody.

The more interesting comparisons are memory and code. We can see that Mono uses 13x more memory on the mandelbrot benchmark, but is anywhere from even to 3x more on every other. It also requires up to 5x more code than Perl. You can see the source code for the benchmarks that required much more code in C# below.

k-nucleotide: C# Perl
reverse-complement: C# Perl

You can see that the code for the k-nucelotide benchmark is much more concise in Perl. The verboseness of C# in this case hinders the ablity to quickly understand the algorithm. The same is true for reverse-complement, though not quite as bad, with Perl’s concise file-handling operations being the main difference.

You can also see the same comparison made on a quad-core 32-bit machine. The same trend holds and you can also see that Mono makes better use of multiple cores. Unfortunately, benchmarks are not available for Perl on 64-bit processors.

Does It Matter

So what? C# is faster. How often does it really matter? If you aren’t doing heavy number crunching, it probably doesn’t. These days performance is often limited by outside factors, such as network latency or database performance. But let’s say you have identified a bottleneck in your code and it is definitely your code that is the bottleneck. How would you go about improving performance in each language?

You have similar options for both languages. In C# you can link to native code (usually a compiled C/C++ binary) or you can declare your code to be unsafe to get direct access to pointers. Either way, it’s going to introduce some pain. Integrating C# with native code always made me feel dirty and I usually ended up putting a wrapper class around it to hide the ugliness. Declaring your code to be unsafe isn’t much better. Most of its speed benefits come from getting the runtime out of the way, meaning you lose most of the benefits of C# over C/C++.

Perl gives you a few options that are mostly equivalent to those in C#. First, you can inline C code with the Inline module. This is admittedly pretty sweet for simple cases. You don’t have to use C, but if you are doing it for performance reasons you probably will. This is great if you have a single performance sensitive algorithm in your module, because, as the name implies, you can do it inline. However, there are limitations to what you can do with this method. If you need to improve the performance of a whole module, you are best served by using XS. This is not for the faint at heart, but will allow you to transparently call C code within Perl.

Conclusion

What we have found is pretty much what was expected. C# is much faster, but uses more memory than Perl and is more verbose. They both have similar options to improve performance by integrating with code written in C, although Perl’s seem slightly more natural to me.

Once again though, does it really matter? Most programmers are not tackling performance sensitive problems and hardware is cheap. If performance does matter, you’re probably better off with C#, but in the grand scheme of things, whatever tools your team is familiar with is the far more important factor.

Welcome

Welcome to the newly launched website for Curmudgeonly Software. The goal is for this to be an umbrella for all of my open source work. For now, you can see projects I have contributed to on the Projects page. All technical posts that formerly resided at curiouscurmudgeon.com will also be moved over at some point and all future technical posts will be posted here.

From C# To Perl: Garbage Collection

I don’t think that it is a stretch to say that every modern language that isn’t built especially for peformance or system programming uses a garbage collector. The programmer productivity gains that you get by lifting the burden of manual memory management can be large. Sure, you lose some control, but most tasks don’t require that level of control. C/C++ is always there if by chance you actually do. With that being said, let’s look at how the Perl and C# garbage collectors compare.

Perl employs a simple reference counting garbage collector. A reference counting garbage collector works exactly as the name implies. It keeps a count of the number of references to a piece of data on the heap. When the number of references to an object reaches zero the collector knows that it can reclaim the data. The major limitation of this algorithm is that it cannot handle circular references because the reference count will never reach zero. Even if your application can no longer access the data, the collector will never reclaim it, leading to a memory leak. Fortunately, circular data structures don’t come up in most applications, but you must be aware when they do. Perl allows you to get around this by weakening a reference. A reference that has been weakened does not increment the reference count for the garbage collector, allowing the it to reclaim circular data structures when used properly.

Coming from C# the simplicity of the Perl garbage collector was a bit of a surprise, because, quite frankly, I find the .NET garbage collector to be amazing. It uses generational collection, allowing for faster collection cycles that get most objects, with periodic longer collections to check older generations. The longer collection cycles use a simple mark and sweep algorithm. There are even different modes depending on if you have a desktop or web application. It also allows you to weaken references, manage non-memory resources with finalizers (although you should be implementing the IDisposable pattern), induce collections, or get notifications when the runtime senses a full garbage collection is approaching. This is a massive topic, but if you want to learn more about .NET garbage collection then you ever wanted to, a good place to start is the blog of Maoni Stephens, who spends her days actually working on it.

Put simply, C# collector puts Perl’s to shame. Unfortunately, the programming language shootout uses the Mono implementation of C#, so a quick comparison against Perl isn’t feasible. Quick benchmarks most likely won’t exercise the generational collector very well anyways. If Perl 6 ever gets around to being ready (I’m not counting on it), Parrot will allow for pluggable garbage collection engines. I would fully expect for something better than the current Perl 5 garbage collector to be an option. For now though, C# has a clear edge.

From C# To Perl: Code Analysis Tools

At my last job we ran a continuous integration server with CruiseControl.NET. As part of each build we did code analysis with FxCop. (We also ran StyleCop, but that was only to run one custom rule to address a problem we were having.) FxCop is a tool that analyzes .NET assemblies for potential design, localization, performance, and security problems. Most of these rules are pulled from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, which serves as the de-facto style guidelines in many .NET shops. (We used it to avoid petty formatting arguments. Whatever FDG said was the decider unless we unanimously disagreed.)

So, what are the options in Perl and how do they compare to FxCop? Luckily the Perl community has an excellent tool for code analysis as well, Perl::Critic. I am not aware of any other Perl code analysis tools. It too pulls many of its rules from a standard text, Damian Conway’s Perl Best Practices. Let’s look at how it stacks up.

One criticism of FxCop is its unwieldy XML files. Depending on the size of your code base and your configuration it is easy to end up with XML files running into the tens of megabytes. Perl::Critic, like most UNIX tools, disdains the use of XML (usually a plus) and instead outputs violations one to a line. Both tools let you configure which rules/policies to include with each run. FxCop throws these into the same massive .fxcop XML file while Perl::Critic looks for an INI-style file called .perlcriticrc in your home directory. Speaking of that massive XML file, FxCop also has a nasty habit of rewriting its XML results and configuration across runs, leading to some nasty conflicts if you have multiple developers committing changes simultaneously.

Why would you commit changes though? This is an area where FxCop comes out ahead. Both tools let you exclude violations. Perl::Critic does it through the use of “no critic” annotations. FxCop gives you more flexibility. It allows you to use attributes to suppress specfic violations in any scope you can apply an attribute too. In additon, you can add exceptions directly to your XML through the GUI tool to avoid cluttering your code. You probably don’t want to try editing the XML config yourself. It’s a beast.

FxCop also has some advantages because it works on bytecode. Since all .NET languages compile to the same bytecode you can use FxCop on any .NET language. In Perl this would be similar to using Perl::Critic on Parrot bytecode to analyze any language that runs on Parrot. However, in practice this doesn’t matter too much. Most .NET code bases are homogenous. It’s still pretty awesome though.

Any advantages that FxCop has though are blown away by the fact that Perl::Critic is open source and FxCop isn’t. FxCop doesn’t even have a published API. This means you cannot write your own custom rules. Seriously. Someone explain to me why this is a good idea. There is someone trying to document the API, but it’s a poor substitute for the real thing. Perl::Critic on the other hand is open source with each policy neatly organized into its own module. Install it from CPAN and you’ll get a bunch of policies, all of which you can view the code for to learn how to write your own. And there a lot more rules just waiting for you to try out.

In the interest of fairness, StyleCop is open source, but I don’t have a lot of experience with it. We briefly looked at using the built-in rules, but decided we didn’t really care for a lot of them. A number of these rules would fall into the type of style rules that Perl::Critic has though.

If Perl::Critic had the exclusion capabalities that FxCop has this wouldn’t even be close, but even with those limitations I still prefer it. Point Perl.

From C# To Perl: Introduction

After over three years as a C# developer I have made the jump to Perl. Judging from the dearth of information I have found comparing the two (all I could find is this awful auto-generated comparison), I don’t think this is a jump many programmers have made, so I wanted to make some comparisons myself. In future posts I will be touching on differences (there aren’t many similarities) between the two languages and the advantages and disadvantages of each. In addition I will compare the surrounding issues of culture, tooling, performance, debugging, etc. The focus will be on the C# developer coming to Perl.

Since my Perl-fu is still weak, feel free to point out any inaccuracies you see. To be fair to Perl, when comparing many language features I will be comparing C# against both bare Perl and Perl with CPAN. The malleability of Perl compared to C# makes this necessary. In addition there are some features of each language that have no direct comparison to the other, such as tied variables in Perl (I just sat here for ten minutes trying to think of some feature of C# that isn’t available in some form on CPAN. I couldn’t think of any. Point Perl.).