Getting with the program

I’m not a Windows person, and I’m not trying to hide that. Part of this challenge I’ve given myself involves my discomfort and ignorance of the operating system I see on many a businessperson’s desk and often foisted onto their developer’s desks.

The pain of this process is apparent to anyone who didn’t start on Windows. They come into the situation trying to replicate the environment that they use on the non-Windows system. It’s not just a different operating system; it’s a different way of thinking.

I’m used to the Unix model where there are lots of small programs that cooperate with each other. I edit files in one program by run them in another. The unix pipeline model makes it easy to pass text around, and it’s in the DNA of those developers to write small tools based on standard input and output. When I first started this project, I thought I’d be able to get close to that.

I couldn’t get anywhere near to close. Whereas I’d use a terminal in unix land, the various Windows consoles have historical and severe problems handling modern text data (see Dealing with code pages). My first reaction is that Microsoft is stupid, but that’s not true. There are lots of smart people there, and the more I read from Raymond Chen, the more I appreciate what’s going on there and why things are the way they are. The consoles suck and are stuck in the 1980s because Windows people typically only use them for legacy stuff.

When in Rome, and all that. As I investigated these issues, I was in the land of not-Perl. All sorts of developers have the same problems, and the recurring answers all seem to point to the same thing: Windows development is about silos and single applications. It’s no accident that applications can go full screen and applications display all there stuff in one meta-window. They expect you to work there and stay there. I don’t like that because I beg the question that it’s the wrong way. It’s a different way, certainly, but it’s also the same way as Smalltalk, something I like.

In my Perl classes, I’ve mostly told Windows people to use Notepad and Command Prompt, but not primarily because I think they should develop like that. I encourage people to work in class the same way they plan to do their real work. I’ll adjust. But, training computers are often locked down. Perl is there often because I’ve gone through a process with an IT manager to get it installed. That’s typically a painful process with lots of back-and-forth emails. Getting them to license something like Komodo IDE is orders of magnitude for complicated. I know that Notepad and Command Prompt will be there, and I know that at the Learning Perl level the deficiencies in those tools don’t matter.

This explains how Komodo, Padre, and other things work. To see proper output for UTF-8 that I couldn’t coerce out of the Windows console backend, I resorted to Komodo Edit:

The IDE can do anything it likes because it can build from the ground up. Everything it needs it provides, so it doesn’t depend so tightly on history and internals.

This is what I need to get used to, I think, or at least tolerate for the length of this project. Komodo puts the command output under the program text pain without a way to have it anywhere else (optimally, a separate window). If I’m going to stay inside the IDE, how can I get the most bang for my buck with these huge monitors I have?

Leave a Reply

Your email address will not be published. Required fields are marked *