A new video on atheism where I talk about the theist’s concept of moral absolutism and why I think it is an incorrect and impractical view to have.

Transcript: (more…)

A poem that I wrote that any geek with grand project ideas can relate to. (By the way, I’ve finally settled on Django as the framework for my next web app. Maybe with SQLAlchemy. Or not. Or maybe I’ll do it in LISP instead. Or Haskell. Or Erlang. Either way, I still need to learn more JavaScript for the front-end. I should probably buy another book on it. Or two.)

Starting Out, by Albert Sweigart

“When starting out,” the sculptor said,
“First lay out your tools with care.
And always remember, through and through,
The most important thing is to prepare.”

The sculptor’s tools were neat and ordered,
His studio was well-lit and clean,
He always began by sweeping eleven times,
And sometimes twelve or thirteen.

Centered was an untouched marble block,
His raw, undeveloped masterpiece,
Here is where the magic was made,
On this stone his genius would be released.

“But not so fast,” the sculptor warned,
“Great works don’t just fall from Heaven,
After all, it takes nine months to make a baby,
And sometimes, ten or eleven.” (more…)

The title comes from an astute commenter named Frank on my last post, Your Ignorance Does Not Make a Programming Language Suck. Many of the comments on the post and the comments on Reddit quickly devolved into precisely the kind of language war I spoke against.

If I were a cynic (and on alternate odd days I am), I would say that it’s an inevitable side effect of the blog-comments medium. You can say, “I like chocolate ice cream” and you’ll get a slew of angry comments, half demanding why you hate chocolate ice cream and the other half demanding why you think chocolate is better than every other flavor.

But it is an interesting question: Is it possible at all to discuss language wars without starting one? Not really. Most reasonable debates about programming languages fail for a number of reasons. (more…)

(It might look like I’m picking on a couple strangers here, because they were the main inspiration for this post. I hold no grudge against them, heck, I don’t even know them. Don’t think that a few words or a few opinions encapsulates a person’s whole personality or intelligence.)

I’m trying to push for more Python adoption at the company I work at. This led me to casually google for “Python sucks” in order to anticipate any criticisms from coworkers. I found the usual suspects (mostly myths about Python’s indentation). But a couple blog posts did stand out. (more…)

Download PyBat 0.1.1

UPDATE: Hi, Reddit! I just wanted to clear this up: PyBat is about solving a somewhat specific problem: allowing Python scripts and batch files to communicate environment variable changes. This is in the case where you have a ton of legacy batch files that you cannot (for whatever reason) outright replace (which may or may not be the best thing to do in your case). I understand that everyone has their favorite scripting language (and for nontrivial tasks, they all sound better than batch files), but this is for situations where you want new Python scripts to work with the old stuff. The rest of the article is simply my rant that using batch files for nontrivial tasks is like working on a fusion reactor with a stone ax. Thanks for reading! Check out the rest of the site!

I’ve seen build systems that have accumulated the cruft of undocumented, half-forgotten, it-was-written-by-a-guy-who-no-longer-works-here software that was added piecemeal over time. It wasn’t until I had to do maintenance work on it that I discovered the horrifying truth of batch files.

Batch files are great for small tasks. But no bit of software remains small for very long, and after a while it balloons into an almost but not quite unbearable size. Batch files rely on goto logic. Batch files use environment variables (which is essentially a single namespace of global variables). Batch files have no consistent syntax. Batch files require several twists and hoops for basic programming tasks, if they can do them at all. Batch files rely on obscure command line switches (I can never remember if copy’s /Y suppresses the confirmation prompt and /-Y enforces the confirmation prompt, or the other way around.)

(UPDATE: I know you can use “call” to jump to a label in the batch file, though I rarely see it in use. The parameters use the %1 %2 etc. convention, instead of more descriptive labels. And you can always /? a command, but only because command line switches are also not very descriptive, and the long versions fill up the command line and make an unreadable mess.)

I tried googling for a batch file debugger, but only found pages that give handy “techniques” like printf-style debugging. Yech.

Of course I then realized the reason no one would make such a useless, baroque thing is because we have real scripting languages with real debuggers. Although throwing out all these batch files and rewriting them in Python (or even Perl) is tempting, it’s something you should never do.

No problem. Let’s just make all our new code in Python, and leave the unaesthetic but still usable old batch files around.

But you can’t. Because of environment variables. Many of the batch files I’ve seen do nothing but configure settings by changing environment variables (Visual Studio’s vcvars32.bat is an example of this). But any changes made to a child process’s environment will not be seen by the parent process. Batch files calling other batch files get around this with the “call” command. But batch files calling Python scripts (or vice versa) will not be able to see any changes made by the called file.

It’s not a flaw at all, it’s a basic, well-designed operating system principle. But it does make adding Python scripts that are backwards compatible with a batch file system impossible.

So I wrote a script to get around this impossibility. PyBat is a Python module that lets a Python script call a batch file (or vice versa), and will see the changes made by the called file. Because batch files can share environment variables with each other (with the call command), and Python scripts can share environment variables with each other (with the execfile() function), I’ve written pybat.py and pybat.bat that can bridge the two worlds by writing to a commonly known file. (A hack approach, but also the simplest that works.) (more…)