Ah, the joys of learning something new

So, I’m going through the MS recommended “C++ Beginners Guide”. I have to keep reminding myself that it’s useful to type this stuff out, even though it’s way, way simpler than anything I’ve written in years.

It’s neat coming to a guide like this already understanding OOP pretty well via Ruby; it’s cool seeing what the guide doesn’t address. I often think that reading real beginners guides is good for a programmer’s soul: it lets you remember where you came from, lets you focus on where you are now. I often think that one of the worst things we can do for ourselves is forget where we came from: how do I know what direction I’m headed in if I can’t see where I came from and how I got here?

Of course, there’s also the idea that I need to do something with this knowledge, so I’ve set myself a challenge: I normally install cygwin and use its outstanding ports of a bunch of unix tools to help me remain sane in windows. My challenge to myself is that I can’t install cygwin, and if there’s a program I absolutely must have then I have to write it in C++ myself. That should give me a good solid heaping spoonful of real world experience to continue forwards with my ideas for developing on Windows.

I’m also restricting myself to Visual Studio Express, though there are some libraries it doesn’t provide that’d be nice for me to have.

Advertisements

Windows developin’

I started life as a die hard linux developer. That was all I wanted to do, and all that really made sense to me. I enjoyed looking into, calling and using various odd APIs, I love the idea of writing a little C and bob’s-your-uncle-you’ve-got-a-driver. I’ve never actually written a linux driver, though, and as such I just bought a linux device drivers book so I can get on that.

In either case, I think there’s some odd difference between linux and Windows development that I’m finding it hard to put my finger on. It seems, though, like there’s more general knowledge inside the linux camp: the languages themselves are known, rather than just the MS libraries. The kernel is studied and understood to have an exposed API, the compilation toolchain is something you’re encouraged to understand instead of just pressing build and now it’s done. And I think I’m better off for having an idea of what the individual steps that are taking place whenever I request magic from an IDE are.

However, the IDE front is really interesting. There’s something nice about a tool like visual studio, which is giving me a lot of hand-holding, rather than sitting down in front of gEdit, or Emacs or vi and being stuck with, well, with working out how the hell everything else happens. It’s a bit of a pain the first few times and visual studio takes a lot of that pain and hides it away.

Mac OS has a great IDE, too, in XCode. Interface builder could use a touch of work, and it looks like XCode 4 addresses a lot of my complaints against XCode as a whole, but it’s overall pretty neat. And the documentation, oh the documentation.

One place where the proprietary folks tend to whip the open source folks is the documentation. Now, that’s not universally true: OpenBSD has very, very high quality documentation indeed, the GNU toolchain is exhaustively documented (though documented exhaustively and documented well are two different things), but by and large the smaller stuff isn’t nearly as good. Except in the perl community, where everything on CPAN is normally really outstandingly well documented.

Something I’ve been really taking to heart, and which my colleagues at work are really pushing for, over the last six months is the idea that if I’m going to write code then everything in it has to be highest quality, no exceptions. It’s one thing to write a tracer bullet, to take an example from The Pragmatic Programmer, it’s another to then leave the tracer bullet in the system and never improve it. And if you’ve not written a high quality tracer in the first place, well, just remember that nothing’s quite as permanent as a temporary solution.