Via the Clojure wiki I found a great page describing how you can use GNU screen and some Vim magic to let Vim play nicely with an interactive commandline program like a Common Lisp REPL, Ruby's irb, or Python's, well, python.

That page is a very stripped-down and simpler version of what Limp does for Vim+Lisp. But Jonathan Palardy's version has the benefit of being so simple that you can set it up yourself manually in a second or two. I still have never gotten Limp to work quite right and I don't have the time to debug a big mess of Vim script.

The idea is to start up a named screen session via e.g. screen -S foo -t bar, then start an irb session (or whatever) in there, and then in Vim you can simply yank some text into a named register and send it off to screen via a system call. Download Jonathan's code and see.

It's not a full-blown SLIME; it doesn't have tab-completion or weird interactive debugging windows or such bullcrap. It doesn't capture the output of your command and feed it back into your Vim buffer. But hey, it's pretty good for something you can throw together in 2 minutes, and it works.

So there goes my last reason to ever use Emacs. Good riddance, I must say.

Honestly, Emacs just frustrates the living hell out of me. Oh how I tried to like it. I really did. I've used it on and off constantly over the past year. I have Emacs shortcuts written all over the whiteboard in my office. But its braindead window management, its terrible broken undo/redo system, its finger-crippling key-chord combos, its lack of features I need (like line numbering), its reliance on broken 3rd-party elisp hack scripts for things Vim has built in (like line numbering!), its ugly fonts and GUI elements, and so on and so forth. Vim is such a joy in comparison.

People are stupid. We're blinded by our own prejudices and biases and preconceptions. It's kind of understandable because no one has enough time to really collect enough information to have an informed opinion about everything. So we end up extrapolating or relying on expert opinion or turning to our gut feeling. Inevitably we end up being wrong some of the time.

This leads to two problems. One is that being a person myself, I'm also stupid, meaning there are almost certainly some beliefs I currently hold that are wrong. The second is that from my perspective, I appear to be right about everything. This is trivially true of everyone; as soon as a person decides they're wrong, they change their mind right away and become right again. The problem then is how can I tell when I'm wrong and when I'm right? I quick objective glimpse at reality suffices most of the time, but sometimes we're still tricked.

Those two things in combination are a problem for everyone. I think the best anyone can do is to realize that this is the case, be open to being wrong, and to take some efforts to rectify it. At least minimize the damage, try to be as right about as many things as you can.

This is why e.g. I started learning Emacs even though I love Vim, and why I stick with it even though it's unpleasant at first. A lot of smart people say good thing about Emacs. My opinion of it is much different now than before I'd used it a lot. I think many things people say about it are wrong, but many are also right. There is some good stuff there.

For the same reason, I've decided to learn Python. I've been wanting to for quite a while anyways. In spite of the pain I've had trying to use it in the past, and my generally low opinion of the language, there may just be something worthwhile there. A lot of smart people say good things about it, and a lot of good programs are written in it. The community is large and active and enthusiastic.

My first shot was to try some of the stuff at Python Challenge. It's an interesting site full of puzzles that you need a programming language to solve; many of them are geared toward Python or toward libraries available in Python, but you can use any good language for many of them. I got through 17 of the puzzles last night, but I did look at "hints" on the forum for about half of those. A lot of them require sort of specialized knowledge apart from knowledge of Python, on a wide variety of subjects, so it's pretty fun.

