John McCarthy

Ruby vs. Python Briefly

Ok, so I figure it's about time to live up to the title of this blog, since I've spent the vast majority of the language discussion firmly planted in parentheses. Aside from the fact that my company is starting a project in Erlang, I've also been scripting Python and Ruby pretty heavily.

They're actually not very different languages. Neither is perfect from my perspective[1], and neither sucks. If I had to, I could get work done in both (and having gone through the Ruby chapter in 7 Languages in 7 Weeks, I'm more inclined to look at Ruby for my next big project than I used to be). To start with, here's a boiled down, no-nonsense table that represents my perspective.

...is more annoying than...
len([1, 2, 3])	[1, 2, 3].length
"foo " + bar + " baz" or "foo %s bar" % bar	"foo #{bar} baz"
", ".join(["one", "two", "three"])	["one", "two", "three"].join ", "
map(lambda a: a + 1, [4, 3, 2, 1]) ## still makes more sense ## than join or len, though	[4, 3, 2, 1].map {|a| a + 1}
a = [4, 3, 2, 1].sort() a[0]	[4, 3, 2, 1].sort[0]
nothing.jpg	foo.methods.sort
require 'optparse' require 'pp' require 'fileutils'	import optparse, fileutils ## I also prefer the more granular ## symbol access I get with python
sudo apt-get install ruby-full irb	python
...is about as annoying as...
def aFunction(foo, bar): #do stuff return baz	def a_function(foo, bar) #do stuff baz end
with tempfile.NamedTempFile() as tmp: tmp.write("Test test\n") ##more stuff tmp.flush() popen(["lp", "-d", "a-printer", tmp.name()])	Tempfile.open() do |tmp| tmp.write("Test test \n") ## more stuff tmp.flush system("lp", "-d", "a-printer", tmp.name) end

So I am slightly biased, but like I said earlier, not enough to actually decry either language. The biggest point in Ruby's favor is its handling of blocks (as seen in that tempfile pseudo-code). I like having an expression that says "Create an entity, do this stuff and then clean up", without having to clean up myself. Python doesn't like that.[2] Gotta admit, I boggled at the join syntax the first time around. Rhetorically, who the hell decided it makes sense that a join operation is something you do to the delimiter, rather than the list? In my opinion, it would even make more sense to make it a standalone function a-la len.

I really like the syntactic whitespace in Python.

def something():
    foo()
    bar()

seems like it's cleaner than the Ruby equivalent. Except that when I want to return the result of bar (which I do quite often, given that I much prefer functional programming to OO), I need to do so explicitly. Ruby has me waste an additional line on end, but returns implicitly. While I'm at it, Python libraries seem to be heavily anti-functional programming. They do the standard "OO" thing of exposing functionality via classes, but they also typically have a heavy reliance on side effects, which makes it harder than it ought to be to compose things. A recent example I had to go through involved using pyPDF and reportlab to process existing PDFs. You can do it, but the amount of fiddling involved is nontrivial if you want to decompose the problem properly because you need to do so by setting up multiple instances of PdfFileReader/canvas and making destructive changes to them.

Also, not represented in the table is how much easier it is to install python packages in Debian. While gem frequently errors on something, I've yet to find a package I need that I can't either apt-get or retrieve using python-setuptools. That's worth something (in fact, it's worth enough that I've been procrastinating on a ruby port of get-youtube-series, which used only default components in Python, but requires several installs in Ruby).

The last thing that table doesn't encompass is the version situation. That's a fairly major one from my perspective, but I'm not sure how serious it actually is. Python 3 has been out for quite a while, but it's not uncommon to see "Supports Python 2.7" on various frameworks/utilities. Squeeze still provides 2.6.6, Django still requires 2.[4-7] and Google app-engine is still asking for 2.5 (with 2.7 being supported as an "experimental" feature). That's less than encouraging. By contrast, Ruby 1.9 is fairly widely supported (though the Debian repos are still at 1.8.7). That just doesn't seem to bode well for the next version, regardless of how enthusiastic Rossum is about it.

---

Footnotes

1 - [back] - Though, to be clear, my opinion is that Ruby gets a damn sight closer than Python.

2 - [back] - Thank you Brendan Miller for pointing me to the with statement (documented here, here and here) which does emulate blocks well enough for my purposes.

Testing googlecl Posting

If it worked, you should be able to read this.

This post was posted via Emacs with help from the googlecl project

ScreenWM Follow-up

So I had enough theorizing last week, and am currently putting the setup through the Compaq Test™.

