Monthly Archives: July 2005

On getting spanked by Anders and Raymond…

Some of the early session preferences are rolling in for the PDC and, as expected, I’m getting spanked by Anders and Raymond. I guess that’s just what you get when you go up against a Distinguished Engineer and the most popular Microsoft blogger…

Seriously, though, if you’re going to the PDC, do take a moment and respond to the Session Preference Survey and help us make good planning decisions for the conference. After all, when you show up to my session and find that there’s no space to sit because you didn’t say you were interested in coming, you’ll only have yourself to blame…

Tag:

Another one turns to the dark side…

In my recent entry on dynamism, I noted that one person we’ve been working a lot with lately is Erik Meijer, late of C?. Although Erik appears to be retaining a healthy dose of language agnosticism, it appears that we’ve started to turn him over to the dark side as he’s become quite enthusiastic about VB… In fact, he’s going to be giving a talk at JAOO this year on some of the stuff we’re going to be discussing at the PDC and a few speculative ideas he’s been working on beyond that. Here’s the abstract:

Moving forward, the dominant costs for IT projects are people costs more than hardware costs. Meeting business needs revolves around improving developer productivity. This provides great opportunities for language designers and compiler writers to concentrate on providing more powerful high-level programming abstractions rather than than on low-level optimizations.

This desire for more abstraction has lead to a plethora of new domain specific programming languages for manipulating data including XML with XSLT and XQuery, objects with OQL, and relational data with SQL. We argue that instead of creating such specialized languages, general purpose languages such as C# and Visual Basic should be extended with query capabilities. This allows programmers to query any form of data, using a broad notion of “collection”.

We will discuss various advancements in Visual Basic towards simplifying the development of data intensive applications. In particular we will concentrate on ways to bridge the impedance mismatches between objects, relation data, and XML and the importance of dynamism in this trend.

If you’re going to be that way in September, I’d urge you to check it out. Now Erik just needs to get that death grip power down pat and he’ll be a full-fledged VB programmer…

Eschewing jargon…

As longtime readers may remember, I suggested a long time ago that if/when VB added refactoring we might not call it “refactoring.” This immediately raised a hue and cry about how I was saying that VB users were “dumb,” how I was turning my back on an industry term that “everybody knows,” how this was just another example of how out of touch we were. I tried to turn in a good defense, but in the end it didn’t really matter, since first refactoring was cut and then it was an add on, and the add on uses the term “refactoring.”

I was reminded of this when I read Chris Williams – someone who would not be described as a low-end VB programmer – talking about how he finally managed to connect the abstract term “refactoring” with the basic concept of “cleaning up your code.” This much more eloquently states what I was trying to get at way back when, which is that what I find annoying about monikers such as “refactoring” is that they often taken a simple, straightforward concept that most people are already familiar with (“cleaning up your code”) and dresses it up in a funny hat to make it look like something new and special. This works well for:

  • …the originator of the moniker, because now he gets to be called “the father of refactoring”, which sounds very impressive.
  • …the author of the book on refactoring, because “Refactoring” or “Refactoring Explained” sounds more impressive than “How to Clean Up Your Code.”
  • …the lecturer on refactoring, because a talk called “Refactoring” or “Refactoring Explained” sounds more impressive than “How to Clean Up Your Code.”
  • …the consultant, because saying “well, you really need to refactor this code” sounds more impressive than “well, you really need to clean up this code.”
  • …the tools vendor, because saying “Now Supports Refactoring!” sounds more impressive than “Now Helps You Clean Up Your Code!”

Who it doesn’t always work well for is:

  • …the guy who just wants to clean up his code but doesn’t really have the time or inclination to invest much time in learning the latest jargon for something that he’s probably already doing today.

All that being said, I freely admit that jargon is often a necessary evil. After all, if you want to talk about a particular concept, you still have to name it. What bugs me is the way that the jargon often starts to take on a life of its own, until the original useful idea that it refers to is almost buried under a pile of formalization and people start to lose sight of the simplicity of the original concept. Maybe there’s nothing to be done about it, but that doesn’t mean we still won’t look for a way out of the dilemma…

Be careful what you joke about with Brad…

So with tongue firmly in cheek, I complain about how some people get their names in their session titles and some don’t and then Brad has to go call my (fake) bluff and put my name in my abstract. So now I get to see just how little name recognition I really have out there compared to Anders and Raymond…

Well, I’ll show him! I now command each and every loyal reader of the blog and all their friends to sign up for the PDC and register for my session! Bwahahaha! That’ll really show him!

Or just confirm my place in the world… 😉

Tag:

What?!?! Don’t you know who I am?!?!

Now that I know that Brad added Anders and Raymond’s names to their talk titles to pique people’s interest in their talks, I am shocked, shocked, that he didn’t do the same to my session. Doesn’t he know who I am?!? Doesn’t he know that the mere mention of my name would cause thousands of people to flock to the PDC to hear whatever I might have to say about VB? I mean, c’mon — I’m sure that Don Box would also have rearranged his schedule to make sure that he can attend my talk, if only he had known it was me giving it. But now, who knows? And how will Don be able to live with himself if he misses it?

Wait, what’s that you say? I’m not a Distinguished Engineer? I don’t have the single most popular Microsoft blog on the face of the planet? Joel Spolsky hasn’t even coined some cute phrase that includes my name?

Sigh.

Oh, well, I guess people will just have to come to hear about the technology after all…

(I should add that I give lots of kudos to Brad for his work on organizing the PDC. It’s a tough job, and I’m glad he’s the one doing it!)

Tag:

Drip, drip, drip, the PDC water torture continues…

More information about the PDC continues to drip out drop by agonizing drop. As Brad notes, most of the PDC session abstracts are online, including:

