Going retro

Blocks in Java and C#

James talks about some syntactical sugar enhancements that can be made to Java borrowed from C#. Although it sounds petty, this stuff really makes a difference when you’re staring at code all day. Clean and readable code makes for relaxation which makes for smarter thinking. Syntax is closely related to karma.

The foreach and using operators are particularly nice as it provides a cleaner sequence for commonly executed sequences of events. But why stop there?

One of the features that made Smalltalk and Ruby so popular was the use of blocks. These allow you to create your own constructs.

Having (finally) twisted my brain far enough to start to understand Perl, I’m actually starting to appreciate it. This alone should probably scare me. It is (proudly, deliberately) a derivative language.

Perl shamelessly borrows paradigms from C, C++, Lisp and a few Unix tools. I’m still learning, but it looks like a lot of the AOP, block/closure & attribute stuff could easily be (or has already been) implemented in Perl, and has been available for years. I sometimes wonder if language designers are doomed to reinvent things that some guys over the road already implemented a decade ago.

Take this:


my $block =
sub {
my ($target) = (@_);
print "Hello, $target!\n";
}

Dangerous Perl Oversimplification 101:

my is like ‘private’.

$ means ‘scalar’ – essentially a single variable.

my ($target) = (@_) means (roughly) ‘take a copy of the first argument and assign it to $target in list context’.

$block now holds a reference to a function that will print a greeting every time it gets called. You can treat it like any other kind of variable, including sticking it in an array, or indeed a hash. Dynamic dispatch becomes a simple matter of using your arguments as the key to a hashmap. Yes it can be done in strongly typed languages with some creative use of interfaces and the Command pattern. The point is, its built-in, and has been for some time.

Why is Perl hard?

  • Well for a start, it has no grammar. You can’t generate a parser for Perl, its too irregular.
  • It is contextual. Like English, meaning can vary depending on the topic of conversation. For example, if I ask you “where are you going?”, and you replied, “to the shops”, we would both know that it was you we were talking about, and that you were going to the shops. Perl is a bit like that. A lot of those evil looking magic variables are to do with this. $_ is essentially the ‘topic’ under discussion. Unless told otherwise, most Perl operators assume $_ which is one of the biggest hurdles to overcome when learning Perl.
  • Perl is laid-back. So lines like ‘unless ($flag) {return 0};’ can also be written ‘return 0 unless $flag;’.

XP in Perl?

Can be done, of course. In a language as powerful and undisciplined as Perl, the discipline of XP is more important than ever. Refactoring will be harder than in other languages, possibly so much so that the (heretofore undiscovered) ‘refactor to other language’ may need to be applied. Test first is more rapid than in languages with a compilation step as you might expect.

One of the most compelling reasons to use Perl? CPAN. As has been said elsewhere, the true strength of many modern languages lies in the extent of their libraries. Chances are, if you need to do something in Perl, someone else has already done it and put it in CPAN. Something that made me laugh today is the Date::Manip module, which can parse strings like “second wednesday in 1996” to date values.

Take a walk on the wild side.

Book buying bonanza

The GoF Design Patterns of enterpise application development.. I just got my copy of Martin Fowler’s Patterns of Enterprise Application Architecture. I can best describe this as the GoF Design Patterns of enterprise application development. Beautiful book. I followed the public review process on his web site very closely. Martin’s style makes for such an easy read. I see this being a staple of any serious developer’s bookshelf.

I’m off to Ireland to drink my Thanksgiving dinner. Bet your ass that this book will be in my carry-on. [crazybob.org – web log]

Just placed the order for my copy. I’ve been following its evolution on Martin’s site for over year, so it seemed only fair.

Written any good books lately?

Michael Feathers of Object Mentor has started writing a book (currently) called Working Effectively with Legacy Code. Everything you need to know about tackling that aspect of software development that most of us spend a large chunk of our time on, and would probably rather we didn’t have to. Excellent stuff.

Follow its development, and discuss refactoring in general at the ‘refactoring’ yahoo group here.

XP Misconceptions

This

article makes for an interesting read, but it suffers from a common

misconception about agile methods and planning. Namely that Agile doesn’t do

planning. I’m more familiar with XP than the other agile methods, but as far as

I know, none of them claim that ‘planning doesn’t work so lets throw it out’, as

the article states. There’s even a book called “Planning Extreme Programming”,

by Kent Beck and Martin Fowler. What XP does recommend is that you should have

just enough planning/design/whatever for your specific needs. Its about

removing anything that doesn’t add value to your process.

The shroud of the dark side is falling

I like Perl. I feel like I should go to a meeting or start a 12 point plan or something. I’ve volunteered to work on a project at work that is using Perl, as I’ve wanted to see it in action for a while, and I have to say that it is scarily seductive. It just does what you want and gets out of the way. Provided you know how to tell it what you want.

One thing in my defense: I am entirely unconvinced that there should be ‘More Than One Way To Do It’. I got terribly confused with some date manipulations due to the ‘localtime’ function returning zero-indexed (0-11) months, and the Date::Calc module expecting 1-indexed (1-12) months. Sometimes its just easier to have Only One Way To Do It.

The OO stuff also looks like a dodgy aftermarket bolt-on…

Language Loss

Books and Words

Learning another language is tough. Amazingly tough. Cedric is going to post about accents some other day, which should be interesting. My accent in Spanish is horrible… I feel for the people who have to try to have conversations with me every day. I need another 3 years here at least.

-Russ [Russell Beattie Notebook]

Learning another language is certainly tough. Knowing that you used to speak one and can no longer is also a bummer. Its hardly my fault – I was 5 when we left Brazil. But when my parents recount stories of how my mother used to get me to translate for her, I feel gutted that I have (apparently) utterly lost all my Portugese. I would love to go to Brazil or Portugal to work just to see if I could regain my childhood facility with the language, but unfortunately its hard enough to maintain a software career in your native country currently, let alone try to make a go of it overseas. Darn.

Nullify Nasty Negotiators

Kept Waiting. Karen wants to know how to handle being persistently kept waiting by lawyers and accountants. [read more] [Tony Bowden: Understanding Nothing]

I hate negotiations, mostly because I’m not very good at it. Or perhaps its because the majority of my experience has been with people who do it for a living (car salesmen, estate agents etc.) and are therefore a lot more experienced at it than I am. Either way this link makes for an interesting read. The best way to prepare for a negotiation is to understand what tactics might be employed against you and how to deflect them, while resisting the temptation to try and be underhanded yourself. About the only thing I hate more than negotiation is dealing with a dishonest negotiator.