Posted by Brian
Last week I decided to do something I had been toying around with for a while and launched a new website, www.curmudgeonlysoftware.com. This will be the new home for all of my software related postings and this blog will be where I post everything else. Essentially it’s a professional vs. personal divide. My most commonly read articles are by far software related, so splitting this way should do most people a favor.
Existing technical posts that have value to others will be redirected to Curmudgeonly Software. I will probably get around to sorting that out this weekend. For now, you can see the next post in my From C# to Perl series on the new website, this time on performance. Also, I have been working on an implementation of tetravex in Perl with SDL that I will be posting on soon. For now you can find the code at github.
This site may also be changing over to WordPress sometime in the near future. When I started this site I chose Typo because I was doing some work with Rails, and because WordPress was becoming the target of more frequent attacks. However, I tried WordPress for Curmudgeonly Software and it is so far and away superior that I’ll probably switch this site as well.
Posted by Brian
Edited By Andy Oram & Greg Wilson
Beautiful Code is a collection of essays from programmers working in a number of different areas, from language design, to operating systems, to enterprise application development. If you are a programmer, chances are good that at least a couple of essays in here will appeal to you.
First, the good. Some essays are great. Yukihiro Matsumoto, the creator of Ruby, has arguably the best (and shortest) essay in the collection, concentrating on what makes code beautiful and how those factors influenced his design of Ruby. Elliote Rusty Harold’s contribution on lessons learned creating XML verifiers is also a standout. He goes through several implementations, learning from each to improve the performance of the next, all while maintaining correctness across all cases. Charles Petzold’s description of on-the-fly code generation for image processing is dense, but interesting. As a sometimes Python programmer, Andrew Kuchling’s discussion of the design trade-offs in the design of Python’s dictionary implementation was much appreciated and gives insights into performance optimizations you can make with your application if needed.
Unfortunately there is also a fair amount of bad. One issue is that the book is simply too long. The editors mention they got a more enthusiastic response from contributors then they expected. They may have felt compelled to include all or most of the responses. But beyond the length, some of the essays are just bad. For example, Douglas Crockford’s “Top Down Operator Precedence” essay dives right in without actually explaining the algorithm. It is explained piecemeal throughout the code, but you never get a good feel for exactly what is going on. Other contributors have the view that whatever skills they need to do their work is essential to being a true software engineer. For example, Bryan Cantrill writes that postmortem debugging with core dumps “is an essential part of our craft - a skill that every serious software engineer should develop.” Quite honestly, only a very narrow niche of software engineers are serious then. Other authors take similar narrow views at times, whether it is the author of math libraries feeling that everybody needs to care about high performance computing or C programmers feeling that every real programmer should implement their own dynamic dispatch code in C at some point in their careers.
Beautiful Code is worth the read, but don’t hesitate to skim over the essays that don’t interest you. I probably would have enjoyed it more if I didn’t force myself through most of the them. (Also see Jeff Atwood’s review for a good explanation of why the title of the book is misleading.)
Posted by Brian
Well, my goal this year was to cut back my reading and I somewhat succeeded. I only read 44 books in 2010, but I saved a lot of time by not writing reviews for most of them. Here’s the list for the year, with links to the ones I have written a review for at this time.
- Open Sources 2.0 Edited By Chris DiBona, Danese Cooper, and Mark Stone
- The Mythical Man-Month By Frederick Brooks
- The Innovator’s Dilemma By Clayton Christensen
- Predictably Irrational By Dan Ariely
- The Cluetrain Manifesto By Rick Levine, Christopher Locke, Doc Searls, and David Weinberger
- The Greatest Benefit to Mankind: A Medical History of Humanity By Roy Porter
- Ender’s Game By Orson Scott Card
- Guns, Germs, and Steel: The Fates of Human Societies By Jared Diamond
- The Future of Ideas: The Fate of the Commons in a Connected World by Lawrence Lessig
- The Stand By Stephen King
- Biobazaar: The Open Source Revolution and Biotechnology By Janet Hope
- The Drawing of the Three: The Dark Tower #2 By Stephen King
- The New Complete Joy of Homebrewing By Charile Papazian
- The Complete Stories: Volume 1 By Isaac Asimov
- Neuromancer By William Gibson
- Count Zero By William Gibson
- Mona Lisa Overdrive By William Gibson
- In Defense of Food: An Eater’s Manifesto By Michael Pollan
- The Waste Lands: The Dark Tower #3 By Stephen King
- The Dilbert Principle By Scott Adams
- Wizard and Glass By Stephen King
- Wolves of the Calla By Stephen King
- The Song of Susannah By Stephen King
- ‘Salem’s Lot By Stephen King
- The Dark Tower By Stephen King
- The Red Thread of Passion By David Guy
- The Cathedral & the Bazaar By Eric Raymond
- NurtureShock By Po Bronson and Ashley Merryman
- Capitalism, Socialism, and Democracy By Joseph Schumpeter
- Sex at Dawn By Christopher Ryan and Cacilda Jetha
- Innovation Happens Elsewhere (Did not finish)
- Effective C# By Bill Wagner
- More Effective C# By Bill Wagner
- Programming in Scala By Martin Odersky
- Foundation By Isaac Asimov
- Foundation and Empire By Isaac Asimov
- Second Foundation By Isaac Asimov
- Dr. Kinsey and the Institute for Sex Resarch By Wardell Pomeroy
- Pain: The Fifth Vital Sign By Marni Jackson
- Programming Perl, 3rd Edition By Larry Wall, Tom Christiansen, & Jon Orwant
- Joel on Software By Joel Spolsky
- Listening To Prozac By Peter D. Kramer
- Songs of Distant Earth By Arthur C. Clarke
- Speaker for the Dead By Orson Scott Card
Posted by Brian
Let’s talk about readability. It’s a fact that code is read far more often than written. Listening to the Perl community, you would think that it is the most readable computer language ever devised. Larry Wall loves to talk about linguistics and applied some of his knowledge on the subject when creating Perl. The result was… interesting.
Waste No Keys
How many keys does your keyboard have? Want to use a language that seems to go out of it’s way to find a use for every one of them? Perl favors terseness over readability to almost a pathological point. This is exemplified in its use of magic variables. You can find a full list of them here. Now imagine reading a code base that uses any significant fraction of them. To be fair many of them are almost never used. Even seasoned Perl hackers would have to look them up. Also, you can see in the documentation that they also have readable aliases. If you are using any of the obscure ones you should probably use the alias instead.
On a related note Perl seems to have inherited from C the almost pathological need to abbreviate. C system code tends to abbreviate variable names to the point of confusion if you aren’t familiar with the codebase. Perl programmers seem to carry this over into non-system code. I’m a big believer in Domain Driven Design, which states as one of its tenets that you should speak the same language as your users. This should carry over into your code. Once again, when I come back to a codebase six months from now I don’t want to have to think about what that abbreviation was for. Sometimes you can save too many keystrokes.
Perl gurus often seem to highlight the fact that their language is closer to natural language than most. They consider this to be A Good Thing. I don’t. Natural language is messy, ambiguous, and full of nuance. I want my code to be as clean, clear, and straightforward as possible. If this comes at the expense of succinctness, so be it. I’m writing this code once. Others (and me) will be reading it many times. This is one reason any scientific field of study comes with its own jargon. The goal is to eliminate as much of the ambiguity as possible by distancing itself from natural language.
In contrast, the foundation of C#’s syntax comes from the C/C++/Java model. I don’t find anything inherently superior to this syntax (it is pretty dominant though), but one thing it does not suffer from is ambiguity.
This is where I feel readability suffers the most. Perl’s motto of There’s More Than One Way To Do It encourages significant fragmentation of what are built-in concepts in other languages. For example, there are countless different modules to write object-oriented code. Perl5 has a half-assed OO implementation, leaving it up to module writers to provide most of it. This means that you can have considerable Perl experience but stumble upon a code base that looks like nothing you have seen before. A Perl developer using Moose might as well be writing a different a language.
However, this could be an advantage if you wish to define any sort of DSL, something that is difficult at best to do in C#. Most C# programmers who wish to define a DSL are best served to learn Boo), another language that runs on the .NET framework that is much better suited to the purpose. A true DSL is also difficult in Perl though. The closest I have seen so far is something like Moose, which looks like a DSL in parts. To contrast with another language, before learning Perl I was working with Scala, which through the use of some advanced features allows you to easily define a DSL. To a user it simply looks like you defined new keywords.
To a large extent readability comes down to what you are used to so of course C# is more readable to me right now than Perl. However, some of these issues have nothing to do with my lack of Perl experience (such as pathological abbreviating). Some of the Perl community recognizes these problems. There seems to a sharp divide between traditional Perl users and a group that prefers to use what it calls Modern Perl. Put me in the modern camp.
Posted by Brian
One constant in my life is that I have a tendency to become a jack of all trades, master of none. I read voraciously across a range of topics, but rarely delve extremely deep into any topic for an extended period. If I hadn’t have hurt my arms I was planning to learn several more instruments in addition to bass guitar. I doubt this would have left time to be really good at any of them. I’ve only scratched the surface of hobbies such as woodworking, electronics, and yoga and find myself getting back into video games instead of delving more deeply into any of those.
What I can’t decide is if this is a good or bad thing? Right now I don’t have any other languages I’m itching to learn (Although it would be nice to relearn Scheme and Elisp. I didn’t even list those above), but I would like to dive more deeply into some I have only scratched the surface of. The problem is that it simply isn’t possible to learn so many languages and related tool sets in depth without investing large amounts of time. Right now all that time is being taken up diving deeply into Perl. For now, I’m just not going to worry about it.
Posted by Brian
I mentioned in my last post that I was learning Perl in the hopes of landing a job. Well, that has now paid off as I will be starting at Summersault next week. I’m pretty excited to get out of working with Microsoft tools. I was worried about getting pigeonholed into that if I took another job with it. While C# is a great language, my moral objections to Microsoft’s business practices far outweigh my love of C#. Now I get to work with a variation of the LAMP stack (FreeBSD, Apache, PostgreSQL, and Perl) as part of a small team. And other people can actually see my work this time. That was sometimes frustrating when writing internal web apps.
This change may effect my open source work with Trac. Summersault does not use it internally (RT seems to be the standard with Perl). Up until now LSR’s use of it was a major motivator for me to get involved. We will see if I am able to sustain interest when I am not using it on a daily basis. If not, I will put out a call for someone to adopt the batch modify plugin. The whiteboard plugin will probably just die. I can’t see anybody else wanting to put the necessary work into it.
Posted by Brian
Due to my lack of posts here I have now scheduled writing time every night for at least a half hour. So far this has proven fruitful. I’ve been hard at work writing a series of posts to finish up My Lombardi Experience. I want to focus on why our BPM experience failed with the hope of preventing other teams from failing in the same way. Right now I have a lot of material that needs massaged into something that I am comfortable posting.
Book reviews may resume as well, but only for those I feel that deserve it. Previously I had been writing something for every book I read, but that became a pain in the ass. The goal was to read less this year, but I still am going to end up in the low 40s. I read one a week last year, so I guess it still counts as less though.
On the coding front I’ve mostly been busy learning Scala and … Perl. That one was certainly a surprise, but a job opportunity came along that required me to learn it. Now hopefully I actually get the job. Unemployment is getting boring. I may write more about Scala and Perl later, but they are so alien to each other that I haven’t even attempted to compare them yet. I can’t imagine too many programmers go from C#, to Scala, to Perl.
Taking the time to learn two new languages has caused my open source work to recede into the background for now. The Trac whiteboard plugin may languish in prototype phase for quite some time now. An Indian company did express interest in hiring me to extend it for their needs, but that never materialized. The batch modify plugin may get some love early next year. I am currently looking at making it aware of custom workflows, but doing so will require a major rewrite. I already started it once, but left the codebase a mess, so I’ll probably start from a new branch.
Posted by Brian
My wife is starting a new job on October 18, which means that I will have to quit my current job. We will be moving to Richmond, IN which means I will be looking in Dayton, outer suburbs of Cincinnati, possibly Indianapolis, and anywhere in between. Telecommuting is also an option. You can find my CV on StackOverflow or download it as a PDF here.
Posted by Brian
I have started work on a new plugin for Trac that will provide an whiteboard view of query results. It doesn’t do anything yet, but you can check it out at Trac-Hacks. The ultimate goal is to provide a kanban-style view of your query results with drag-and-drop support for changing a ticket’s status.
Posted by Brian
The Drawing of the Three (The Dark Tower #2)
By Stephen King
I really need to get better at writing these as I read the book. I think at least apart of the problem is that I don’t take any notes when reading fiction and that is what the majority of my reading has been the last few months. I finished this months ago and am now on the 5th book in the series, Wolves of the Calla. The Gunslinger had felt like a 300 page prologue so I wasn’t quite sure what to expect here. I ended up being pleasantly surprised.
King’s style is again quite visual and I had no problem with visualizing each setting in considerable detail. The gun fight with Balazar’s men is especially vivid. Also, King starts sprinkling in more language from Roland’s world in a highly effective manner. The light sprinkling serves to accentuate the the line between Roland’s world and ours while giving more weight to the terms. Simply stating that it was destiny instead of “ka” would not focus the reader as intently on Roland’s view of his quest.
The series is starting to show some minor cracks with where I am in my reading, but at the conclusion of The Drawing of the Three everything fits together very neatly. Highly recommended.