Preliminary observations are good; now that I've fixed the minor ui annoyances pertaining to screen and blog-mode, this is a very comfortable editing environment. I don't actually have the wireless drivers installed on this machine yet, so I'll have to plug into the router later in order to post this piece, but it's quite snappy considering the hardware I'm actually working with[1].

Hell, slime works pretty well too. Except that paredit[2] seems to have it in for me in various ways. It's nothing I can't work around with some judicious re-binding, but it's extensive enough that I don't want to attempt it today.

I started with a fresh install of Debian Squeeze[3] and basically just ran the following

## Basic dev tools
apt-get install emacs slime git-core mplayer lynx screen openssh-server gnupg
apt-get install sbcl python-setuptools ruby-full erlang

## app configuration
wget http://beta.quicklisp.org/quicklisp.lisp
su inaimathi -c "sbcl --load install.lisp"

## I. Fucking. Hate. Caps. Lock.
sed -i 's/XKBOPTIONS=""/XKBOPTIONS="ctrl:nocaps"/g' /etc/default/keyboard
/etc/init.d/console-setup reload

in order to get everything running the way I like. install.lisp contains

(load "quicklisp.lisp")

(quicklisp-quickstart:install)
(ql:add-to-init-file)

(ql:quickload :linedit)
(linedit:install-repl)

