Skip to content

Book Review: Your Money or Your Life

Your Money or Your Life by Joe Dominguez and Vicki Robin, is a collection of simple, common sense observations about money. Perhaps because money is so fundamental to our lives, or because we associate it with work, often we don’t examine these simple truths. But the first step to making sound decisions, about money as about every other topic, is to gather all the facts so you can make a knowledgeable and concious decision. This book helps you do that.

The book takes you through 9 steps to Financial Independence, from cataloging all the money you’ve ever made to keeping a budget to their solution for non wage income. The lessons are told in a easy, simple manner, with ‘real life’ stories interspersed throughout. Some of their most profound ideas aren’t about money, but about work–what human beings look for in work that they used to look for in community and family.

I’m a single guy, and I felt this book was aimed at big spenders with families, mortgages and boats, but I still felt there were lessons to take away. Their end solution is something I’m still up in the air about, but the steps along the way were fabulous–every one simple enough to understand, yet powerful enough to change the way you thought about the concepts discussed. I liked this book and would recommend it.

Scripting languages and productivity

Bruce Eckel has some things to say about different languages and productivity. One quote in particular stood out:

“I didn’t have to look that up, or to even think about it [reading the contents of a file using python], because it’s so natural. I always have to look up the way to open files and read lines in Java. I suppose you could argue that Java wasn’t intended to do text processing and I’d agree with you, but unfortunately it seems like Java is mostly used on servers where a very common task is to process text.”

I agree entirely. I come from a perl background (it’s the language I cut my teeth on, which, I suppose, dates me), and unlike some, I’m unabashedly in favor of it. I’ve looked at python briefly, and it does seem to have perl’s flexibility and agility with less ambiguity. When you have to grab a file from the filesystem (or parse a file and stuff it into a database) there’s simply no comparison, and anyone who reaches for Java to solve such problems simply hasn’t experienced the joy of the freedom of scripting languages.

The problem with such free form languages arises when you start doing large scale systems. Java, for all its faults and complexity, forces choices about implementation to be done at a high level–which framework do we want to use, how do we architect this solution. Perl (note that I’m not talking about python, since I’m a python newbie), on the other hand, is more flexible, and hence allows more latitude. It requires more discipline to code OO perl, or, for that matter, readable perl, than it does to code readable java. (There are different ways to implement objects in perl–see Object Oriented Perl for more information.) By limiting some of the latitude of the developer, you gain some maintainability.

I was trying to think of trivial examples that illustrate this point, but I couldn’t. Perhaps it’s because I’ve been out of touch with perl’s evolving core libraries for so long, or perhaps it’s because all the perl I’ve ever had to maintain has been intensely idiomatic, where all the java I’ve had to maintain has been, though at times obtuse, fairly easy to read, but I just feel that perl is a harder language to maintain than java.

Now, how does this apply to Eckel’s statements? Well, he uses python as his example–stating that you just plain can get more done with python than you can with java. It’s hard to argue with that…. But the majority of code expense and lifecycle is not in the creation but the maintenance. How do the scripting languages stack up for large scale systems? My experience (which, granted, is primarily applicable to small to medium size systems) indicates that the very flexibility which allows Bruce such amazing productivity hampers further enhancements and bug fixing on the code he writes.