How ya been doing lately? Glad to see you haven’t forgotten to drop me a line every now and then…
Author Archives: paulvick
Language history
Rocky asks the question “What languages and language families have you been competent in during your career?” and provides his own list. Here’s mine, in order, as I remember it:
- BASIC (IBM-5100, a precursor to the IBM PC)
- BASIC (TRS-80 Model III)
- APL (IBM-5100)
- AppleBASIC (Apple ][+ and Apple ][e)
- UCSD Pascal (IBM PC)
- Unix shell scripting (not sure the machine)
- C (ditto)
- Turbo Pascal (IBM PC)
- GBBS Pro BASIC (a custom BBS language, Apple ][e)
- Scheme (Mac)
- C++ (IBM PC)
- Haskell (Sun)
- Visual BASIC 1.0 to present day (Windows & .NET)
- SQL (Access & SQL Server)
- Java (Windows)
- MSIL (.NET)
- C# (.NET)
And there is a small smattering of experience with other languages, but no significant programming experience. Broadly, this breaks down to the following families:
- BASIC
- Pascal
- C
- Functional languages like Scheme, Haskell, etc.
- Other
I’ll also add that the entry for “APL” is really a joke. I started programming on IBM-5100s over at Duke University. The 5100 had the distinction of having a switch on the front panel marked “BASIC/APL”. Depending on which position the switch was in, that’s the language you used when the machine booted up. Somehow, my friend Tom and I came into possession of some mag tapes (which is what the 5100 used for storage) with a bunch of games written for the 5100, including an adventure game written in APL. I seem to remember really wanting to learn how to modify the adventure game and so I set about learning APL. Unfortunately, I was probaby 11 years old at the time and had nowhere near the necessary mathematical foundations to be able to understand the language, so the whole enterprise was a bust. So Tom and I fell back to writing an adventure game in BASIC. I think I still have a printout of “Escape from Carr Building” somewhere around here…
Updated 02/17/05: How could I forget SQL?
Are C# programmers masochists?
OK, normally I try to be pretty even handed about the whole “VB vs. C#” thing since we’re all one big happy family, but sometimes I just gotta wonder… Scott Wiltamuth (he’s the product unit manager for C#) was talking on his blog about the recent Office System Developer Conference and said:
Given VBA’s long history with Office, one might expect VB .NET to be the primary language among .NET developers using Office as a platform. But I’ve seen a lot of anecdotal evidence that C# usage of Visual Studio Tools for Office (aka VSTO) is high. I’ll try to get some solid data on this and share it here.
Which raises the question: are C# programmers just masochists? I’ve always kind of suspected, what with the case sensitivity, the cryptic syntax, the lack of declarative event handling, and so on. But it seems to me that programming against Office is one of those places where VB has got it over C# hands-down. Sitting on my desk are some chapters of a book that I’m doing technical reviews for. The book is about using Office from managed code, and several of the chapters (maybe the whole book, I haven’t gotten that far) are written in C#. So as I’ve read through the chapters, I just keep circling things and writing in the margin things like “this limitation doesn’t appy to VB” and “this code is simpler in VB.”
For example, VB supports optional parameters, named parameters and passing expressions to reference parameters, whereas C# doesn’t. So when printing, code that in VB looks like:
Doc.PrintOut(Copies := 2, Collate := true)
Becomes in C#:
object copies = 2;
object collate = true;
Doc.PrintOut(ref missing, ref missing, ref missing, ref missing,
ref missing, ref missing, ref missing, ref copies,
ref missing, ref missing, ref missing, ref collate,
ref missing, ref missing, ref missing, ref missing,
ref missing, ref missing);
There are other various little gotchas sprinkled throughout Office (like the fact that C# can’t bind to Word’s Close event and VB can, although I think VSTO finesses this a bit), which raises the question: why would you use C# instead of VB to automate Office unless you were a bit of a masochist?
OK, OK, OK, I’ll admit it – I’m only half serious here. I don’t really think that C# programmers are masochists who whip themselves on the back every night chanting “I will initialize all of my variables, I will initialize all of my variables” and wear their “I Am Strongly Typed” hairshirts under their clothes during the day. In fact, I have it on good authority that many C# programmers are normal, well-adjusted members of society. But that doesn’t mean I can’t razz them a bit every once in a while…
Why is this man smiling?
In a comment to my griping about having to come up with 3 strengths and weaknesses for my performance review, Scott Mitchell pointed at one of Joel’s older articles entitled “Incentive Pay Considered Harmful.” I must have missed Joel’s posting the first time around, but I did get a chuckle out of reading his rant against the Ship-It Award (or, as some people called it “the Sh*t-It Award”). One amusing thing was that Joel didn’t tell the whole story, though. He says:
The Ship It program was announced with an incredible amount of internal fanfare and hoopla at a big company picnic. For weeks before the event, teaser posters appeared all over the corporate campus with a picture of Bill Gates and the words “Why is this man smiling?” I’m not sure what that meant. Was Bill smiling because he was happy that we now had an incentive to ship software?
There weren’t just teaser posters – every employee in the company also got a silly yellow and orange button with a pixellated picture of Bill Gates smiling on it. I’m looking at mine right now, and I distinctly remember when I picked it up from my mailslot, thinking “what the hell is this for?” I think I came in the weekend they were distributed and happened to pick mine up. What happened next may be completely apocrpyhal, but I believe that by the next morning the uncollected buttons (and, I guess, the posters) made a sudden disappearance from the campus. The story that I heard was that the “why is this man smiling?” campaign hadn’t been fully cleared with management and someone with a lot of clout went ballistic when they saw it and made them recall all the paraphanalia. So, the fact that I actually had my button was… well, it really meant nothing, but I’ve held on to it nonetheless.
Anyway, the really amusing thing is that while Joel has nothing but contempt for the program (as did most everyone else at the time, including myself), in my view it’s turned out to be a net positive. As far as incentives go, Joel’s right – it makes absolutely no difference. But Ship-It awards now function as a kind of institutional memory for those of us who’ve been around for a while. I’ll confess that I can never remember exactly when some version of some product I worked on shipped, and now I don’t have to. The ship date for Access 97 – November 18th, 1996 – is sitting right there on my shelf to remind me. It’s also a quick shorthand introduction to people when you go to their office: multiple Ship-It plaques = oldtimer. You can also see people’s histories within the company (“Oh, so you used to work on Windows and then Office…”) or the history of products within the company (VB 6.0 shipped July 1, 1998. VB 2002 shipped January 15, 2002. Between lies quite a tale.) So, yeah, it’s something that didn’t fulfill its intended, misguided purpose but I think it redeemed itself in the end in some small way, despite the scorn that was heaped on it originally. I’m glad I have mine and wouldn’t give them up.
As for the rest of the article slagging on the idea of performance reviews, I can only fall back on Churchill’s immortal quote: “Democracy is the worst form of government except for all those others that have been tried.” There’s no question that performance reviews can have terrible effects, but what’s the alternative? Give everyone a pat on the head, say “nice work” and send them off to a nap with some warm milk and cookies? This isn’t to say that there aren’t better or worse ways to do performance reviews, but it seems cheap to dispatch them without suggesting some alternative…
]]>Who is John Galt?
Apparently it’s the 100th anniversary of Ayn Rand’s birth, so for a brief period of time the media spotlight is shining again on the founder of Objectivism. Interestingly, there is a way in which Ayn Rand was tangentially involved in the creation of the precursor to this blog. When I received my brand-spanking new 300 baud modem for my birthday way back when, there were no BBSes in my hometown. This led to many long-distance phone bills calling places like Norfolk, VA, which made my parents oh-so-happy. Within a few months, thankfully, some local ones opened up. Most of them were the usual run-of-the-mill (i.e. boring) BBSes, but one of them had an extremely active political discussion group. Being 13 and somewhat naive, I dove into the discussion with my proto-socialist views and started duking it out with all involved. Two of the participants, who went by the names Darkshot and Cardinal Richardson, were dyed-in-the-wool libertarians who were very big on Ms. Rand (and were also usually the most interesting people to argue with). After debating for a few months, Darkshot apparently decided that although I was completely wrongheaded in my thinking, I was intelligent enough to be saved. So he took it upon himself to send me a copy of Atlas Shrugged (and some other books, I think, but I forget which ones).
When I went off to summer camp that year, I took the book with me and ended up reading it straight through. I have to say that it was probably one of the most entertaining books that I’ve ever read – it’s sort of like a comic book in fiction form. A bit of mystery, some really good good guys, some really bad bad guys and the end of the world – what could be better? It didn’t turn me into an Objectivist as hoped, but it did help sharpen my own views on things. Sadly, Darkshot passed away a few years ago but the book still has a sentimental place on my shelf. (I later tried reading The Fountainhead, but I found that it lacked the zip of Atlas Shrugged.)
The whole point of this is that in many ways the fact that, at the tender age of 13, I could go online and argue politics with adults and be taken seriously was a seriously formative experience. (As they say, on the Internet, nobody knows you’re a dog.) The egalitarian nature of online discussion had, I think, a lot to do with my desire to run my own BBS and helped spark my interest in online communities that continues to this day. So, thanks, Ayn, and happy birthday!
(As a footnote: Atlas Shrugged also holds the distinctive honor of being the only book that I’ve finished where I didn’t read the whole book. Those of you who’ve read the book know what I’m talking about. I can still distinctly remember getting about 3 pages into Galt’s diatribe before I thought “How long does this thing go on?” and started flipping ahead. When I realized it was, like, 40 pages, that was it…)
]]>Top 3 Strengths and Weaknesses
It’s mid-year review time again, and this year I’m resolving to do my review by the date that it’s actually due instead of when I usually do it, which is maybe two days before the actual review discussion. I’m generally positive about the review process but, I have to say, the part that gets old the longer you work here is the “Top 3 Strengths and Weaknesses” section. Back in the “old days,” when I had only been at the company, say, three years, this section was actually a very useful opportunity for me to reflect on what I did well and what I could improve on at a more general level. For example, in 1995, a new weakness showed up on my list – delegation – that reflected my move towards owning more areas in the product and beginning to have some management responsibilities. That was a good opportunity to think about why I had issues with delegation and what I could do about it, above and beyond the more targeted goals that I had for the next year.
But, c’mon. This is my 13th mid-year review and I’m running out of things to say. It’s not that I don’t have strengths and weaknesses to talk about, it’s just that they looks suspiciously like last year’s strengths and weaknesses. And the ones from the year before that. In some sense, over the course of 13 years I’ve managed to work my way through the easy weaknesses and now am engaged in the long twilight struggle against my more intractible weaknesses. I mean, I expect that I’m going to be working on my weakness concerning “dealing with ambiguity” for the forseeable future – I’ve improved a lot in the last year, and I expect to keep improving, but this is the kind of thing that is as much a part of my personality as anything else. Over the course of, say, the next ten years of my life I expect it to continue to improve, but it’s probably going to sit there on my “strengths and weaknesses” list for most of those years (assuming I’m still at Microsoft in 10 years, you never know…).
So this year I’m probably going to end up just copying last year’s list, but I’m not feeling particularly good about it. Nobody likes to feel like they’ve plateaued. So I’m choosing to view it as a sign of maturity. Yeah, right. I guess we’ll see what I come up with next year…
]]>Stupid questions…
So Andrea and I were talking on Friday about learning to cook and, in particular, how I used to really drive her nuts with stupid questions when I was taking my first culinary steps in the kitchen. Now, when I say “stupid questions,” I mean really stupid questions not “emperor’s new clothes” kind of stupid questions. The latter kind of stupid questions are understandable and have a certain aura of respectability. For example, while the question “Hey, honey, this recipe says that I need to ‘julienne’ the carrots. What does that mean?” might seem like a stupid question to someone who already knows their way around a kitchen, for the novice it’s a perfectly understandable question. My wife was always more than happy to answer those sorts of questions (provided that she knew the answer, of course…).
No, the stupid questions that drove her nuts were ones along the lines of “Honey, the recipe calls for 2 tablespoons of cooking oil. Where’s the cooking oil?” Questions that, even in my novice state, I should have been able to answer easily if I had just stopped and spent five seconds thinking about it. I mean, it’s not like I hadn’t seen her get the oil out of the cabinet a hundred times. Heck, it’s not like I couldn’t have, through the process of elimination, figured out what cabinet it was in. I was just having a momentary brain lapse, one that occurs less frequently now that: a) I know my way around the kitchen, and b) my wife’s standard answer was something along the lines of “Well, have you looked for the cooking oil?”
The point of the conversation, ultimately, was that no matter how hard one tries it’s sometimes impossible to avoid asking stupid questions like this. The best we can do is draw up a little social contract: I, the undersigned, do solemnly agree to think before I ask a question so as to minimize the chance of asking a stupid question; you, the other undersigned, do solemnly agree to not call me an idiot when I do ask a stupid question, understanding that such things do, occasionally, happen. As long as each of us keeps up our side of the bargain, everyone gets along just fine.
I was reminded of this conversation today when, in response to a technical problem I’m having, I sent out an email to a large email alias describing my problem and asking if anyone was aware of it. About 30 seconds later, I got responses from several people (including Dare) pointing out that my exact problem had been discussed four days ago on the exact same alias. Fortunately, everyone was very nice about it and no one said anything to the effect of “here’s the answer, you moron.” As they say: sometimes you’re the windshield, sometimes you’re the bug…
(As a side note, the one indispensible aid I have found in my quest for culinary mastery is the updated The Joy of Cooking. Besides having lots of good receipes, that thing has saved my rear more times than I care to think. Highly recommended.)
]]>Singletons and Default Instances
In my previous entry, I described what default instances are but left open the question of why we’re re-introducing them into the language. So let me spend a moment discussing that.
A default instance is, more or less, an instance of the design pattern called a singleton. A singleton is a type that only ever has one instance (hence the “single” part of “singleton”). Forms are often an excellent example of singletons because there is usually only ever going to be one instance of the form (with the exception of less common situations like MDI windows). For example, you only need one instance of the File Open dialog because there will only ever be one File Open dialog on the screen at a time. Rather than having to allocate an instance of the dialog every time you need one, or holding on to the same instance in some random place in your application, a singleton has a central location where the single instance is stored.
In most languages, you have to manage singleton objects yourself. This is usually accomplished by sealing the type (i.e. making it NotInheritable), making it uninstantiable (i.e. making its constructor Private) and exposing a shared property called something like DefaultInstance that returns, well, the default instance. If only the language would do that management for you automatically, how nice would that be? If only…
So now we arrive at the rationale for default instances, aka singletons: we think it’s a more natural way of working with objects that always or almost always have a single instance.
I’ve been using forms as an example up until this point, but let me expand the scope a little bit to illustrate my point. Web services are another example of a natural singleton object. When an application interfaces with a remote web service, there is typically only ever going to be one web service proxy instantiated. In VB 2002 and 2003, it is necessary to create a new instance of a web service proxy and then hold on to that instance for as long as you wish to use the service. If you wanted to share the service across multiple objects, you had to make sure to store the instance somewhere where everyone who needed it could get at it. And, truth be told, all of this management code had nothing to do with your program logic. It was just boilerplate that everyone has to write again and again and again.
In constrast, VB 2005 adds a default instance to web services. When you add a reference to a web service Bob, you automatically get a default instance at My.WebServices.Bob. No need to remember to create an instance of the proxy. No need to sock that proxy away somewhere so that everyone can get at it. It’s just… there. Without you having to do anything to make it so.
This seems like a good thing, but don’t just take my word for it. After all, you can go read about how to implement the singleton pattern in C# and how to implement singleton forms in C#. And then you can come back to VB and find that we already did it for you… (I should add that Justin’s singleton form entry touches on a specific problem having to do with the design of WinForms that I’ll address in the next entry.)
Well, that’s about it for the moment but we’re not done yet… I still need to cover the problems and issues that have been raised around default instances, which I will cover next. That entry, tentatively titled “Default Instances Considered Harmful” is coming soon.
]]>Vote for Me!
Now I know that you’re all saying to yourselves: “Paul, I read your blog religiously, I’ve bought your book, I’ve gone to all the talks you’ve given, I’ve listened to the .NET Rocks show you were on, I’m even considering getting your name tattooed across my… What else can I possibly do to show my love for you?”
I’m glad you asked!
My friends at Addison-Wesley let me know that my book, The Visual Basic .NET Programming Language, has been nominated for a Sys-Con Reader’s Choice award! I’m up against some pretty stiff competition, so I urge everyone who liked my book and who subscribes (or wants to subscribe) to go to their voting page and vote for the book! And, as an added incentive, every person who votes for me will earn a free gift: my personal and undying gratitude! (Offer void where prohibited. No monetary value. Not available in WA, VA, CT, TX, IA, OK, ND, WV or Puerto Rico. See stores for more details.)
Default Instances
Fresh off of writer’s block, I thought I’d dive straight back into the sea of controversy and talk about a feature called “default instances.” Default instances are a “new” feature in VB 2005 that is really the return of a very old feature, one that’s been around for a long time. Now, the return of default instances has stirred some very passionate debate, but what I’m going to do is address this question in three separate entries. In this entry, I’m going to describe what default instances are at a technical level. In my next entry, I’m going to talk about what I see as the positive case for default instances. Then, in the final entry, I will talk about some limitations of default instances and address the controversy about their reintroduction more directly. You can choose whether or not you want to wait for the last entry before you start throwing brickbats…
So, what are default instances? Well, they’re exactly what their name suggests: a way to provide a default instance of a class that you can use without having to New the class. If you’ve used versions of VB prior to VB 2002 (i.e. pre-.NET), you’ll probably have come across the most common default instance, the form default instance. For example, in VB 6.0, if you created a form named Test, you could say in code:
Test.Show()
And voila! an instance of the form would just magically appear. What was going on behind the scenes was a bit of magic. When you referred to “Test,” the VB runtime would go check and see if it already had a default instance of Test lying around. If it did, then it would hand back that default instance when you called Show(). If there wasn’t a default instance lying around, the runtime would create a new instance of Test and use that as the default instance going forward.
Default instances disappeared in VB 2002 and VB 2003, but are making a comeback in VB 2005. The high-level “why,” I’ll leave to my second entry, so let’s talk about the “how” for the moment. Hopefully, all of you are familiar with the introduction of the My namespace in VB 2005. (If not, go read this MSDN article and then come back.) One part of the My namespace is the Forms object. If you bring up a VB 2005 project with a Form named Test in it, you’ll notice that the My.Forms object has a property called Test. This property returns a default instance of Test. So you can say, sort of like you did in VB 6.0, “My.Forms.Test.Show()” and voila! up pops a new instance of Test. What happens behind the scenes is that the Test property of My.Forms checks to see if it’s already returned an instance of Test and, if it has, it just returns that instance. If it hasn’t returned an instance yet, it just creates a new instance. Pretty simple.
We also extended default instances to work in exactly the same way that VB 6.0 default instances did. Besides saying My.Forms.Test.Show(), you can also just say Test.Show() and it will also access the default instance. Essentially, Test.Show() is a shortcut to saying My.Forms.Test.Show().
There are, however, a couple of differences between the way default instances are implemented in VB6 and the way they are implemented in VB 2005:
- In VB6, if you tried to use the Is operator to test the default instance to see if it was Nothing, the expression would always evaluate to False. This is because referring to the default instance caused it to be created if it didn’t exist! In VB 2005, we recognize when you are testing the default instance using the Is (or IsNot) operator and won’t auto-create the instance in that case. So you can see if the default instance exists or not.
- A common source of default instance errors was using the default instance instead of Me within the default instance’s type. For example, if Form1’s load method has the statement “Form1.BackColor = Color.Red”, this will only change the background color of the deafult instance’s form. If you create a new instance of Form1 that is not the default instance, it’s background color will not be red! To assist users in this case, we give an error when you refer to the default instance inside of the type, telling you to use Me instead.
Well, that’s about it for the technical side of things. Now onto the good, the bad and the ugly…