(with-open-file (s (merge-pathnames ".sbclrc") :direction :output :if-exists :append :if-does-not-exist :create)
  (format s ";;; Check for --no-linedit command-line option.
(if (member \"--no-linedit\" sb-ext:*posix-argv* :test 'equal)
  (setf sb-ext:*posix-argv* 
        (remove \"--no-linedit\" sb-ext:*posix-argv* :test 'equal))
  (when (interactive-stream-p *terminal-io*)
    (require :sb-aclrepl)
    (ql:quickload \"linedit\")
    (funcall (intern \"INSTALL-REPL\" :linedit)
             :wrap-current t)))"))

(ql:quickload (list :drakma :cl-who :cl-ppcre :cl-fad :hunchentoot :clsql :cl-smtp :cl-base64 :ironclad :trivial-shell))
(quit)

Which just configures quicklisp and linedit to run whenever I start sbcl. After that , it was just a matter of importing my Emacs settings[4], and .screenrc file. I didn't end up keeping the fancy settings I was thinking about last week, by the way. It currently contains, in its entirety

screen -t emacs emacs -nw

startup_message off

bind S split -v
bind s split
bind R remove
bind ^e screen emacs -nw
bind ^w screen webjump

markkeys "h=^b:l=^f:$=^e"

which is as basic as it could possibly be, except for the line that calls a program named webjump. That's actually a convenience script of my own devising that simulates my conkeror webjumps from the desktop machine. It reads

#!/usr/bin/ruby

require 'uri'

print "Webjump: "
input = gets.chomp.split(" ", 2)

def get_url(input)
  jump = input[0]
  query = URI.escape(input[1])
  jumps = {
    "youtube" => "http://www.youtube.com/results?search_query=#{query}\&aq=f",
    "stockxchange" => "http://www.sxc.hu/browse.phtml?f=search\&txt=#{query}\&w=1\&x=0\&y=0",
    "google" => "http://www.google.com/search?q=#{query}\&ie=utf-8\&oe=utf-8\&aq=t",
    "wikipedia" => "http://en.wikipedia.org/wiki/Special:Search?search=#{query}\&sourceid=Mozilla-search",
    "gmail" => "http://mail.google.com"  
  }
  jumps[jumps.keys.find{|k| k =~ /#{jump}/}]
end

url = get_url(input)
if url
  system("lynx", url)
else
  puts "Can't find webjump '#{input[0]}'"
end

which is quite useful when I need to search for something quickly. I'm thinking about changing it such that it just takes a command-line option for which webjump to use so that I could actually keybind google-search as opposed to webjump (I've observed that "go something something" is used far more commonly than any of the others).

Like I said, that's it. It's an extremely minimal system, and it doesn't have any kind of multi-monitor support, but it gives me the important little comforts I've been used to (like tabbing between applications and convenient, keyboard-based browsing) without the need to start up an instance of X[5]. That greatly increases the universe of useable machines for me.

The only things I'm still missing:

• a klavaro-analogue I still have no way of practicing typing from the command line (which is kind of ironic)
• more shell-friendly bindings for paredit
• multi-monitor support which I have no idea where to even start on

---

Footnotes

1 - [back] - An old Presario R3000 with a 1.4ghz processor and 256MB ram.

2 - [back] - Which I've installed, and actually gotten to like under X, at the recommendation of a friend from the Toronto Lisp User Group. It's actually fantastic, but there are various key that just barf when you try using it from terminal. The default bindings for slurp, barf, forward and back s-exp operations are outright ignored, and it does something funky to my home and end keys so that they insert odd square-bracket escape sequence instead of doing what they say on the key. It's paredit because, all of the above works just fine in other modes.

3 - [back] - Since the Compaq still had a copy of Parabola running from last time.

4 - [back] - Including the steadily-growing blog-mode, which I've added several functions to since I started writing this piece.

5 - [back] - Also, conveniently, lynx doesn't let me waste any time on Reddit, since I can't actually post or upvote from it.

Screen for StumpWM/Xmonad Users - GNU Screen as a window manager

The first part is exposition. If you're just interested in how to set up Screen as a StumpWM analogue, skip to the next heading.

I've been thinking about window management again, for my own purposes and bouncing around between combination of Xmonad, StumpWM, XFCE and GNOME (as well as trying the two tiling managers standalone).

Using XFCE and GNOME standalone really wasn't going to do anything for me, I already knew that. Using the lightweights on theiir own had a few minor annoyances that I tried to fix by running them together.

Out of the box, neither Xmonad nor StumpWM

• support a nautilus/thunar style file display (and I sometimes need it)
• auto-connect to my wireless network
• automatically mount external media (or watch for new drives being added and mount them as necessary)

It's becoming clear that I don't want a regular point-and-click interface by default anymore, except for one or two specialized tasks for which nautilus --no-desktop should suffice.

I also don't really use removable media anymore. Maybe my memory is a bit clouded, but it seems that I used a lot more USB keys, DVDs and CDs back when I was a Windows/OS X user. It's possible that I was just being stupid, but it seemed like the easiest way of sharing data between two different machines[1]. That flat out doesn't happen anymore. We only have Linux machines in the house now (split between Debian, Parabola and Ubuntu, in order of descending quantity), so when I want to share data between them, I use scp, or possibly rsync depending on the specific situation. I don't do backups to DVD or CD anymore; I just use hard drives and the only computer that needs to play DVD media is in the livingroom[2]. I also don't install things from CDs, except for Debian itself.

Finally, connecting to my wireless network isn't automatically handled, and I do still need to do that with my netbook, but I can work around it[3]. Granted, I could have just memorized how to do it via iwconfig and friends, but this way is simpler from the interface perspective.

Bottom line; I don't need a desktop environment anymore. I'm good with the plain window manager. So it looks like GNOME is coming off my own desktop this weekend and Stump is getting re-instated as the manager of choice. The thing is, I also have a few old machines lying around that chug noticeably under any sort of graphic interface. And it turns out that if I'm willing to ditch nautilus, and fend for myself in terms of mounting media/connecting to networks, then I can go all the way to terminal.

I've been using GNU Screen as a way of deploying Lisp applications, but looking over the keybindings and man page, it looks like it can serve as a respectable alternative to a tiling window manager.

Screen WM

The default control combination is C-a instead of C-t, and the keys are significantly different, and you can't extend it in Lisp[4], but it looks like a fairly simple .screenrc file can turn it into Stump-Lite. Here's a quick breakdown, assuming the default bindings:

• C-a ? shows you the help screen.
• C-a c starts a new terminal in the same session (when you re-attach later, you'll have both of these)
• C-a | splits the screen vertically (note that screen doesn't automatically start a second terminal). Equivalent to C-t S
• C-a S splits screen horizontally. Equivalent to C-t s
• C-a TAB moves to the next split
• C-a X removes the current split
• C-a C-a pulls the other terminal. Equivalent to C-t C-t
• C-a n/C-a C-n cycles to the next terminal (C-a p/C-a C-p cycles backward)

In other words, out of the box, you've got the same basic window management shortcuts this way. And if you feel like remembering extra keys, feel free to commit the above to memory. As for me, my .screenrc file is going to look something like

startup_message off

bind S split -v
bind s split
bind R remove
bind ^e screen emacs -nw

On a machine where I plan to use terminal exclusively, I'll also add

escape ^t
bind ^t other

to mirror the StumpWM keys I'm already used to.

Incidentally, that last line in part one is what got me convinced that screen could credibly replace X for my purposes (assuming I'm working anywhere other than my dual-screen setup). It seems like you can wire up arbitrary shell commands and bind them to keypresses (use exec instead of screen if you don't want to start a new window for them). I left it out, but you can also put regular screen calls in .screenrc like so

split
resize 60
screen -t lynx lynx
screen -t emacs emacs -nw
focus
screen -t top top
focus

in order to customize your startup routine. I'm sure I could get more complex than that, but it illustrates the point. That snippet starts me off with a horizontal split. The top frame is emacs, the bottom frame is top and lynx is running in the background.

The stuff that I'll be missing this way is

• A dmenu-like command (it seems like you can't have screen prompt for user input to then use in a keybinding; I'll have to do more research. The only thing I'd do with this is setup some lynx webjumps in any case.)
• X windows (so no GIMP, gitk or a graphic browser on my dev machine, which is actually a good thing on balance since that'll reduce Reddit use)
• Resizing mode (you can resize windows in screen, but you do it by typing in a height/width in lines/cols to set the width to, rather than the Stump resize mode where you can incrementally tweak windows)
• A run-or-raise equivalent (the C-t C-e binding as above will actually start a new emacs every time rather than switching to it if one already exists)

Given how my .stumpwmrc is shaping up, I don't think this'll be a big sacrifice. The thing I think I'll miss most is actually gitk.

I'll let you know how it goes.

---

Footnotes

1 - [back] - Whether they were both mine and sitting in my room, or not and lying on a table in the OCAD student lounge.

2 - [back] - And has a standard GNOME 2 setup out of deference to my wife, who hasn't taken the Computer Nerd prestige class remaining a regular nerd.

3 - [back] - Been meaning to do a writeup on that little UI layer I'm slowly using to coat my shell experience. pack and unpack have already left me smiling several times.

4 - [back] - :(

Old Machines Redux

I was actually just contemplating my current backup setup here, when I came across two things. First, a thread asking about these experiences, and second, another discarded machine.

It even had the Windows License key sticker still attached. No severed monitor cable to laugh at this time, but still.

Booting this one up showed me an, actually, respectable 1.7 Ghz processor and a full gig of Ram. Cracking the case also yielded a couple of surprises. One, whoever last used this machine had it hooked up to a vacuum cleaner running in reverse for at least six months. The amount of dust was insane. To the point that I had to don a facemask/goggles and clean it out outside[1]. Two, this thing actually contained an old Micro ATX motherboard[2].

I was surprised, because it had the standard, giant tower typical to desktops of the past few years. One trip to the local computer store provided an appropriate Micro/Mini ATX case.

Transplanting the board over was straightforward, except for two things. First, since this was a found machine, I didn't have that little reference card for what each of the case pins does, so I had to create my own based on what the current case hookup looked like. The USB connectors also took some guesswork since the two cases actually had different types of plugs for them[3].

Second, I don't happen to have a Mini-ATX-sized ethernet card lying around, so the existing one had to tolerate some minor mods.

At more or less this time, one of my cats decided it was a good time to put their tail in the path of my chair wheels. I had to take ten minutes or so to calm the little guy down before going further.

I tested whether the thing boots before arranging all that hardware in the case. There really isn't much room in these, it doesn't even look like I can get a second hard drive in unless I want to leave it hanging outside somewhere. The drive that was in the original case was fucked (which I assume is why this unit was disposed of), so I had to pop in one of my spares. It ended up getting a 40GB Western Digital. In the process of picking a new drive, I realized that two of the three stashed ones were out too. I'll strip them for magnets later, I guess.

This brings my lifetime hard drive failure record by brand up to

• 3/6 - Maxtor
• 1/1 - Fujitsu
• 0/4 - OCZ
• 2/43 - Western Digital

Which actually isn't too shabby overall.

This time, I decided to throw a copy of Parabola on it.

The installation was entirely uneventful except for the hard-drive and cat-related problems I've mentioned already. The only challenging part was actually folding everything down into a case that small. There's just a birds nest of wires in there, but it boots and runs properly.

I'm not entirely sure what I'll use this one for, since we have a media PC in the living room already. I might just get a VGA to RCA converter and toss it in the bedroom with our CRT. The other option is to use it as a random dev box to play around with.

---

Footnotes

1 - [back] - No pictures of that sadly, though I can assure you that the dust is now providing nesting materials for no fewer than nine neighborhood birds.

2 - [back] - As an aside, it seems that "Micro ATX" is a larger form factor than "Mini ATX", which I thought was a little odd. I assume that the team developing the "Mini ATX" was done second and had to settle for the less impressive name

3 - [back] - The old one had one chunky plug that fit over the entire USB pin-set while the new one actually had a separate wire per port and each one had a separate plug for the ground pin