Sometimes I hate being right.

So two days ago, somebody posted this satire link to lily. It's a joke about how Planned Parenthood is opening an $8 billion abortionplex.

My comment: "I give it no more than 2 days before it's being forwarded around as The Truth."

It is now two days later.

I hate being right.

A Modest Proposal

Given the Bush Administration's War On Birth Control, we clearly need a solution that all parties involved can agree on. Since people, for some odd reason, refuse to stop having sex, and various soi-disant conservatives refuse to keep their noses out of other people's sex lives, we need to find some middle ground.

I think I've found it. It's simple and effective.

If a health-care practitioner chooses not to provide birth-control services to a patient, they must take financial responsibility for the results.

So, if the patient chooses an abortion, that health-care professional gets to pay for it.

If she chooses to have the child, that health-care professional gets to pay for the pregnancy and labor, and then gets to pay child support. Full support for the child, including schooling, food, shelter...the works.

If she chooses to give the child up for adoption, that health-care professional gets to adopt the child. After all, they're the one who made the choice that it had to be born. They must have wanted that child to be born quite a bit, right?

The people who want this sort of ability to impose these choices on others should have no problems with these rules. After all, it's just putting their money where their mouths are. And it's a much nicer proposal than, say, Swift's original Modest Proposal.

Things We Don't Need Any More Of #2

iPhone tip calculators.

Especially ones that people want to charge money for, but I think we've got enough free ones now as well.

Really. Yes, it's a vaguely interesting introductory project. That doesn't mean you need to try to sell it.

A quick search of the App Store for 'tip' finds 18 items that look to be tip calculators. 4 of them are free. 11 cost $0.99, and 2 cost $1.99.

The last one costs $4.99...and that one is the only one I'd consider paying for. (International Tip Calculator, which includes information on expected tipping practice around the world. Now that is useful information for the world traveler...and if I expected to need it, I'd consider buying it.) In other words, it's not just a quick-and-easy way of calculating 10-20% of a given number.

So, can we find something else to use as our demo project now? (Not Sudoku. We're at 24 of those now. Although the issue there is that about 1/3 of them are free 'lite' versions of another 1/3.)

At least we aren't getting more flashlight apps.

I hate computers.

So, the old Powerbook that's acting as a media machine has been running off a Firewire drive for a while because the internal drive started acting up.

Now the Firewire drive started having problems as well. Unfortunately, I don't have any spare drives that are large enough to hold all the data on that drive. So, we'll try setting it up to run off a smaller drive (in the same Firewire enclosure) and set up a reduced-size library until we can get things fixed. No problem, right?

Well, the optical drive isn't terribly happy either, so it can't boot the install DVD. Tried to install onto the new Firewire disk from the MacBook Pro, but as an Intel Mac, it can't install to a disk that's bootable on an old PowerPC Mac. Grah.

Ended up installing to a USB drive that was partitioned for Intel booting, doing a drive-clone from there onto the Firewire drive. Then had to swap things around again because the smaller disk I had in the Firewire enclosure started acting up.

Now, about 7 hours after I started, the newly-installed OS is finally at the point of updating to the latest version. And then I need to get the music set up on it as well, and find out if I lost any data on the old drive. Guess I know what I'm doing tomorrow.

Things We Don't Need Any More Of

#1 in a continuing series. (Collect them all! Trade them with your friends!)

Anyway:

Rock songs about how awful the touring life is.

Sorry, folks. This is the life you chose. Yep, it's not all wonderful. Get over it.

(Besides, whatever you're trying to say, there's a damn good chance Jackson Browne already said it better.)

Things I Hate About You Detour: Medical Insurance

Monthly birth-control pills? Covered.
Viagra? Covered.
Pregnancy and childbirth? Covered.
Abortion? Covered.
Sterilization? Covered.
Infertility? Covered.

IUD? Of course not. Why would we want to cover that?

Things I Hate About You #3: Python

This one's tougher, because my Python isn't anywhere near as good as my Perl or Java.

1. Whitespace - Low-hanging fruit. The whole whitespace thing is Python's bugaboo the way that speed is/was for Java and a resemblance to line noise is for Perl. But there is still something here, and not the usual "OMG it makes me indent!" that shows up. The problem is that using whitespace as the delimiter causes issues when modifying code later. A very, very common maintenance idiom is taking a block of code and wrapping it with an if statement because you've found cases where it shouldn't be run. In C-styled languages, when using emacs, the usual way I've done this is to put in the if statement, then walk through the code, reindenting each line with the tab key, until it's time to close the block. In Python, if you try this, you will screw up the indentation for each block inside the new block you're creating. More generally, programming in C-styled languages in emacs teaches you that re-indenting with tab does not semantically change the program; that's no longer the case in Python. (Other editors generally have similar concepts; it's not just an emacs thing.) Or, in the general case again - if you lose leading whitespace in a Python program somehow, there is no automatic way to get it back. (This can happen with a bad translation to HTML, a funky mail filter, or many other ways.) Now, there are ways to work around this (ending all blocks with 'pass', '#end if' comments, etc.), decent editor support makes it less of a problem, and there are advantages to Python's approach, but it's not without its issues as well.
2. PyGTK - Not entirely Python's fault here, I suppose, but PyGTK is quite possibly the least intuitive, most annoying GUI toolkit I've ever worked with. (And, remember, I've worked with both Java AWT and Swing.) GtkTreeView in particular is just plain twisted.
3. Python People - Mention #1 to a Python advocate, and...hoo boy. Python's got some damn good Kool-Aid, I guess. Any mention that there is possibly a problem with using whitespace as the delimiter is met with either blaming the user ("Well, clearly you shouldn't be editing that way, then") or shifting the issue ("Well, you'd have to fix the indents anyway, right?") and missing the point that making whitespace significant causes issues of its own.

A relatively lame list, I think. Clearly I need a few more years working in Python to build up some good hatred for it.

Things I Hate About You #2: Java

So - Java. Most of the folks who hadn't worked in Java would mumble something about speed or lack of native compilation when asked what they disliked. Now, I'm just coming back into Java development after being away since about 2000, but from what I've seen so far, these items still haven't improved much...

1. TMTOWTDI (poorly) - The Perl motto is "There's more than one way to do it", and it (mostly) works well in Perl. You've got several ways to do something, and can choose the appropriate one for the task you're dealing with. Java, on the other hand, has far, far too many cases where they implemented one way to do something, realized it was wrong, implemented a second while leaving the first one in place. They can't just remove the first one, because it's embedded in other parts of the API, so it just...festers. The worst example of this is java.util.Date, which has 6 constructors (4 of which are deprecated) and 27 methods (17 of which are deprecated)...you can't just use Calendar everywhere, so you have to change back and forth between Date and Calendar all the time. In particular, if you're using SQL, java.sql.Date and its kin are all subclasses of Date, but you can't get any information out without using a deprecated call or converting it to a Calendar. (So what's the solution? JodaTime, of course! Replacing a broken API with another incompatible one is the Java Way!) Other examples: there are three separate UI systems now (Java 1.0.2 AWT, Java 1.1+ AWT, and Swing), there's the whole Reader/Writer vs. InputStream/OutputStream issue (now with Channels to make life even more confusing), HashTable/Vector vs. Collections...and those are just the ones off the top of my head. The biggest advantage that C# has is that Microsoft was able to learn from Sun's mistakes and not have as much deprecated cruft cluttering their APIs.
2. Make the simple things simple and the hard things tedious - A pattern I've run into several times in Java: "To make this work, you need all these other objects to be in place...a convenience method is provided for the common case." And so, as long as you're doing exactly what the programmers expected, it's easy...and as soon as you wander even a little bit off that track, you need to do everything manually. Places I've run into this include Swing (JTable, specifically, as I recall) and security/cryptography (adding a new trusted key for an SSL connection).
3. Frameworks upon Frameworks - Java EE is, apparently, built around the idea that if you have enough frameworks, every problem will come out of them eventually. Er, no, it's build around the idea that the solution to every problem will come out eventually. (In practice, it seems the first statement was more accurate, though.) Why I Hate Frameworks sums this up better than I can, though, so I'll let them have it. True story: I went to look into how to use a particular framework at work. Lo and behold, this framework in and of itself is an agglomeration of seven external frameworks plus four more internal frameworks. Now that's Enterprise.

