When I needed to learn Perl, I went the other way around. I read and worked through all the exercises in Learning Perl and then followed that up by reading the first two thirds of Programming Perl. This was all accomplished before I had written more than a 1,000 lines of real perl and I think this gave me a much stronger base for understanding the how and why of things. Of course when I learned Perl, I was able and willing to devote 80 hours a week to the task, and going through Learning Perl and Programming Perl probably only took 3 weeks.

Last year when I went to talk to by soon to be adviser about working on my Master’s thesis, he said that he wanted everything written in C++. No big deal I said, but I have never taken the time to develop a strong ground work in the hows and whys of C++. Thus I ordered C++ Primer Plus.

I was planning on reading the entire book over Christmas break, but instead spent all my free time working on my thesis. Obviously, I had waited too late to do the right thing and did not really start on the book until after graduating. I am certain that the code for my thesis could have been better, but certainly was no where near the worst that has been written. After graduating, I made it one of my goals to finish the book since I really enjoyed writing C++ for my thesis.

Reading this book gave me some insight into C++, but it is no Programming Perl. What I now have is background in C++, and know that I probably should read a book just on IO and spend a very long time working through template examples. My weakness in C++ is really what has been developed in the last, oh, 15 years.

First the problem. When a running a command remotely using ssh, there is no local ptty associated with that remote command. So if the connection dies, or someone kills the ssh itself, the command continues running on the remote box.

For example, you have several servers and you want to monitor a log file on each of them from a central location. There are other solutions to this problem, but for the sake of the argument, we want to use tail -f on the remote box and the tail will be run over ssh.

ssh login tail -f log file

If the ssh is killed, the tail -f will live forever on the remote box.

The solution is simple, once you know where to look for it. In the ssh man pages there is a flag, -t, that will associate the local ptty with the remote command. So if the ssh goes away, the ptty goes away for the remote command, triggering the remote command to terminate on its own. This is the desired behavior.

But now, you want to write a perl script to monitor all these remote tails you have going. The problem now is that you don’t have a ptty because your command is started from inside the perl script. Oh no, what to do?

Run around, scream and shout!

Actually, the hard part was finding -t. Going back to that wonderful bit of knowledge and reading the last bit of the paragraph explaining -t, the mention Multiple -t options force tty allocation, even if ssh has no local tty. Really, that was nice of them. That is exactly what I needed.

So the command becomes

ssh -tt login tail -f log file

and I can stick it in whatever script I want, and it will clean up nicely is the ssh connection is ever lost.

I think the same justifications hold for a traditional CS education. You might not actually use the knowledge directly, but it creates a basis of understanding that will help accomplish what you actually do use on a daily basis.

Coding the Wheel is my favorite blog right now. I could care less about windows programming, but with his posts about poker bots, I get all excited about the neat hacks that make the windows world work.

Lisp is used a lot in AI and I should be taking a AI class in the next school year. Scheme is a derivative language out of MIT. Considering that lisp is probably used in UTD’s AI class, it is slightly better supported, and I have already started learning it, I think it wins.

Erlang has built in distributed capabilities. That is enough reason for me to learn it.

Just read a bit about Ruby today, and it was discribed as having stolen all perl’s good features (and a bunch of other languages). So perl++, sounds great. This should be a fun one and maybe we can just call Ruby Perl6.