Saturday, January 31, 2009

A Better Economic Stimulus Package

At the time of this writing, we here in the U.S. face double-digit unemployment and record national debt and budget deficits, with no sign of any of the above ending any time soon. An economic package that will ease the near-term pain is being discussed. Justin Raimondo, the guy, has made an excellent suggestion for a stimulus package that won't increase the deficit. But we're not advocating that here because it's reactionary, and we're in tune with modern economics.

Instead, I say that the economic stimulus package being discussed doesn't go far enough. If we really owe the money to ourselves, and China, Saudi Arabia and Japan will really loan us as much as we need, why stop there? Why not go all the way and give every household in America a million dollars? That would really stimulate the economy. Consumer spending would skyrocket. It's not real money right? Like my friend at work says, it's all abstract anyway, and worst case, we just repudiate the debts and start over with a new currency. It could work, couldn't it?

If you've been following along, you could reasonably conclude that you've been led down the garden path. Let's not talk about the obvious hyperinflation this program would cause. After all, nobody I talk to about this seems to believe that it could happen here. Let's talk about the recipients of the stimulus money. If they do the right thing with the money, namely pay off their debts and invest the rest, they will be in position for a modest income for life. They won't work any more, and, talk all you want about jobs being moved offshore, there is still plenty of work here that needs to be done. On the other hand, they could do what most people who win the lottery do: spend all of the money and end up broke again. In this case, the economic stimulus will be temporary at best, and the money will end up in the hands of the wealth as usual.

Now you may think that it's harmless to do these things as long as they're not done to such an extreme level. Most people would agree with you. But at what point does it become extreme enough to be harmful? Is a trillion-dollar deficit really moderate enough to be harmless?

Tuesday, January 27, 2009

Tilton's Law: Not Just for Computers

The post linked above is an excellent programming war story which may not mean much to you unless you work with computers for a living, the story has some lessons that can be applied with profit to life in general.

First: whenever you spend hours or days wrestling with a difficult problem, the answer is invariably some stupid little thing that you either forgot or didn't know about, so you may as well check for that first and save some time.

Second: as Mr. Tilton says in his post, "You can run, but you cannot hide." This is especially true when it comes to marriage, as most of the people I know who are divorced broke up as a result of issues that were readily apparent before they got married.

Finally, Tilton's law: "Solve the failure first." Failure provides an excellent opportunity for learning. Take it.

Monday, January 26, 2009

You Don't Have the Right to Your Opinion

If you're like most Americans, you were told many times that "everyone has a right to their opinion." In a legal sense, that's true, although expressing that opinion can sometimes have negative consequences for your career: for example, if you're a meteorologist, expressing skepticism about the human-induced climate change theory is essentially career suicide. But it's not really accurate.

If you research a subject intensively and get information from multiple independent sources, then you do in fact, have a right to your opinion because you've earned it. But what if you haven't done the research? Or what if all your sources draw the same conclusion and you haven't considered any alternative viewpoints? Or if your opinion is just "common sense?" In that case, you do have an opinion, but it's not really your own. Especially if it's just common sense, because that usually means that it's so obvious to you given what you've seen and heard that any opposing viewpoint is simply inconceivable.

So do you have the right to your opinion? Yes, but sometimes "I don't have enough information to know for sure" is the correct answer.

Friday, January 16, 2009

Haskell Names Considered Helpful

I've been working on a SQL parser and pretty-printer in Haskell to help me in my duties as a DBA. After using Parsec, I will never go back to lex and yacc if I can help it. Like most Haskell newbies, I had a hard time with monads at first. I also struggled with the type system, but now I find that it actually makes things easier, especially refactoring.

There's a very active thread going on at fa.haskell about a blog posting linked to in the header. It's a very good article, especially the bit about data being code. But I have to take exception to this part:

One thing that does annoy me about Haskell- naming. Say you’ve noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell’s tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I’d be inclined to call it something like “Appendable”. But no, Haskell calls this pattern a “Monoid”. Yep, that’s all a monoid is- something with an empty state and the ability to append things to the end. Well, it’s a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them “monads” instead of “warm, fluffy things”. Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you.

My feeling on this is that using a name like "Appendable" instead of "Monoid" because Appendable is more intuitive is exactly the wrong thing to do. If you see the name "Appendable" for the first time, you think you know what it is. Unfortunately, in this case, the definition you would assume the name has is incomplete at best. However, you don't know that because the name is intuitive, so you don't look it up. Not yet. But you may have to later when you find out that it doesn't exactly do what you want, or you may never have to, which is worse because you won't find out what else it can do.

This is actually an example of a larger trend in computing: making things intuitive and easy to understand for beginners is given a higher priority than developing in-depth knowledge and making tools that are fast and efficient to use for experts. And that's O.K. for the mass market. If you're just writing CRUD screens in VB, C# or Java, then just knowing enough to get by is fine, but you wouldn't be interested in Haskell anyway.