Public Class GeoffAppleby

Programming Experience in a Nutshell

Rocky Lhotka posted recently about the necessity of having experience with multiple programming languages. He's also interested in other peoples histories.

I thought I'd throw in my two cents to this :)

I've always been an advocate of wanting every programmer to be an expert in C. When you have to manage your own memory allocations and deal with pointers, you gain an immense understandings of the inner workings of the computer. I know back in my early C days, I spent an incredible amount of time drawing myself little memory diagrams - just trying to figure out which part of the array i was dealing with, how i need to reference it, and which bits are possible to be modified when passed as a function parameter. Once you get the hang of several levels of indirection, the whole memory management things really isn't an issue any more.

For windows programming, C++ is a must, so you can get direct access to creating win32 controls by hand, and how to communicate with them (just about everything comes down to sending a message, rather than calling a method) so you gain a very good understanding of the message pump and notifications.

A smattering of C++ COM programming is useful more as backgrounder knowledge. Implementing a couple of COM interfaces by hand, writing factories and such, sets it clear in your head how it works - QueryInterface at first glance appears to simply be the COM equivalent of type casting, but you never know what you'll get back :)

What does this give you? When you program in VB6 (my next 'required' language) you don't get stuck in the 'VB6 gumby' hole. VB6 removes the problems with almost everything I've mentioned above. NO more (at least, not much) memory management. Controls as 'objects'. Everything you write is a COM class. Events just happen.

This is pretty nice, provided what's going on behind the scenes is well written. I have no opinion on whether the vbruntimes were well written or not, but they were certainly very restrictive when you wanted to get creative. When you needed to fall back to the win32 api to do something, things were just annoying enough to make it a dangerous place if you didn't know what was going on. Dealing with char, wide char, Unicode, being able to convert them, it's not easy to understand if you don't have the background.

A lot of VB6 guys knew what sub-classing was - that is, they had a piece of code they cut and pasted from app to app, inserting the needed code as found online into it, and forgetting about it when it all just worked.

Then comes .Net (C# or VB, it doesn't matter). Things are even more abstracted out, there's very little sign of anything that's going on in the background. That is - until you need to get that far down. Then you're lost - pinvoke, COM interop, CCW, now what the hell is going on?

It's not bad if you've got a good background in dealing with all this shit by hand like we had to in the old days :)

So what's been my areas of knowledge?

1. Pascal
2. Prolog
3. C
4. Perl
5. C++
6. VB 5/6
7. VB.net / C#

This is the order in which I became fluent (with some provisors). To me, the trick here is not just 'what do you know?' or 'what would you consider yourself pretty good at?' but 'what have you done with it?'

It's this that makes the big difference to me - I could be considered quite fluent in VB, but never written anything other than desktop applications that have no data connectivity, and never created a user control or needed to subclass. So while I might considered 'good' at VB, what do i really know? It's experience that matters - knowing what's really going on. It's these things that make you a good programmer - making decisions because of the stuff you can't see.

So let me expand on the previous list with the important information - context :)

1. Pascal. I only ever wrote with this in high school. I thought I was shit-hot with this language. I was top of my class, sure, but we didn't actually write anything worthwhile. But there was an important concept there that has rarely changed throughout my career - procedural programming. OO is really just moving different procedures to different objects :)
2. Prolog. Programming for women! Who else has a twisted sense of logic that makes this language understandable? I've delved into Prolog twice now, once for high school, once for Uni. I still have no idea how what I wrote worked. Where the hell is my int main()?????
3. C. Now we're talking. I first started playing with C when I downloaded the source code for a MUD so I could host my own. I read the source over and over and over and tinkered and played and reverted constantly. I bought the only book that's been really useful to me (for learning a language, not concepts) - The C Pocket Reference (I'm not sure if this is it - it's way out of print and I can't find it now to lookup the author). This book listed all the stuff available in the standard C library, and explained a few simple concepts. It was enough :) Once I had the MUD sorted (which ran on Linux), I've since written things like my own web server (for Linux and windows), my own CGIs (not graphics, web cgi's) for Linux under apache and windows under IIS 4, and custom solutions that involved 5 levels of indirection in the pointers and stuff like that :)
4. Perl. The ultimate in un-understandability while still being procedural. I hate it. About 8 years ago I wrote a hell of a lot of stuff in Perl, but it was under duress. The moment I got the go ahead, I converted all my code to C :) It ran faster and I wrote it quicker *laughs*
5. C++. Played with the supposed 'OO' paradigm that C++ gives us, although I really don't like the C++ language - I almost always fall back to calling stuff in the standard c library rather than the fancy new C++ ways (printf rather than cout, for example). But I learned win32 coding, and that was the important bit. I did a little tiny bit of MFC, but I realised quite quickly that it was crap :) ATL/STL I avoided because I consider it much less readable and maintainable than other language constructs. COM coding is a nightmare too, and I didn't really touch it until after I'd played with VB5/6 for a while.
6. VB 5/6. This is where I started to party. Immediate gratification. RAD. w00t! It didn't take me long to want control over what was happening however, and due to my background was able to grasp all the concepts with sub-classing and stuff quite easily. When you write a class that needs to rewrite it's own vtable, then you know you've gone hard core :) In this time I managed to get shell extensions and IE BHOs and Explorer Bars firmly sorted out (yes, within VB6, not many people can say they've done that, can they? :)
7. Ahhh... .Net. Sweet sweet .net. Mostly VB of course, but some C# too. After getting adjusted to VB6 I just don't want to go back to semicolons and curly brackets, so I'm happy with where I am.

And this is the thing - no matter what languages you write in, it's your experiences that count. (It's not the size, it's what you do with it ;)

I found over time my sweet spot for coding has been the middle tier - figuring out the algorithms, writing things fast, writing things right. GUI stuff is fine, but I prefer to write the code that does the work, not the code that makes it look pretty and makes it usable - if you get what I mean. And that's going from the experiences I've had - the fun bit for me is taking some idea and making it happen, not showing it nicely on the screen - once it happens, I'm bored :)

Rocky also mentions the divergence of VB and C# in the future. As Rocky explains, he's maintaining two identical source trees in different languages, and the differences between the two will grow as time goes on - VB is getting the My namespace, for example. As time goes on, front ends will be much developed easier in VB. If Orcas brings other changes, middle layers might be better written in C#, due to extensions made in C# that aren't available in VB.

What does this mean? Probably that as time goes on, the VB vs C# wars go out the window, and every .net programmer really becomes a .net programmer you'll either need to be fluent and experienced in both languages to write all components of your system, or we'll start seeing much more specialised job roles, where you're hired to only write the front end, or only the back end, etc. The front end guys will end up staying VB, the middle guys in C# - geez, it's lucky that a .net assembly is callable from any other .net assembly, regardless of the language it was written in, huh?

And so it all goes back to your experiences. Learn as much as possible, because you can apply it everywhere!

So what else does everyone else know? Come on, chime in - like Rocky said, leave a comment or blog about it yourself. He wants to see what people have done, and I'm curious too :)