Not that it should be too surprising to me, but (even as a long time Rubyist) I’m finding the Haskell posts on Slick or Slack to be the most beautiful so far. When I took my first look at Haskell years ago, I thought it was ugly. Every progressive year it strikes me as more and more beautiful.
Why am I not a Haskell programmer, then? More on this in an upcoming post.
In my previous post, I asked for examples of great Ruby code. I got emails, comments, instant messages, and twitter messages with suggestions. I’d still like more.
But one really cool suggestion came from an idea Bil Kleb and Peter Provost had. They proposed a Hot or Not -like site for code.
I thought that would be fun, so Bruce and I whipped something up in a couple of hours over the weekend: Slick or Slack?.
It’s not done yet, but we deployed it anyway. My experience helping Ze Frank with Color Wars 2008 has convinced me that deploying things that aren’t done is more often a good idea than not. If for nothing else that for mental health reasons.
What we want to do now is to start collecting potentially “Slick” code snippets. This could mean beautiful code, clever code, code which does something awesome, or whatever. You can also post code that sucks. We just need code to start the tallies running.
When you visit the site, you’ll be presented with two code samples, probably doing totally different things. They might even be in different languages. Your job is to choose the better of the two. If you can’t make up your mind, just hit refresh.
I doubt this is going to unearth great code in the same way that I doubt Hot or Not unearths great people. But I hope it will be fun to play with. It will probably be broken and we know it’s lacking some necessary features to make it more useful and/or fun. Suggestions are welcome. Just don’t take it too seriously.
It’s fun to watch the rush to be first to market with a new piece of open source functionality. You probably already know that Amazon released their SimpleDB this week. I was thinking we might whip up a Ruby wrapper but I knew if I just waited a day or so there would already be libraries available. Tonight I checked RubyForge and the three most recent projects are all SimpleDB wrappers:
It will be fun to see which one (or more?) of these gains and keeps mind share. Competition among open source projects is an interesting topic given the abstract nature of the stakes.
In the comment thread of a previous post on this site, Chris Taggart made an interesting criticism of my Facebooker Facebook API. It seems that, on a high level review of the code, he found it to be well-craft and well-tested. His criticism was that, unlike in RFacebook, I chose to implement a concrete set of Ruby classes to abstract the underlying workings of the Facebook XML API away from Facebooker’s users. RFacebook, on the other hands, employs a trick using Ruby’s method_missing, to catch undefined method calls and to transform those method calls into HTTP posts which conform to Facebook’s HTTP/XML endpoints. Here’s what an RFacebook call might look like (from the RFacebook Web site):
friendUIDs = fbsession.friends_get.uid_listfriendNames = []
friendsInfo = fbsession.users_getInfo(:uids => friendUIDs, :fields => ["first_name", "last_name"])
friendsInfo.user_list.each do |userInfo|
friendNames << userInfo.first_name + " " + userInfo.last_name
endThis results in two Facebook XML API calls. The two method calls on the fbsession object are undefined, so fbsession converts them to HTTP posts to the Facebook XML API methods called “facebook.friends.get” and “facebook.users.getInfo” respectively. Furthermore, when “uid_list”, “user_list”, “first_name”, and “last_name” are called, RFacebook again employs a method_missing trick to generate an XPath expression searching for the requested data in an HPricot DOM.
Here’s the equivalent Facebooker code:
friend_names = session.user.friends!(:first_name, :last_name).map do |friend|
"#{friend.first_name} #{friend.last_name}"
endIn this code, the same API calls happen as in the RFacebook example, only we don’t explicitly invoke them.
Chris’s (albeit tentative) concern was that, since Facebooker implements objects and their methods as first-class Ruby constructs, the API would somehow be more brittle and less resilient to potential future Facebook XML API changes.
I found it especially interesting that Chris chose this as his only point of criticism, since RFacebook’s method_missing trick and return of an HPricot XML parser object from each API call were two of the key reasons we decided to scrap RFacebook after writing an application with it and implement our own Facebook wrapper library.
As I started to formulate a response, instead of taking my own motivations for granted, I decided to take some time to question my own assumptions. This all led me to question (and to answer for myself) why we write this sort of wrapper library to begin with. What follows are my answers.
Perhaps the primary reason for building a concrete layer on top of a low-level API like Facebook’s is to make the code which uses it less brittle. The scenario Chris was concerned with was that Facebook might change their API, requiring Facebooker to be changed to match it. My point exactly, Chris. If Facebooker didn’t hide the implementation details of the XML API from its end-users, a change in the XML API would require every application which uses Facebooker to change. Magic missing method calls would have to be renamed or changed. If “facebook.users.getInfo” were to be changed to “facebook.user_info”, the calls to “session.users_getInfo()” would need to be changed to “session.user_info()”.
Sure, you could hack the API so that “users_getInfo()” and its parameters were munged into Facebook’s hypothetical new format, but then our API would pretend to be low-level and direct, which would lead to some opaque application code.
When I’m writing a Rails application controller or the controller for a desktop application (both of which I have been doing with Facebooker), I want to think in terms of the domain I’m modeling. In a Rails application, it’s commonly accepted that fat models and skinny controllers lead to well-factored, expressive, and maintainable code.
This is partially because, in the controller layer of an application like this, the code’s job is to (as Marcel Molina said to me recently) codify a dialogue between the domain objects in a system. In other words, when you’re developing an application about users, their friends, their affiliations, and the groups they belong to, the controller should deal with those concepts. It doesn’t make sense to deal with, say, a user, a database connection, the user’s friends, their XML representation, a shared photo album, and HTTP connectivity issues all in the same code.
My brain doesn’t want to jumble all of that together. When I’m trying to look at XML parsing code, domain logic gets in the way. When I’m trying to see how users and their friends interact, XPath is line noise.
Kent Beck refers to this in his Smalltalk Best Practice Patterns as a guiding principle of good API design, specifically having to do with how to decompose your code into methods. His rule of thumb is that one way you know it’s time to create a new method is when the code in one method mixes two or more levels of abstraction.
By abstracting the implementation details of XML and HTTP away from the high level of the API, code becomes more testable. In this case, it’s true for Facebooker itself, but more importantly, the applications that use Facebooker are more testable with a layer of abstraction between them and the XML and HTTP calls which are going on under the covers.
When you’re trying to test a Rails action, it’s much easier to create a User object and set its attributes (first_name, last_name, etc.) than to generate a DOM of sample data. Sure, Ruby being as dynamic as it is, you could create a stub at runtime and forego dealing with the library’s implementation of User altogether. But you shouldn’t have to.
It may seem like a nitpick, but as a Ruby programmer I want to use APIs that look like Ruby code. “fbsession.users_getInfo()” looks like PHP code to my eyes. It’s no surprise. Facebook is written in PHP, and its HTTP/XML API was designed by the same PHP programmers that created Facebook. Wrapping the Facebook API allows me to isolate and hide the PHP idioms, such that the code I use reads like “normal” Ruby code. You could argue that this is not a technical issue, and you’d be right. But I believe in the power of both consonance and dissonance in software development. Dissonant code stands out and alerts the reader that something strange and exceptional is taking place. Sometimes that strange and exceptional thing is just bad code. Sometimes it’s an unusual technique that should be highlighted.
When I see non-idiomatic Ruby code, it tells me one of two things. The first assumption I make is that whoever wrote the code is not a Ruby programmer. That’s usually the case. The second is that the programmer is employing a new or unusual technique to accomplish something which is difficult to do without that technique.
Having implemented a wrapper for the Facebook API, I don’t think there’s a need for dissonance. There’s nothing difficult or unusual going on at any level of Facebooker, so it stands to reason that there should be no dissonant section of the library and that it should all read as idiomatic Ruby code.
I love the tricks you can do with Ruby. method_missing, const_missing, autoloading, and their friends make really powerful things possible.
But they do so at a price. When something goes wrong in a piece of code that relies heavily on one of these tricks, it can be much much harder to track down. So the decision to use such a tool shouldn’t be taken lightly. These are power tools. Used effectively, really cool things can happen. Used incorrectly, you can easily find yourself limb-less and bloody. So when you decide to use one of these power tools, you have to ask yourself: is it worth the risk?
Where possible, especially in a library already dealing with something abstract and out of our control (e.g. someone else’s XML API running on their own HTTP servers of which we have no direct visibility), explicit and concrete are much better attributes than abstract and fuzzy. If you run into a problem or question with part of a library for which you have the source code, explicit method definitions and concrete APIs under the covers are much easier to navigate than parsed method names magically constructing arguments to HTTP posts.
In general, if you’re dealing with code which is out of your control, implicit and hidden from view, it’s helpful if the code which surrounds it balances the abstractness with a nice concrete anchor.
This is a summary of many of the usually-abstract ideas that go through my head when I’m creating APIs that wrap other APIs. I’ve been designing wrapper APIs like this for ages, so it’s been helpful for me to convert intuition into a set of hints. I hope these ideas are helpful to others. If nothing else, if you ever have to use an API I’ve written, you’ll at least know why it’s written the way it is.
As I mentioned previously, Marcel Molina and I are doing a full day testing workshop for charity at RailsConf Europe next month.
Dr. Nic Williams hopes to attend but rather than donate the required minimum $75 directly, he has chosen to auction off his MyConfPlan web site and to then donate the proceeds as part of his registration for the tutorial.
So now’s your chance to kick start your way into Web 2.0 entrepreneurship, help Dr. Nic fulfill his goal of learning more about testing, and develop good karma all in one action.
It’s easy to give money. It’s much harder and more personal to give your time, passion, accomplishments, and creativity. Dr. Nic is a shining example for the rest of us. Thanks, Nic!
Friday and Saturday, I attended the first Ruby Hoedown at RedHat HQ in Raleigh, NC. The Hoedown was one of many regional Ruby conferences popping up all over the place driven in small part by Ruby Central’s conference grant. Nathaniel and Jeremy did an excellent job putting the conference together. It was flawlessly executed with an exciting program and a good dose of southern charm.
Here’s a braindump:
The conference pre-started with me, Bruce Tate, and Marcel Molina giving a two and a half hour testing workshop for charity. Taking a queue from the Dave and Mike’s Rails Guidebook, participants gave a donation ($50 recommended) to attend the workshop. We ultimately raised roughly $3200 for the Food Bank of Central and Eastern North Carolina. A large portion of the workshop consisted of me and Marcel interactively improvising the development of an application in test-first style while drawing the questions, comments, and criticism of the audience. The format worked well (from our perspective), and we covered a lot of great material. We’re really looking forward to our FULL DAY testing workshop for charity at RailsConf Europe in Berlin next month. (Next month’s workshop goes to support Habitat for Humanity. We’re happily accepting donations regardless of whether you attend.)
The main conference kicked off with a talk from Ezra Zygmuntowicz about Merb. Merb started out as a complement to Rails—-something you whip out when you need multi-threaded request processing, such as big file uploads and long-running application logic. Rails isn’t always well suited to this sort of thing, because Rails is single threaded. To scale, you have to add more processes, which adds a potentially unhealthy amount of memory overhead. Merb is a multithreaded, lighter weight Mongrel-bound (for now) framework.
Now, however, Merb is turning into a full-blown Rails clone (Actionpack clone really). I remain fully skeptical. I understand Ezra’s stated reasons for doing it (along with a few implicit ones I think), but I think we already have a Rails, and incremental improvements are, well, incremental. It would be nice to see someone taking a leap as opposed to a step. Even before Rails came out, I think the industry had seen enough MVC. I am hopeful that some of Ezra’s improvements make it back into Rails. His desire to keep things lean and unmagical is commendable.
Next up was Jay Phillips, whose Adhearsion framework for VOIP applications completely blew me away. Adhearsion is a perfect example of someone taking a powerful domain with a historically ridiculous development model and taking a full evolutionary step forward. Jay’s framework takes developers from what literally looks like the dark ages (have you seen an Asterisk dial plan?) to a beautiful and powerful API with modern automation wrapped around it.
We Rubyists have been looking for another killer app following Rails. Adhearsion might be it. Seeing Jay speak made me realize that we have that same combination of disdain with the current state of affairs, courage to slap the (telecom development) industry in the face, intelligence to innovate a solution which brings programmer joy and the people skills and marketing sensibility to push it over the edge. If you care about Ruby, watch Adhearsion closely.
The day closed with Bruce Tate giving a keynote on the direction of Ruby. He drew some interesting parallels to past technologies and also led us through a series of scenarios about where Ruby and its community might be headed. The most convincing one can be summarized as using Ruby to build elegant APIs on top of existing problems which do for those problems what Rails did for web development. See Adhearsion.
Andrea O. K. Wright from Chariot Solutions gave a surprisingly thorough and engaging talk which ended up being a survey of the various game libraries available for Ruby. I’m an avid gamer and got interested in computer programming because I wanted to be a game developer, so I’ve taken this tour myself a few times. But it’s been a while and I was simply amazed at how far things have come. As Andrea spoke, I downloaded literally every library she was discussing and tried them out. I had some problems with the SDL bindings on my Mac, but I had instant success with both Gosu and Shattered Ruby. I’m not sure if we’re ready for Unreal Tournament-style games in Ruby but simple games are finally, well…simple to create. Definitely check out Gosu if you even have a passing interest. Really fun.
There were a series of quick lightning talks. They were good, but there were too many to enumerate. I’m liking this format more and more every time I experience it.
During lunch Jeff Casimir and I organized a “BoF” (I hate that term) on Ruby for Social Change. Jeff booked the smallest spot, thinking we were going to be a tiny crowd, but we ended up cramming a large group into the room. The discussion was lively and loud and the people were passionate. With only 45 minutes to talk, we came out of the meeting with some ideas about organizing volunteers to give their time to produce real applications for non-profits/charities who could use the projects to make impactful change. More on this soon I hope. We have a RubyForge project set up for the group.
If you’re interested in this topic and interested in helping to shape what we do, please do drop in and sign up for the mailing list once it’s activated. The first order of business (in parallel to doing things like setting up a web site) is to find a project with a real customer to rally around. If you have ideas, we’d love to hear them.
I was skeptical because of the title of this talk, but I trusted that Ken Auer was going to deliver something interesting, and my skepticism turned out to be ill-founded. Ken is an old Smalltalker and one of the leaders in both the patterns and agile movements. His talk was a well-thought-out history of Smalltalk and ultimately a comparison to Ruby’s adoption curve. I won’t do this one justice with a summary, but I recommend watching it when the conference videos go live on the Confreaks web site.
Jared Richardson gave a really engaging and fun talk on extending Ruby with C. It was review for me, but the audience was totally into it, and 2 out of 6 people who Nathaniel asked to tell one thing they were excited about learning at the end of the conferenced cited material from Jared’s talk. It’s easy to forget how elegant and human-friendly Ruby’s C API is. If you’re the kind of person who has a natural aversion to that kind of thing and have been avoiding it, you really should take a Saturday morning to crack open the Pick Axe and go through some of the C extension examples. I think you’ll be pleasantly surprised. Lots of potential gain for not much pain.
I’m not going to say much about this, because I hope to take this topic into a separate post, but Marcel’s ideas from this talk have already changed the way I think about my own code as I write it. Those that know Marcel and have worked with him know that he is obsessed with keeping code beautiful. Whether it’s a shell script, a systems programming task, or a high level API, he creates some of the most consistently beautiful code you’ll see in Ruby-land. In this talk, Marcel decided to take this passion for beauty and try to more clearly define the elements that make code beautiful. The result is a small but useful framework for measuring trade-offs when developing software. I’m looking forward to seeing these ideas develop. The keynote itself was short but the Q&A and discussion about it expanded such that Nathaniel ultimately had to cut it off. Obviously a topic that inspired much passion.
This time literally. We took a group to a nearby hotel and played Werewolf until around midnight. If you don’t know Werewolf, you owe it to yourself to try it. We played 5 nights straight at RailsConf this year, and I feel like some lasting bonds were made with people who I might not have even met otherwise. I think our community is too cliquey and fragmented sometimes, and Werewolf is a powerful tool (yes I’m talking about a game and saying “powerful”) for changing that.
We’ll be trying to put together a game again in a couple of weeks at The Rails Edge in Chicago. If you’re coming to the Rails Edge, read up on the rules before-hand and join in. If you’re not yet signed up it’s not too late.
Thanks to last night’s players and my (some-of-them) new friends Lyle Johnson, Tony Devlin, Jim Meyers, Chris Redinger, Evan Light, Devin Mullins, Carl Youngblood, Coby Randquist, Joe Martinez, Rick DeNatale, Ted Behling, Ryan Daigle, and Marcel. I hope to see you guys around soon.
If you’re in the South, I highly recommend watching for an announce of the second Ruby Hoedown. Until then, keep your eyes glued to RubyConf.
The weekend before last, I did something I’ve been hoping to do for literally several years: I joined InfoEther (as CTO). If you’re outside the Ruby, Flash, or Semantic Web communities, you may not know of InfoEther. They are a technology company co-founded by my friend and Ruby Central co-conspirator, Rich Kilmer.
InfoEther is best known for doing seemingly impossible technological feats faster than most companies can write a J2EE bug tracker. They’ve led the way consistently in Ruby, Flash, and Semantic Web technologies since Rich and Mark founded the company several years ago.
For me, joining InfoEther is probably akin to what joining a company like Google is to many programmers. It’s like going back to school, in that I’m joining a small team of people who have all been somehow caught up in Rich’s special reality distortion field in which no technological problem is difficult or time consuming. I’m hoping to catch at least a little of that bug.
Under the umbrella of the indi, a personal semantic web platform, we’re working on some innovative technologies which bring together much of the diverse and cutting edge stuff InfoEther has been doing over the past 5 years. More on this later.
A refreshing change of pace from making simple Web applications.
In My Job Went to India, I talked about using supply and demand as a gauge with which to make decisions about which technologies you should invest in as a software developer:
The offshore market has injected its low-cost programmers into a relatively narrow set of technologies. Java and .NET programmers are a dime a dozen in India. India has a lot of Oracle DBAs as well. Less mainstream technologies are very much underrepresented by the offshore development shops. When choosing a technology set to focus your career on, you should understand the effects of increased supply and lower prices on your career prospects.
As a .NET programmer, you may find yourself competing with tens of thousands of more people in the job market than you would if you were, for example, a Python programmer. This would result in the average cost of a .NET programmer decreasing significantly, possibly driving demand higher (i.e., creating more .NET jobs). So, you’d be likely to find jobs available, but the jobs wouldn’t pay all that well. The supply of Python programmers might be much smaller than that of .NET programmers with a demand to match.
If the Python job market were to support noticeably higher prices per-programmer, additional people might be attracted to supply their services at this higher price range, resulting in competition that would drive the price back down.
The whole thing is a balancing act. But, one thing seems certain (for now). India caters to the already balanced IT services markets. You don’t find mainstream Indian offshoring companies jumping on unconventional technologies. They aren’t first-movers. They generally don’t take chances. They wait for technology services markets to balance, and they disrupt those markets with significantly lower per-programmer costs.
Yesterday, one of the Rails Core guys passed along an interesting link to and article called Who’s Searching for XML? by XML noteworthy, David Megginson.
David used Google Trends to compare and contrast where searches for certain technologies were coming from geographically. Have a look at a few:
Now look at these:
As David says, it’s totally unscientific. But if I were a young programmer trying to figure out where to invest my time, I might spend just a little of it on Google Trends researching who I’m likely to be competing with.
Back in November, I did a presentation for the XP West Michigan at the Atomic Object office in Grand Rapids. They’ve recently posted the talk to Google Video.
The talk was titled “Don’t Follow the Lemmings” and is a continuation of the thoughts laid out in my book, My Job Went to India.
It being on Google Video, you can watch it online (embedded here, in fact) or download it to your computer or iPod for off-line viewing (a discovery I’ve recently made which makes plane trips much more enjoyable).
Watching on an iPod should be fine, because there are no slides to squint at.
If that's the case, why was the customer involved all the time? They had a completely working specification in an already working system. Replacing it is more a matter of reverse engineering than gathering vision, customer feedback, use cases, stories, or any of the other crap the XP team used.
Here’s the problem: when does the label "Payroll System" become so broad that you don’t know if it’s an invention or an implementation? Could it be possible that at a huge company like Chrysler the payroll system was unlike any other payroll system that had ever existed? And, within the realm of this possibility, might it also be possible that Chrysler were redesigning the system, because through such changes as globalization and evolving international tax and labor laws, the system which was being replaced was no longer valid?
My point isn’t to say Zed is wrong. He makes some excellent points and may very well be right (though, knowing some of the guys on the C3 project, I’d guess they knew the difference between invention and implementation).
My point is that it’s not always clear cut which things are implementation and which are invention. Worse than being ambiguous, it’s often not clear that it is ambiguous. My experience says that most of the time, people doing the Big Rewrite will assume that they’re doing an implementation and will staff and estimate accordingly.
Most of the time, they’re wrong.
"Make it do what it already does." That’s a tempting and simple way to view software requirements on a rewrite project. After all, the system already exists. The question of "what should it do when…" can presumably always be answered with: "what it already does".
There are two major problems with this assumption. The first, and most disruptive, is that the programmers don’t know what questions to ask. This is especially true if the programmers weren’t the original developers of the system (most often the case on a major technology shift), but even a programmer who did the original implementation of a product won’t remember every nook, cranny, and edge case. What’s worse, with the fragile safety net of an existing implementation, programmers can easily oversimplify the interface, and assume they know the capabilities of the system. If a combination of drop-down selections results in a whole new corner of the system, how are they to know without stumbling onto it (or performing an exhaustive and expensive test cycle)?
If the software you’ve built is complex enough that it needs to be rewritten, it’s probably also so complex that it’s not discoverable in this way. This means that domain experts are going to have to be heavily involved. It means that requirements are going to need to be communicated in much the same way they are on a green-field project. And it means that, unless it’s only used as a supplement, the existing system is more a liability to the rewrite than an asset.
Optimistic programmers might think I’ve missed something important here. If you’re rewriting a system, you’ve already got the code. The code can serve as the spec, right? Probably not.
Based on my own experiences and conversations with thousands of software developers around the planet, I unscientifically conclude that almost all production software is in such bad shape that it would be nearly useless as a guide to re-implementing itself. Now take this already bad picture, and extract only those products that are big, complex, and fragile enough to need a major rewrite, and the odds of success with this approach are significantly worse.
Existing code is good for discovering algorithms—not complex, multistep processes.
This is the first in a series of articles, discussing why many software rewrite projects end badly and what to do to avoid some of the ways I've seen them go astray.You’ve got an existing, successful software product. You’ve hit the ceiling on extensibility and maintainability. Your project platform is inflexible, and your application is a software house of cards that can’t support another new feature.
You’ve seen the videos, the weblog posts and the hype, and you’ve decided you’re going to re-implement your product in Rails (or Java, or .NET, or Erlang, etc.).
Beware. This is a longer, harder, more failure-prone path than you expect.
Throughout my career in software development, I’ve been involved in Big Rewrite after Big Rewrite. I suspect it’s because I have an interest in learning eclectic computer languages, operating systems, and development environments. Not being just-a-Java-guy or just-a-Windows-guy has led to me becoming a serial rewriter. I’ve been on projects to replace C, COBOL, PHP, Visual Basic, Perl, PLSQL, VBX (don’t ask!) and all manner of architectural atrocities with the latest and greatest technology of the day.
In many cases, these Big Rewrite projects have resulted in unhappy customers, political battles, missed deadlines, and sometimes complete failure to deliver. In all cases, the projects were considerably harder than the projects’ initiators ever thought they would be.
This is not a technology problem. It’s not at all Rails-specific, but being in the limelight these days, Rails implementations are both very likely to happen and very risky right now.
So, why, in software rewrites, when you’re traversing exclusively familiar territory are the results so often unpredictable and negative?
For the next week, I’ll post specific reasons I’ve seen things go wrong. The following is a list which will eventually be made into links:
Stay tuned.
Highlights for me were getting to pick James's brain about how best to deal with multiplatform issues in RubyGems, learning about Rails internals from Marcel Molina, Jr. (I don’t think a presentation went by for the full 3 days without Marcel being asked some hard questions), and spending quality time with the Relevance guys for the first time.
(Like many of the best photos of Ruby/Rails events, Dave Thomas took this photo. Check out his photoset of the event. Lots of good ones.)
Overall, this is the event that I think is responsible for fully rejuvenating me after a short period of burnout. I can feel the wheels turning again and can’t wait until the next one in Reston. Being their home town, maybe some of the folks from InfoEther will make it.
The conversations on RubyGems and deployment issues spawned a new project which we’re banging away at. Hopefully we’ll have a release over the holidays (in between driving, eating too much turkey, etc.)
In a bizarre twist of fate, this interview places me in the company of Larry Wall, Damian Conway, Randal Schwartz, and the mononomenclad, ultra-prolific wonder, chromatic.
Here’s a fun bit of the interview, taken out of context:
Perlcast: This is Perlcast, so I have to ask: Is Perl a safe language to be an expert in? Me: Absolutely not. ... If Perl was going to be your only language right now, then I would be terrified. If you identify yourself as a Perl programmer, then I would be terrified.
You’ll have to listen to the whole thing to hear the shocking conclusion.
The Pragmatic Programmers are also giving away some FREE COPIES of My Job Went to India and All I Got Was This Lousy Book, so check out the Perlcast page for details.