06 Nov 2006
I finally got around to reading my ”blue book”1 for this election last night. Even though the ballot measures this election are pretty much a waste of ink I am happy that I live in a state that has ballot measures. In fact, in most elections it is the only reason I vote. Almost everyone’s vote is wasted in most of the office races. I say that your vote is wasted because in most places in the US you have two choices:
-
Vote for the candidate the most truly represents your views. This candidate with almost certainly lose because they are a third party candidate. Even if you think that you are a Republican or a Democrat I bet that if you actually read up on the third party candidates you would find one of them that better matches your views than the major party candidate you are planning to vote for.
-
Game the system by voting for the major party candidate you dislike the least.
Either way you are almost garrenteed to end up with a candidate that will not represent you very well. In practice almost everyone chooses option 2 but damn that sucks. If you want your vote to count at all you are force to vote against the candidates with which you agree the most and for one of the two candidates anointed with the two “best” letters in the alphabet.
If you are lucky one or the other of those candidates will be corrupt or a wack-job so the choice will be clear. When choosing between the lesser of two evils is easier if one is obviously more evil. But that does not change the fact that you will have probably voted against a good candidate because they didn’t have enough money or bad taste to bombard you with annoying, mean-spirited and laughably implausible attack ads (I mean, really, no one is against motherhood and apple pie).
Is it any wonder that there are so many people apathetic about voting? It does not surprise me. Any sane person can look at the system and see that their vote is wasted. Rather, I am surprised how many smart people actually think that voting is useful and meaningful.
The most common approach of rationalizing the usefulness of voting is to latch onto one or two issues and vote based entirely on those. You can usually find a major candidate that agrees with you on a couple of issues. If you decide that the other issues don’t really matter then it does not matter that your candidate of choice disagrees with you.
Others just choose not to vote, either out of apathy or out of protest. I have often chosen not to vote out of protest in the past. The very act of voting legitimizes this obviously broken system. On the other hand, there are ballot measures, non-partisan races and the occasional crook/incompetent that you really should vote against at all costs. And no one really counts the non-votes so as a protest measure it is not particularly effective.
There are a lot of voting systems and almost any of them would be better than what we have now. A better voting system for would not break the strangle hold the major parties have on the the US political system but it would be a good start. With something like approval voting you could vote for the candidates you liked with out increasing the risk of the candidates you dislike getting in to office. That would mean that some those really good third party candidates would have a fighting chance. We have the power of ballot measures in Colorado, would someone please use that power to get us a better voting system.
Until that happens I will continue go to the polls and vote knowing that, for the most part, my vote is both counted and wasted.
http://www.state.co.us/gov_dir/leg_dir/lcsstaff/bluebook/Bluebook2006.htm
11 Oct 2006
I have been using PHP1 as my primary language for five months now so I feel somewhat qualified to speak about it. My overall conclusion is that PHP is weak sauce. It is easy to get started with PHP but it’s usefulness decreases as the complexity of the application increases. This is primarily because keeping PHP code maintainable requires unnatural levels of discipline. Choosing PHP for a greenfield project is a technical risk that is unnecessary in today’s rich web application ecosystem. Of course, most projects aren’t greenfield so there are plenty reasons to have PHP around.
I find PHP to be a deeply frustrating environment in which to work. It seems to have occurred, as opposed to designed or even evolved, without much of an overarching vision. In “The Mythical Man-Month” Fredrick Brooks claims that “conceptual integrity is the most important consideration in system design”. Unfortunately, PHP has very weak conceptual integrity. It seems mostly to be a collection of decisions that seemed expedient at the time with little thought about how that would impact the over all system.
I remember hearing a few years ago about PHP is syntax to appear more Java like. That was back when it looked like there was going to be a real Java hegemony in business programming. At the time I thought it was a slightly odd but defensible idea. Today I see that decision as an indicator of weak conceptually integrity. I think any system willing to give up its character so completely must lack, almost by definition, the conceptual integrity needed to be great.
I covered several concrete issues with PHP in Early impressions of PHP. All of those issues still stand but my biggest problem with PHP, after working with it for a while, is that is seems designed to actively discourage meta-programming. This means I find myself writing annoying amounts of boiler plate code2. I strongly believe that the future of programming is language-oriented. This make PHP hard for me because even rudimentary language oriented techniques are simply not feasible in PHP.
A Somewhat more minor annoyance is the lack of closures and blocks. I first learned blocks and closures about two years ago and now find programming without them mildly painful. I think that Mark Jason Dominus got it right when he said
in another thirty years people will laugh at anyone who tries to invent a language without closures, just as they’ll laugh now at anyone who tries to invent a language without recursion.
There are just so many common classes of problem that are simply and cleanly solved by closures that not having them seems like a crime. I hope it does not take thirty years, though.
It would not be fair to leave this post without a discussion of the good things about PHP. PHP excels at lowering the barrier to entry. There is no other system I am aware of that even come close the ease of getting start with PHP. The weakness of PHP’s conceptual integrity does not seem to noticeably impact productivity in the context of small systems. The idea that you can have a web application by creating one text file and copying it to the web server is radically powerful.
And then there is Smarty. Smarty is a really nice external DSL for generating web pages, i.e. a template engine. The core of Smarty is well thought out and has very nice extension mechanisms. I is a joy to work with. If you are doing PHP work I can strongly recommend Smarty.
06 Oct 2006
•
Software Development
When, exactly, did bash become smart enough to handle command completion for sub-commands? I noticed this today on my Ubuntu (Dapper) box. I, unintentionally1, typed hg <tab><tab>
. Rather than getting the “Display all 100 possibilities? (y or n)” I expected, I got
add copy hgext/hgk] manifest rawcommit tag
addremove cp history [module recover tags
annotate ct id mv remove tip
bundle diff identify out rename unbundle
cat export import outgoing revert undo
checkout forget in parents rm up
ci grep incoming patch root update
clone heads init paths serve verify
co help locate pull st version
commit hgext/hct] log push status view
pwilliams@pwilliams:~$ hg
Which is the list all the valid sub-commands for hg. And if I do hg<br />
d<tab>
it auto-completes the sub-command to hg diff
. Same thing for cvs
and apt-get
. It seems that bash now support full auto-completion of sub-commands for most programs2.
That is just cool.
06 Oct 2006
Some days it is the little things that make you happy. This is a story of how a little elisp1 made me happy today.
We use phpDocumentor to extract the documentation from our PHP code. It is a workable solution but the format is a bit hard to read in plain text. The examples on the phpDocumentor website are all syntax highlighted which makes them easy to read. Without the fancy syntax highlighting, however, it is quite difficult to detect where the meta-data ends and where the descriptions start. To see what I mean look at this example (copied from the phpDocumentor tutorial):
/**
* Example of unlimited parameters.
* Returns a formatted var_dump for debugging purposes
* @param string $s string to display
* @param mixed $v variable to display with var_dump()
* @param mixed $v,... unlimited number of additional variables to display with var_dump()
*/
function fancy_debug($s,$v)
That does, in fact, document the method but, man, is it hard to read in plain unformated text. Even when you gussy it up with some pretty colors it is not really all that readable. I think some separator characters that where printable would have been a really useful addition to the format, say like a ’:’ between the meta-data and the description. However, you can make that block a lot easier to read just by inserting some newlines, which phpdoc
handles well.
/**
* Example of unlimited parameters.
* Returns a formatted var_dump for debugging purposes
*
* @param string $s
* string to display
*
* @param mixed $v
* variable to display with var_dump()
*
* @param mixed $v,...
* unlimited number of additional variables to display
* with var_dump()
*/
function fancy_debug($s,$v)
Much more readable. The problem is, I am an fill-paragraph
addict. I type M-q about as often as I breath when I am writing text. fill-paragraph
(M-q is the keyboard shortcut for fill-paragraph
) is the Emacs function that will optimally layout a paragraph of text. It splits lines that are too long and merges lines that are too short, removes superfluous spaces, etc. The problem was that fill-paragraph thinks that the ”@param ...
” bit is part of the same paragraph as the description so it (un)helpfully merges those two lines leaving the same jumble of text we started out with.
This has been bugging me for weeks, and today I fixed it. See, fill-paragraph
detects the boundaries between paragraphs by using a couple regular expressions that you can configure. So I buckled down and created a paragraph boundary pattern that make Emacs correctly treat @param
, or any other phpDocumentor tag that appears at the beginning of the line, as a paragraph separator line. Now fill-paragraph
leaves the description on line following the meta-data where it belongs.
Here is the code2. You can just paste this into your .emacs
file any place after (require 'php-mode)
line. Now that I think about it, this same regexp pattern should work for Javadoc, and probably a lot of other document extraction tool formats. You would, of course, need to change the hook, though.
(defun php-doc-paragraph-boundaries ()
(setq paragraph-separate "^[ \t]*\\(\\(/[/\\*]+\\)\\|\\(\\*+/\\)\\|\\(\\*?\\)\\|\\(\\*?[ \t]*@[[:alpha:]]+\\([ \t]+.*\\)?\\)\\)[ \t]*$")
(setq paragraph-start (symbol-value 'paragraph-separate)))
(add-hook 'php-mode-user-hook 'php-doc-paragraph-boundaries)
Having M-q do the right thing in PHP documentation blocks makes me happy. Probably inordinately so. But like I said, sometimes it is the little things.
26 Sep 2006
•
Miscellaneous
It is autumn in Denver. As I look out my office window I see mountains with snow on them behind the foothills bathed in the particular golden light of autumn. It is a gorgeous view. I love this time of year.
I have seriously considered taking up smoking again since fall arrived. There are very few things more enjoyable than having a smoke in the autumn breeze while looking at the mountains. It has been over a year since I quit. Most of the time I don’t miss it but this time of year…
The only thing that keeps me from starting is that I don’t think I would want to quit at the end of autumn. Smoking in the snow is really nice, too. I wonder if I will feel this way every autumn?
If you need me I will be outside…