Lars Wirzenius: Rant, 2006
Contents
- June 06: SMS and e-mail tax in the EU
- February 03: Followup to seven secrets, Secrets of Successful Programmers
- January 04: Bugzilla
Tuesday, June 06, 2006
Rant: SMS and e-mail tax in the EU
The European Union wants to tax SMS and e-mail messages (see digitoday news in Finnish). Or at least the French MEP Alain Lamassoure has suggested that, it seems. The tax would be 1.5 cents per SMS, and 0.00001 (one hundred thousandth) cent per e-mail.
Current prices in Finnish operators seem to be around 7-10 cents per SMS message. A 1.5 cent tax on top of that seems pretty high. Collecting it would be simple: all SMS messages go through operators.
For e-mail, however, the thing is going to be a nightmare. Much e-mail goes not via operators, and there is no good way of tracking it. This could be fixed (from the tax collecting viewpoint) by requiring all e-mail servers to be registered for proper accounting (nevermind freedom and privacy).
Update: This paragraph is rubbish, due to my inability to calculate simple things; I'll keep it here in the interest of historical accuracy (randomly changing already published log entries is impolite, to say the least). Anyone operating a busy mailing list will want to move it outside the EU. Even at such a low price, a list with a thousand subscribers and a hundred messages a day is going cause a tax burden of around four hundred euros a year. A company might be willing to pay that; a free software project would probably not.
Friday, February 03, 2006
Rant: Followup to seven secrets
My friend Kenneth "Cessu" Oksanen, who has only recently started writing a web log, wrote a response to my previous log entry: YASSSP = Yet Another Seven Secret of Successful Programmers.
I have no further comments on Cessu's list. I think it's a swell list.
Rant: Secrets of Successful Programmers
The Seven Secrets of Successful Programmers article was on reddit today. I found it to be simplistic enough to be inane. Also not particularly good advice in all parts.
For example, the article says that "[m]ost compilers will strip the comments from the executable program". Strictly speakig this is true: there is probably one or two compilers out there that retain comments in the binary code they put out. They're so rare, though, that it is quite utterly pointless to say anything about it. Anyone who needs to be told that comments don't impact performance or executable code size needs a course in basic programming, not secrets about being successful.
"A good indication that you have got the level of comment right: could someone understand what your program does if all but the comments were removed?" I disagree with this: better advice would be "could someone understand the code if you remove all the comments?" It's the code that gets executed and so it is the code that should be used to communicate and not comments, except when code can't be made clear enough. For example: if you write a wrapper around malloc to check that it succeeds, a comment explaining why it is acceptable to just kill the application on failure would be good, and very hard to express with code.
"In particular any code branch (an IF..THEN...ELSE construction) and any code repetition (a WHILE...END WHILE construction) should be indented so that it is easy to see where they start and end." Gee, that surely is a big secret that only successful programmers know about.
"Expect the unexpected and deal with it. Before you open a file, make sure that the file is present." That's not a good way to deal with it. It's a race condition just waiting to blow in your face. The correct way is to attempt opening a file and then deal with an error if it failed.
"Name your variables to aid readability. - - - The key is to be consistent and to be as informative as possible." Packing as much information as possible into a variable name can be a hindrance to readability. Too many people read advice like this given in well-meaning but misguided articles and then go on to name loop variables nElementIndex.
The loop gets more readable if you name your loop
variable just plain i. The loop variable is not
significant enough to warrant all the attention from a reader
that a long name requires. A short name in this context makes
it much faster and easier to glance at the loop and see what
it is doing.
Obviously names with scopes longer than a (fairly short) loop need to be more descriptive.
Here's my seven secrets of being a successful programmer.
- Learn to worship the goddess of simplicity. KISS a lot. This is much harder than it seems: it's more difficult to be simple and good than to be complicated and adequate. Simplicity starts with the specification of the program or system, and needs to permeate the design, and the implementation, at every step.
- Pick good tools, and learn them well. You need to know many tools, and know them well, or you'll waste time on doing unecessary things. Tools include software programs, books, algorithms, data structures, and mental models. Learn editors, programming languages, Unix command line tools, and so on. Learn at least three different paradigms for programming.
- Learn how to learn and keep on learning. New stuff is invented daily, and you need to keep up with it, or you'll end up as useless as a COBOL programmer doing a web shop.
- Develop debugging muscles. This is perhaps the hardest thing to learn, since no-body seems to be teaching it. You'll be spending most of your time doing it.
- Learn how to do testing well. Unit tests, test driven development, black-box testing, integration testing, regression testing, test automation, ... There's lots of ways of reducing the likelyhood that code escapes your hands with bugs still in it. It will inevitably happen, but if you know what you do, you can be better than most everyone else. The industry standard for commercial, proprietary code seems to be around 20 to 30 bugs per thousand lines of code; the Linux kernel has less than 1, and is known as a cesspool of bug-infested muck, so surely you can do better?
- Learn to write prose well. Then write a lot. If you can't write a README, a manual page, or the specification for your next work project, who's going to know about your great programming?
- Oh, you need to learn how to program well as well, and that isn't so easy either. Knowing how to program well merely isn't enough to be a successful programmer.
Wednesday, January 04, 2006
Rant: Bugzilla
I have never liked bugzilla much, and for the past week or so, I've found a new reason to dislike it, or at least the GNOME instance of it: every time someone changes the subscriber list ("CC") of a bug I've submitted, I get mail. That's now happening daily. I really don't understand why that setting is turned on by default, and, worse, I haven't found out a way to disable that setting and only that setting. I've lost my patience and configured GNOME's bugzilla to never, ever mail me anything again. This means that if I want to continue to use bugzilla (not that I've ever done it much), I will need to actively poll any bugs I've reported.
I am, however, also not going to be reporting any bug directly to GNOME again. Bugzilla is simply too much pain for casual bug reporting. I don't care how wonderful it is for the GNOME developers; if it is painful to me, I won't use it. All my GNOME related bug reporting will happen through Debian in the future.
For a project that prides itself on simplicity and usability, GNOME's use of bugzilla is rather weird.