Visual Basic: Future Directions in Language Innovation
Visual Basic is designed to be the most productive language for writing data-centric, solution-focused applications. Meet with the designers of VB and learn about upcoming language features that will improve developer productivity, including new features that enable optimized queries over objects, XML, and databases in a consistent way.

I’m going to be giving this talk along with Amanda Silver and we’re going to cover some really cool stuff that we’ve been working on for quite a while now. As Luca notes, this is part of a large cross-group/cross-language effort, but this isn’t going to just be the same thing you’ll see in the C# presentation with curly braces removed! Can’t really say much more about it yet, but you’ll definitely want to drop by for this one. Also on deck is:

Visual Basic: Under the Hood on Extending the ‘My’ Namespace
Visual Basic 2005 includes a new and highly customizable application framework that makes it easier than ever to develop powerful applications for Windows. This session takes an in-depth look at the My namespace to understand the design principles, and demonstrates how the extensible architecture paves the way for future innovations with Visual Basic.

And there might also be another interesting session that might be making an appearance if we can get it in. You’ll have to stay tuned for that one, though… All in all, though, this is going to be an exciting PDC for VB and — who knows? — it might just be cool enough to steal Cyrus away from OCaml

Tag:

VB as a dynamic language

Joel Pobar has posted an excellent start of what should be an interesting set of blog entries on how dynamic/scripting languages work on the CLR. When listing out the dynamic languages available on the CLR he includes among them VB, which may come as a surprise to some people. In many places the cult of Option Strict may have convinced people that VB is an entirely statically typed language like C# is, but they’d be wrong. In fact, a decent chunk of our Whidbey time was spent rewriting our late binder to handle all the new language features in this release: unsigned types, generics, overloaded operators. I’m not sure how much people realize that they can now, say, add two objects together and we’ll correctly figure out the right user-defined operator (and/or conversion operators) to call. It’s one of those less-heralded features.

The interesting thing, of course, is that because the CLR class libraries are much more statically typed than most COM libraries ever were, there are some ways in which dynamic typing has become much less important than it once was. If you were going to, say, work with the Office object model, late binding is pretty much a necessity in many instances. However, the .NET Framework has really gone out of its way to introduce strong typing wherever possible, partially because of general typing goodness and partially so that languages like C# don’t completely fall over in the face of too many things typed as Object. This has had the effect of really swinging the typing pendulum pretty far towards the strong typing side, so I’m really glad to see a lot of creative ferment in the scripting/dynamic typing space. Because, folks, let’s face it — strong typing can be a pain in the ass sometimes.

One of the places where this is most evident, I think, is in the data access space. As anyone who’s used a data-intensive application from Excel to Access to FoxPro to SQL Server can tell you, data is extremely flexible when it comes to typing. A lot of data out there is only semi-typed and as you work with data it frequently needs to change type (and shape, as you add and remove columns). Strongly typed systems often times have a hell of a time dealing with this flexibility, and so it comes as no surprise that pretty much every single application I listed above takes a weakly-typed approach (some more than others) when working with data.

As I’ve hinted at before, one of the major investments we’re going to be making in Visual Basic post-VB 2005 is in integrating data (both XML and relational) more deeply into the language than ever before. We’re planning on talking a lot more about specifics at the PDC, but this general topic definitely has a large impact on our thinking about data. It’s also been very interesting to watch as C# has also thought about data integration (as Brad also hints in his post) because they’re a much more statically typed language, which means there are some places where we may be going farther than they’re willing or able to…

Anyway, the benefits of dynamic typing are hardly limited to data access, and as we think beyond our current release we’re investigating ways in which we can take even more advantage of it in the future. In doing so, we’re really trying to straddle both sides of the religious war between the static typers and the dynamic typers. To paraphrase Erik Meijer (who we’ve been working a lot with lately) the ideal principle seems to be:

Static typing where possible, dynamic typing where needed.

This seems to be the sweet spot, the best of both worlds. Will we be able to achieve it? Well, we’re going to take our best whack at it…

Updated 07/08/05: Peter Drayton pointed out to me that he and Erik wrote a paper on their principle, so I added a link. Also fixed the link to Joel’s entry thanks to mikhar!

The one that got away…

A while ago I mentioned that the first computer I programmed was an IBM 5100. It was not, however, what got me into computing in the first place. For that I can thank the Coco:

I can still remember seeing one of these in Radio Shack in a mall on the edge of Chapel Hill. I was 10 and was shopping with my mom and my grandmother. I wandered into Radio Shack and they had a Coco set up playing whatever crappy game it was that came with the system. Although I don’t remember this, I supposedly asked my grandmother, “When you die, could you leave me enough money to buy a computer?” (Gimme a break, I was just 10, after all.)

I guess I must have kept up asking for a computer, because my dad came home one day with two books on computers and gave them to me, saying, “before you can have one, you have to know how to use it.” Looking back now, I think he was completely crazy: one of the books was on BASIC programming and the other was a “how computers work,” and both were, as they might say today, “not age appropriate.” But I slogged through the latter book, working my way through AND and OR gates and microprocessor design and such. I didn’t understand it all, but I have to say that a lot of the information that I got from that book has stood me in good stead over the years.

The BASIC book was more frustrating because I had no computer to type the programs in to. That’s where the 5100 came in — I can still remember going over to the Duke Physics lab and typing in the little slot machine program in the back of the book. I don’t think it actually worked the first couple of times, but the rest is history. And the irony? I never actually owned a Coco. The first computer that I owned was an Apple ][+. I’ve never actually owned a Tandy computer, but I’m indebted to them all the same…

(For reference, here’s a picture of the 5100:)