I'd be interested to hear what other Java developers would choose for their three items.

Things I Hate About You #1: Perl

An interview question we used to use to separate the posers from the folks who knew their stuff was "Name three things you dislike about Java". The idea is that if you've seriously worked with a language, you've run into several things about it that drive you nuts, but if you've just poked at it a bit, you're likely to spout a few superficial things like "...it's slow..."

So, I'm going to work through this for a few programming languages. Today's victim: Perl.

1. Perl 6 - An interesting comparison: Python 2.0 was released about 3 months after Perl 6 was first announced. In that time, Python has released 6 versions (2.0 to 2.5), announced Python 3.0, and released 5 alpha versions of Python 3.0 with a scheduled release of 3.0 in September. Perl has released a few partial versions, has a partly-written virtual machine, and no planned release date. To be honest, Perl 6 reminds me of everything I've heard and seen about ALGOL 68 - a Byzantine language spec that tried to be all things to all people, with the end result of killing off the parent language (ALGOL 60). The best result we're likely to see out of Perl 6 is the backports into the Perl 5 project, but it took far, far too long for folks to realize that Perl 6 itself was a dead end and begin reviving Perl 5.
2. CPAN - CPAN is a great idea: a single repository for user-contributed modules with a handy front-end and dependency-handling. Unfortunately, both of those systems fail. As a single repository, it's great...until you try to actually find anything in it. Say, hypothetically, that you wish to read a CSV file. And so you go to CPAN and search for CSV...and get 261 results. Which do you use? There's a small amount of guidance now, with ratings and reviews starting to show up...this is a vast improvement over before, where you had literally no indication, but it's just a start. (And CSV is a small example; try XML, which has a FAQ list just about finding which one of 14 XML modules is the right one. A search for XML finds 3522 matching modules.) As a front-end, it's also great...until you run into a mandatory upgrade of some sort. Fortunately, they seem to have fixed the issue where it would try to upgrade Perl on you...
3. Non-Obviousness - There are a lot of cases where what Perl is doing is extremely not obvious to anyone who hasn't spent a lot of time programming Perl. (I've commented elsewhere that Perl is an extremely difficult language to be an expert in, because it's got so many odd edge cases.) Basically, Perl tries to guess the right thing for you...this is great when it guesses right. When it guesses wrong, tracking down the problem is a major pain. Examples include autovivification, scalar context vs. list context, true/false vs. defined vs. exists... There are also a lot of cases where Perl is egregiously Different for no readily apparent reason. (break/continue vs. last/next, switch vs. given - especially egregious since the 'given' statement needs to be activated with "use 'switch'") And let's not even get started on the punctuation variables. A lot of these things are hacks nested upon hacks, where the 'obvious' original use wasn't as obvious as they thought and a new addition had to be made for cases outside the original plan. (Example: lists cannot contain lists. Solution: references. So now you've got all the fun of C pointer manipulation.)
   

Several of these could be expanded out further. Now, in practice - I like Perl, and I'm reasonably good at it. (I can't consider myself an expert, though - still too many odd edge cases I don't know about yet.) But...well, there's a reason I'm trying to do quick hacks in Python now. (Python's list of problems is coming later this week.)