My first pet peeve (of many to come, I'm sure): why doesn't python --help or python --version work? Instead you have to use python -h and python -V (capital V). This is non-standard. It worries me when people do things like this differently. But we'll see.

I decided to try a GUI app. I decided to use QT4. I then quickly remembered why I don't ever use C++ for anything. The amount of bullcrap you have to go through just to get a simple program going isn't worth the bother for the kinds of programs I write. I spent an hour on this and I haven't even started writing any of the actual program yet. Just setting up boilerplate garbage, using qmake to make the project file used to make the Makefile used to compile my program someday if I ever actually progress far enough to write it. But no, the compiler couldn't find some of Qt's headers, so I get to hunt them down and pray. Nope, not worth my time. You know it's a bad sign when you can copy/paste a Qt tutorial right from the Qt docs and it won't compile.

I've always detested C++. I thought maybe I'd start liking it more as I learned more about how computers and compilers and interpreters work, but no, actually I like C++ less and less. I read some books on C++ a while back and it seemed nice at the time, but reading about a language and using it yourself are two very different things. I find myself disliking statically typed languages in general in ever-increasing amounts. And languages without garbage collectors seem archaic to me. And any language that requires you to learn multiple new languages just to be able to configure and use the tools used to build your program is ridiculous. I have a hard enough time getting my logic right, let alone having to hand-hold the computer while it laboriously and clumsily stumbles through my code. Ruby and Lisp have spoiled me.

And God help me if I ever want to run it on someone else's machine. Or a different OS. I started looking into how to compile Qt apps in Windows and now I shudder to think what I almost got myself into.

Interpreted languages are as close as anyone's going to get to "Write once, run anywhere". Step 1: Install Ruby. Step 2: Write Ruby code. Step 3: Run it. Short of places the OS leaks through like pathnames or system calls, your program will work. End. Underneath all of that, someone still had to figure out all the low-level crap. But someone smarter than me figured that out, and had to figure it out ONCE, and then it's done with and I can take advantage. Worst thing that can happen is I get some missing Ruby files and throw them in a directory somewhere Ruby can find them.

Programming after all is all about abstraction. Abstraction layers help us deal with complexity. Ruby is an abstraction layer over a mess of C code and compiled and linked binaries and libraries that I never have to look at. That's the way I likes it.

I was going to use Ruby's QT bindings for this app, but I want it to be multithreaded, which probably rules Ruby right out. Sad. Maybe Python has good Qt4 bindings. Horrifying though the thought of writing Python may be, at least the syntax is more stomach-able than C++.

After I graduated college with a computer science degree, I had no idea what I wanted to do with it. I was fortunate enough to get a great job in academia. After almost three years in this line of work, I really can't imagine working for a for-profit company as a programmer. Right now I work in psychological research. I make databases and I program surveys / interviews for data collection and other such fun scripting and data-managing tasks. It may not sound very exciting but it involves a lot more than writing SQL queries. In my last job I wrote a huge Ruby framework to do all kinds of stuff, and I had to support Perl and Python scripts, master a statistics package, make web pages, and as an afterthought write plenty of SQL.

Working in academia is a wonderful experience. The people you get to work with are some of the smartest people in the world. Not necessarily smart in the computer world, but smart in the world of psychology, or law, or sociology, or other things. The people I interact with come from a completely different world than the computer world I live in, and personally I find it very refreshing and challenging to bridge that gap. If learning to communicate technical issues to non-technical people is a skill, there's no better way of learning it.

Another thing I love is that there's no pressure or drive to acquire money. At least not in the sense of "we need money money money, get it at any cost, beat the competition into submission, advertise, produce produce produce" Instead there's a drive to do good science. It's a different kind of pressure which I find much more palatable. Of course running a study does require funding and you usually have to convince someone somewhere to give you some, but as a computer programmer I'm far removed from such concerns and I don't have to worry about them. If the study is valid, and if it produces good data on time, and if I do a good job of helping that happen, things works out.

The work is important, which makes me feel good at the end of the day. I'm not trying to pad some billionaire's bank account, I'm trying to further the knowledge of the human race. At my previous job, a lot of the work I did ended up directly contributing to law and policy decisions. Most studies deal with things no one has ever looked at before. It's a much more fulfilling feeling than slaving away to make other people money.

The atmosphere at my current job and my previous one were very laid-back and casual. You generally work with a small team of people, and people just do whatever needs to be done. I've never had to punch a time card. I don't have to wear a tie. There usually are no deadlines where I need to get some product done by X date. There is no product except knowledge and research papers. I don't have to deal with customers. There are no customers except PhDs waiting to read that papers or work with new data.

In my very limited experience, there is a good demand for computer programmers who are willing and able to support a research study. I was really needed at my last job, and I got multiple very nice offers when I started looking to move to the west coast. If you're good, people will need you. If anyone reading this is an up-and-coming programmer trying to figure out what to do with your degree, give academia and research a thought.

Recently I was again faced with the task of maintaining and debugging someone's old Python code at work, with classes that make heavy use of super. Little did I realize that super in Python is the product of a madman. This article explains how it "works" (I use the term loosely) in Python.

Every time I have to debug, read, or acknowledge the existence of someone's Python code, I want to punch myself in the face repeatedly until I lose consciousness.