Marquee de Sells: Chris's insight outlet for category 'spout' via ATOM 1.0 csells on twitter

You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.




Be Your Own Teddy Bear

Wednesday, 10/17/01

According to legend, the TA office next to the Stanford computer science lab is guarded by a teddy bear. Before a student is allowed to consume valuable time asking a question of the TA, they must first explain it to the teddy bear. Apparently the bear is able to answer 80% of the questions that students ask, saving time for the TAs to play Unreal Tournament.

I often feel like I act as the teddy bear for the COM community. I get several email messages a day from folks that consider the mailings lists (resources set up to answer just these kinds of questions) to be too slow, so they ask me directly. If I don't know the answer off of the top of my head, I often respond with the following phrase:

    "Can you send me a tiny, tiny project that reproduces the problem? --Chris"

This, of course, implies that I will actually build and debug the project. And 20% of the time, I do. The other 80% of the time, by the time folks have reduced the problem enough to demonstrate it for me, they've already solved it, saving me the time (thank goodness).

Knowing that this is the case, I recommend that you become your own teddy bear. A whiteboard is handy for explaining the problem to yourself and Microsoft development tools are now so handy that you can typically whip out a small reproduction project very quickly. These very activities will often solve the problem, but even if they don't, you've got a concise description of the problem and a small repro case to send to your friends or to post to the list.

0 comments




Flattery

September 17th, 2001

Is it imitation or nudity that's the sincerest form of flattery? Either way, it looks like Robert Scoble is naked outside where the neighbors could see (unlike mine, which was inside and very private : ).

0 comments




Give Comfort

September 11th, 2001

The World Trade Center and the Pentagon were attacked today when hi-jacked commercial airlines crashed into them, destroying both of the towers and damaging the Pentagon. I can't possibly know what the people who had friends and families in those buildings are going through right now, but my thoughts and prayers are with them. If there's anything you can do today or in the coming weeks or months to help those people to recover from their loss, please put aside your computers and your work and do it. I will be doing the same. Thank you.

If you're interested, both Amazon.com and PayPay.com have set up disaster relief donation funds. 100% of all donations go directly to the American Red Cross.

0 comments




Q&A: .NET Cross Language Inheritance?

August 23rd, 2001

Q: D.J. Stachniak writes:

I missed the Conference.NET, but I've been reading through the PowerPoint presentations posted on DevelopMentor's web site. I noticed in the C++ In A Managed World presentation that there is a slide (page 62 specifically) which says ".NET supports real inheritance across languages - Although, that doesn't mean you should use it..."

Would anyone like to take a crack and explain to me why cross language inheritance might be bad?

A: Chris responds:

At the Microsoft PDC in 1993 (also known as the "COM PDC"), Kraig B. introduced COM by saying that it didn't have inheritance, but that was a good thing, because of the fragile base class problem. This problem says that derived objects, by definition, need to have incestuous knowledge of their base classes, including full understanding of the implied contract (which often requires to source to determine). What made this relationship fragile was that reliance on the implied contract caused all kinds of trouble when it changed, implying that it was knowledge of the source that caused this problem.

Of course, that's not the case. We often experiment with components that we don't have the source for and made decisions based on implied contracts that can easily change version to version. I would call this the "fragile use" problem, but it's more commonly called "DLL Hell." The idea that components can be replaced in the field without breaking things has long been known as a fallacy, and it doesn't matter if you've got the source or whether you're doing inheritance, aggregation or mere creation.

Eiffel's Design by Contract is a good step towards detecting problems, but that's an Eiffel-only thing. A good step towards reducing DLL Hell is the aggressive versioning and side-by-side installation of multiple versions that .NET supports. If your client or derived class binds to a specific version of a component, then there's no need to worry about it changing out from under you. Lack of source makes it harder to derive than to merely use, but assuming you can make things work empirically, cross-language inheritance might actually work in .NET (but don't hold me to that : ).

0 comments




Conference.NET: Notes from the Field

August 17th, 2001

In talking to fellow DevelopMentor instructor Craig Andera today, I realized that those of you who didn't get to attend DevelopMentor's Conference.NET this week, must've hoped that DevelopMentor's inaugural conference would suck so that you didn't miss anything good. Well, I'm pleased to tell you that it didn't suck. In fact, it was awesome. In further fact, I can't say that I've ever had more fun at a conference. Of course, I couldn't be everywhere, but here's what happened to me:

Day 1: Chris Doesn't Suck

Monday started with a rousing keynote from David Chappel, the industry's best-dressed speaker (not a high bar in our industry, of course, but even I have to admit that he's very good looking : ). An overview of his talk is available here, but what I most remember is that he pegged C++ as for dinosaurs only. While I certainly see his point, Microsoft's Managed Extensions to C++ are going to enable a lot of people to enter the world of .NET without rewriting large code bases, which is going to make it enormously popular. This was further evidenced by the volume of MC++ questions that I fielded all week long (one attendee left the lab unhappy with the answer he'd gotten from a C# bigot and dragged me back there to examine his problem). Like VB before it, I predict MC++ to be the .NET love that dares not speak its name. Of course, David's comments weren't exactly designed to fill my day-long MC++ tutorial later that day...

Further compounding my potential attendance problem was going to be Don Box. Don's an amazing man. He has the ability to dive completely into a technology, understanding it better than the designers, while still remembering the technical details of every other technology he's ever ingested and completely belittling any value they might have had when compared to his latest fetish. In his talk, C++ didn't respect the programmer, VB was the bane of every other programmer, COM was a mess and of course people had trouble getting DCOM to work over the Internet (how could it work when our neck-bearded network administrators had been replaced with kids pulled away from flipping burgers by the siren song of readily available MS networking certification?). Of course, to Don, only .NET and C# are at all useful to the reasonable, thinking developer. My biggest issue with Don is how right he usually is, but when he singled me out as destined to be the world's last C++ programmer by painting an image of me in a '76 Ford truck sporting a gun rack and a bumper sticker reading, "You can have my C++ when you pry it from my cold dead fingers," I knew that those attendees who hadn't yet decided weren't likely to show up in my MC++ tutorial...

The last 2/3rds of my day was spent teaching my first real material in about three years. Oh, I'd given the odd conference talk now and again, but after years on the sidelines managing the development of Gen<X>, I was nervous. After all that time, could I still manage to entertain and educate a room full of people on a topic that the keynote speakers had spent all morning panning? As it turns out, I can. Oh, I can't say I was brilliant, but I didn't suck, and that was enough.

Day 2: Chris Has a Bad Hair Day

Day 1 ended with lots of celebration of my not sucking. I got to hang out with dear friends from as far back as 3rd grade and enjoy a bit more alcohol than was strictly necessary. After finally collapsing into bed at around 5:30am, I was hardly in any shape for my 8am business breakfast (note to self: never let the commission-based sales guy schedule the meetings -- they're just too damn eager). Needless to say I grabbed every minute of sleep that I could, but because of my short, deathlike REM, my hair was remarkably unmussed when I showed up without a shower (and even managed to make a point or two without falling asleep in my waffle). After two hours of scintillating business wrangling, I retired to my room to grab some quick Zs before returning to "office hours" in the lab. The lab was really great, because it contained a couple of hundred PCs with exercises from each of the conference talks so that attendees could practice what they'd learned, getting help from the rotating speakers pulling lab monkey duty and answering attendee questions about designs scrawled on cocktail napkins. This was also where I learned that my continued lack of a shower had finally made it's way to my hair. After thirty minutes of frightened stares, I stopped by the gift shop to buy a hat (stupid looking, but better than the Elijah Prince "do" I was sporting) on the way to my first Birds of a Feather talk.

The BOF that I was to do with Brian Randell, a died in the wool VB guy, was entitled "WinForms: Love it or leave it," and it was designed for two things: 1) to leave things very open to audience participation and 2) to make sure that Brian and I could show up without any preparation whatsoever. You see, both of us had fallen in love with WinForms, but we hadn't gotten to do much with it. We showed some fun demos, though. Mine was dedicated to the splitting and docking that WinForms has built into it (a thing of beauty!). Brian's was dedicated to the new opacity property setting which makes windows imperceptible (how very useful...). So, after me making fun of Brian about this fetish, he was getting a bit tense. Then, when the WinForms designer decided to crap out because of a license file problem, causing Brian to have to shut down the IDE, delete files manually, restart the IDE, etc, he got even more tense. When Don decided to rub it in with his standard, "You know, when I use Emacs, that never happens," Brian snapped. Before I even had a chance to draw a breath to put Don back in his place, Brian came right back with, "And how many products did you ship last year, Don?" A low moan swept the audience and Don turned tail and ran (after waiting a few minutes to let the ruckus die down). It was an awesome site to behold! I gained much respect for Brian that day.

I also gained much respect for WinForms. In spite of all of the hype about ASP.NET and Web Services, the thin-client backlash was in full swing at this BOF. Our room started out full and just gained people as it went on. Somewhere in the middle it became standing room only and still people came. And they didn't just sit there, either. They all participated in a very rousing discussion first about MFC/VB vs. WinForms and then onto the more interesting thin vs. rich client. These people were very tired of the limitations of HTML 3.2 and cross-platform DHTML and anxious to get back to a real development environment for UIs. Truly, the Renaissance for rich UIs has begun.

Day 3: Jason Whittington is Accused of Slut-like Ignorance

Day 3 was a big day for me. It started with a talk on a subject near and dear to my heart, generative programming. This is a relatively new term for the technology ideas we'd been using for years in building Gen<X>. Again, my room was full, not only of attendees but also of two of the software engineers from the Gen<X> team (Chris Tavares and Shawn Vanness). The audience was certainly spending a lot of time nodding their heads and understanding the benefits of generative programming, but when I showed them how far we had taken it and all of the things for which we were using Gen<X>, that took them right over the top.

And then, right after getting to pitch my favorite technology, I got to proceed right to my next BOF, where I would get to tilt at my own personal windmill -- non-deterministic finalization. Those of you who know me or my programming style know that I'm absolutely in love with the idea of objects managing their own resources and them being notified immediately when the last client is done with them, either via COM-style reference counting or via a C++ destructor. This kind of deterministic finalization allows for very aggressive reclamation of resources, even in the face of exceptions or forgetful programmers. Non-deterministic finalization, on the other hand, leaves notification that an object is no longer in use to a background thread managed by a garbage collector. Because when the GC will get around to notifying an object is non-deterministic and empirically takes a long time, this means that resources can no longer be claimed by automatic means, instead leaving it to the client to manually notify the object via a Close or Dispose method. In my opinion, this is not a robust technique in the face of exceptions or forgetful programmers.

This issue has been the bane of my existence for years. When Java was first becoming popular, I was studying to become DevelopMentor's first Java instructor. And at first, I really liked it. Then I discovered that Java had non-deterministic destruction and my life turned to ATL instead. Fast forward a few years to an early design preview of .NET where I learn that Microsoft was "leveraging" many of the ideas of Java in its new runtime, including my favorite: non-deterministic finalization. I try to explain the problems inherent in this decision, but apparently, they've been all through this and Bill Gates has already made the decision for them. Of course, I don't know this, so I kept fighting the good fight with one of the first emails on DevelopMentor's .NET mailing list. This caused quite a stir, consuming much bandwidth to this day and eventually culminating in a long, explanatory email from Brian Harry, a PM on the .NET team. This email was intelligent and thoughtful and annoyed me no end because it put the final nail into the coffin containing my hope for DF in v1.0 of .NET, which we're going to be living with for years. In fact, this email annoyed me so much that, on Day 2, I referred to it as "Brian Harry's 'little' email." After all, the room was nearly empty except for a few of my very close friends and one attendee who I hadn't met. I met him 5 seconds later. It was, of course, Brian Harry. Remember, this was the day I had almost zero sleep, so I wasn't exactly on top of my game. What an inauspicious way to meet your arch-enemy... [1].

Now, I told you that story so that I could tell you this one.

The BOF was to be a debate between me (pro-DF) and Jason Whittington (pro-garbage collection), with Don as the master of ceremonies. Imagine a thoughtful, reasoned exchange of ideas between calm, measured adults. Now throw that image away. Instead, Don introduced the BOF by saying that there was the right way of thinking and the Chris way of thinking and that I had been lured into the packed room (containing, as backup for the side of evil, Brian Harry) for an "intervention." Now, it's not as if some of us didn't try to be thoughtful and reasoned. For example, Jason gave us all kinds of background into the history and practice of garbage collection and how it works under .NET. In fact, if you haven't yet had a chance to read Jason's GC talk from Conference.NET, you should. It's great. Unfortunately, the passions in the audience and in the other side of the debate, i.e. me, left little time for Jason's approach. Instead, Don and I and the audience went back and forth, invoking stories of ASP.NET applications written by the cream of the crop at DevelopMentor that leaked so many resources as to make them unusable, laments of the semantic incorrectness of tying resource management to object lifetime and analogies of deck chairs on boats that did and didn't sink. It was somewhere between a gospel revival and a schlock talk show (in fact, at one particularly cantankerous moment, the audience was literally chanting "Jerry! Jerry!"). At one point, I got so worked up during Jason's attempts to shed some actual light on the topic that I interrupted him exclaim, "Jason Whittington, you ignorant slut!" It was one of the highlights of my life...

But that was not to be the highlight of the show. Oh no. The most amazing thing about the show was later that evening at the close of conference party, where DevelopMentor introduced the .NET Band: The Band on the Runtime, made up of speakers and attendees who were also accomplished musicians. It was an awesome mix of showmanship, musicality and parody lyrics that caused the audience to sing along, wave their candles (in lieu of lighters), jump on stage and scream for an encore. When it was over, I was so moved that, in spite of my long friendship with Don and my pride in never seeing him as the hi-tech rock star that most folks do, I had to rush backstage to shake his hand and to be in his presence. I felt like a giddy school girl hoping to snatch a sweaty handkerchief from across his brow (which I'll be auctioning off at eBay when I'm good and ready...).

Day n: The Rest of My Life

I have to say that I was deeply affected this week at Conference.NET. I'd like to thank everyone who organized it and hosted it and made it happen. And those of you who had the chance to go, but didn't? Well, on your heads be it. Don't make that mistake again next year...

Related Links

[1] As it turns out, it didn't take long to make up with Mr. Harry and I soon found him to be reasoned and intelligent. Even worse, I found that I liked him. Damn it!

0 comments




What I Love Best About .NET

Monday, 8/6/01

DevelopMentor has long attracted smart folks. Really smart folks. These are the caliber of people that forces you to look up every once and a while and question your own worthiness. With this many high-caliber people together, you'd think they'd be able to look objectively at the world and avoid such religious arguments as "What's the best language?", "What's the best platform?" and "What's the best editor?"

Nope.

We get into arguments like this (and even more esoteric) stuff all the time. Oh, open debate is healthy and we eventually come to a reasoned, balanced decision, blah, blah, blah, but these kinds of arguments made me realize that the thing I love most about .NET is that one of the most contentious arguments has just gone away: "What's the best language?" In the old days, this boiled down to VB vs. C++, otherwise known as practical vs. theoretical, simple vs. complicated or even, my personal favorite, journalism major vs. computer scientist. The argument was a real one, though, because VB6 and below put a real straight jacket on you when it came to real object-oriented features (the lack of implementation inheritance springs to mind), whereas C++ was so hard for so many people, it was almost impossible to build correct code with it. Much mud was thrown during these debates and no progress was ever made.

Until now.

Now, we have the same "What's the best language" arguments over VB.NET vs. C#, but they always peter out very quickly. While it's true that VB.NET makes it much easier to build late binding component clients and C# allows unsafe code sections, neither of these features is enough for us to avoid agreeing that, modulo syntax, the two languages overlap by about 90%. Which means, and now I'm coming to the part that really makes me love .NET, I get to work with lots more smart people at DevelopMentor. Before, it was about the star-bellied Sneetches and the plain-bellied Sneetches. Since I felt I was one with a star on his belly (doesn't everyone feel that way?), I couldn't work with those without stars upon thars! Well, Sylvester McMonkey McBean, you can teach a Sneetch! [1]

I just got off the phone with a good friend of mine who I've never been able to work with before, because we've always had a great divide between us caused by my C++ bias. Now, for the first time, we get to work together! He can do his stuff in VB and I can either work with it directly, or I can easily port it to C#, because all the classes and functions that he's going use in VB are going to be identical to what I would do in C#. So, while 90% of the language features overlap, there's 99.999% overlap in the framework and how to use it between the two languages. To answer Rodney King's immortal question, "Yes. Finally, thank .NET, we can all just get along."

[1] Those of you with kids will understand...

0 comments




Hanging Out My Shingle

Friday, 8/3/01

For the last three years, I've been in management. Oh, it started innocently enough. When the team was small, I was only managing a little bit. However, as the team grew and we got closer and closer to shipping our first product, I spent less and less time doing anything technical and more and more time managing. Eventually, I was doing nothing but dealing with the rest of the company and potential customers and "enabling" everyone else. Luckily, Don Box, co-founder of DevelopMentor and my long-time mentor, noticed that I'd been swept right out of the things that I loved the most. And he made me an offer I couldn't refuse...

Now I'm back on the consulting, teaching, writing, development train and loving it. I've been all over .NET for about a year, but now I get to concentrate on it full-time. If you'd like any consulting help in the area of .NET (or even COM and ATL), I'm here for you. Pass the word along. Thanks!

0 comments




My Favorite Books

Friday, 8/3/01

When I started writing books, I decided to stop reviewing other peoples' books. I used to have a list of all of the books in the topic of my current interest and write a little review, either pumping them or panning them (this was long before Amazon.com). Once I decided to write books myself, I figured that there'd be a conflict of interest putting down competing books, so I stopped. However, I've had lots of folks ask me for a list of recommended books over the years, so I thought I'd provide one. While I'm still biased, there's at least less conflict of interest if I just tell you about books that I love (although I'm not so proud that I don't tag each book URL with my Amazon.com associates ID...).

I would give each of these books a 5-star rating on Amazon (and, in some cases, I've done just that). These are the books that I absolutely love (in no particular order):

0 comments




My Favorite Software

Friday, 8/3/01

The following software is what I install on nearly every computer I set up. BTW, I pay for all my favorite software and you should, too. While I am guilty of "trying" friend's software, I own legal copies of every piece of software I use.

0 comments




My Favorite Web Sites

Friday, 8/3/01

These are the sites that I visit on a regular basis and like (the sites I visit on a regular basis and don't like are not listed : ):

0 comments




Choose Your Defaults Carefully

Saturday, 6/9/01

In the last week, I've been bitten twice by developers that have chosen defaults poorly and, therefore, have adversely affected my life. The first was on my Nokia phone. I was in a "meeting" with some of my key engineers (read: we were goofing off at a movie on a Thursday afternoon), and I had set my phone to Silent mode. Now, I have a Nokia 8260 (blue) that I dearly love. It kicks butt on the silly Ericsson that I used to have. However, I noticed when I came out of the meeting that their had been several calls from my blushing bride. The Nokia is cool not only because it's small enough to fit into my pocket (where I keep it during our "meetings"), but also because it has a vibrate mode. So, I figured that if the phone was in Silent mode, but the phone was still on, if someone called, I'd get the vibrate in my pocket (separate from my change and my keys to honor the spirit of the Nokia Silent profile). Unfortunately, this was not the case. Calls came in, but no vibration was forthcoming. This happened a couple more times in the next few days until I had a free moment to check the settings for Silent mode (ironically this free moment came while waiting for another movie to start today -- "Operation: Swordfish," which I enjoyed, btw). The default for the vibrate setting in the Silent profile was *off*. How could this possibly be right? It's a phone! It's on! Sure, I want it silent so it doesn't bug people around me, but I still want to know when someone calls! Hence the vibrate mode! Needless to say, my blushing bride was less than pleased.

The second time that incorrect defaults interrupted my life happened to be a bug recently found in Gen<X>. Because Gen<X> installs some COM components, we require it to be installed by an account that's part of the Administrator group. Unfortunately, the bug is that once Gen<X> is installed, another user can't use it on that machine unless they are also part of the Administrator group. Of course, since 98% of developers run with Admin privileges on their own machines, this bug was never reported by the secular community. So how did we find it? It was reported by none other than Keith "Mr. Security" Brown, who was experimenting with running at a lower level of security for some perverse purposes that I can only imagine... Anyway, when Keith calls you with a security bug, you listen (at least it was the good kind of security bug, i.e. offering less access then we should instead of more. I can only imagine what the phone call would be like if Keith discovers that we've opened a hole...). The problem with security? Defaults.

The author of CRegKey, a class in ATL we were using to read the serial number out of the Registry, built in a default access level setting. We use the Registry key when our tools are started to make sure that user has a valid serial number on their machine -- standard stuff. You need to be an Admin to write the key, but you shouldn't have to be just to read it. However, the default setting in the CRegKey::Open method is set to allow read-write permissions, as show here:

LONG Open(HKEY hKeyParent, LPCTSTR lpszKeyName, REGSAM samDesired = KEY_ALL_ACCESS);

The developer who wrote the code (let's call him "Shawn"), being a human with many tasks interested in doing them all efficiently, left off the default value, assuming that the default would be read-only. This was the correct assumption to make if you assume that the CRegKey author was specifying his defaults properly. Unfortunately, he wasn't, so when we tried to merely read the SN out of the Registry, we were asking for read-write permissions, and the read failed, causing the SN validation to fail, keeping Keith from using Gen<X> and motivating him to call me and complain about it. All due to bad defaults.

Rules for Defaults

Defaults are often set to save typing. That's a bad idea. If the Nokia guy and the CRegKey guy had but followed the these simple rules for determining defaults, my life would have been better:

  1. Apply "the principle of least surprise." I'm sure he didn't invent this rule, but it's one I learned from Don Box and it sticks with me as one of "the seven good ideas" that exist in our field (a story all its own). The principle of least surprise says that you make interface design decisions based on what people expect. Shawn expected the default access level to be read-only. I expected my phone to vibrate in Silent mode. Pretend that the default isn't even an option. What would people expect?
  2. Minimize the harm of inadvertently choosing the default. Assuming the defaults are not changed (a very common occurrence), what bad things could happen? If the default had been read-only on CRegKey, unit testing a code path that required read-write would have immediately uncovered that greater access was needed, a fix could have been immediately supplied and no harm done (except some extra typing). However, because the default was read-write, we introduce an invisible bug that Keith has to find. Likewise, if the default had been vibrate in Silent mode, when a call came in, it would still have been silent, but I would have been notified of the call. Again, no harm (assuming no holes in your pockets and that you're wearing underwear). However, because of the default, I missed calls and angered my wife. That didn't happen with the Ericsson.
  3. Change defaults sparingly. Once you've chosen your defaults and released your thing, people are going to learn those defaults and depend on them. For example, we can't go back into our ATL source and update the default to CRegKey::Open because we've got all kinds of code paths through our code depending on the default. If you change a default, even if the default was set incorrectly to begin with, you're doing more harm than good. Unless you can change the defaults without inducing harm, don't.

Unfortunately, not all developers follow these rules, so when you make use of defaults, please double-check them first.

0 comments




Other Blogs

5/16/2001

My spout page is just one of literally thousands of web logs ("blogs") available on the net. These are a few of the ones that I like:

0 comments




Rules of Engagement

Tuesday, 5/15/01

This is a page where I can just spout off about whatever. I keep it separate from my Tools page so that you don't mix up any of my spoutings with facts.

Before I  get started, I'd like to lay some ground rules. First and foremost, I'd like to warn you that every human on the planet has an agenda, often more than one. These are some of mine:

The second ground rule is that while I try to be as accurate as possible, I'm human and I make mistakes. If you find a mistake or you think my opinion is just so wrong that it requires a response or you'd just like to respond in general, feel free to send me email at csells@sellsbrothers.com.

0 comments




Object-Orientation is Over

Tuesday, 5/15/01

Java, and Java 2.0 (aka .NET), have brought with them the end of object-orientation. Of course, by that I mean that object-orientation is no longer a question -- it's just how we program. Even our scripting languages have classes and objects now. That fight is over, as are the advances in that area. Object-oriented programming, with inheritance, polymorphism and encapsulation, is just the way we do things now and Java and .NET represent the end of that line and the beginning of several others:

Generic Programming

Generic programming (aka "generics") provides the ability to write a partial type or function and let the compiler or runtime environment fill in the details based on client usage. Of course, C++ templates have provided generics via templates for a long time. Unfortunately, no modern object-oriented languages, i.e. Java and C#, have generics as yet, but they're coming. My favorite research paper in this area describes how generics can be added to .NET languages, using C# as an example, written by Microsoft's own researchers, Andrew Kennedy and Don Syme.

Generics have been around for a long, long time, so if you aren't already familiar with them, you're behind. Only C++ programmers do this now, but very soon, everyone will be.

Component-based Programming

Components differ from objects in that they are binary objects, often callable from languages other than that in which they were written. COM, Java and .NET are popular modern component development environments, but even DLLs have provided component-like features since Windows. Components provide a degree of encapsulation that often exceeds that of source-based OO environments, often at the expense of ease of use (although both Java and .NET work real hard to make components look and feel like objects).

Aspect-Oriented Programming

Aspect-oriented programming (AOP) provides the ability to define a set of characteristics of an object or a component that are actually implemented by the hosting runtime. The benefit, of course, is that it's much easier to declare the need for some feature, e.g. method tracing or the need for a component to be part of a transaction, than it is to write the code. To date, we've had pretty primitive support of AOP in the popular programming environments, but it's been there, e.g.

The .NET attribute mechanism represents a giant step forward in AOP. It's the first popular environment that provides a convenient, extensible mechanism for not only declaring attributes, but also implementing custom attribute provides, i.e. those bits of code that are activated when an attribute is encountered. Extensible .NET metadata is replacing the COM+ catalog and providing exactly what the Java serialization keywords provide and I expect most language to converge on the AOP style that .NET provides.

Generative Programming

Generative programming is the newest of these new programming styles. The term itself was boasted into popular usage by the book of the same name by Krzysztof Czarnecki and Ulrich Eisenecker. Generative programming is about representing your system's design requirements in some computer-readable form, e.g. SQL schemas, XML, UML, etc, and feeding it to some kind of metaprogram that will generate your program. The main benefit of generative programming is that as the design requirements change, your programs can be regenerated, saving you from manually replicating design changes into the code. Likewise, as the implementation choices need to change, e.g. from Java to C# or from Linux to Windows, the metaprograms can change and your programs can be regenerated, saving you from doing the porting work.

Macro languages, e.g. the C preprocessor, are generative languages for generating code within files. ASP and PHP are both generative languages for building web pages. Of course, DevelopMentor's own Gen<X>, was built from the ground up to be a generative programming tool (although we designed and built it long before we'd heard the term). Generative programming has a vast potential, I think (although I'm biased), because it encourages you to specify your design requirements and keep them up to date with the code, but also because of the potential for generating large parts of a system's code, testing data and even documentation. In fact, in building Gen<X> itself, we find ourselves generating more and more of the next version using the previous version. We don't use it for unique code, but we use it for the repetitive horizontal or hierarchical code as well as reference docs and test data. Highly recommended.

[new] Comment from Mickey Williams [mickey.williams@codevtech.com], Mon 7/2/2001 10:54 AM:

"I'd like to remind you that Eiffel has had generics longer than C++, and Eiffel's generics work on .NET. So there.

"Best regards from the Eiffel bigot,
"Mickey"

That's true, Mickey. I knew that Eiffel supported templates, but I didn't know that Eiffel# (the .NET version of Eiffel) did, so that's really cool.

0 comments




From COM to .NET

Saturday, 4/21/01

Enough people have asked me what I think about the transition from COM to .NET that I thought I'd publish my thoughts instead of responding to each individual email. This is the question that finally lead to me publishing this page in the first place.

In the early days of C, ASM was much more efficient, but C was much easier to use and as machines got faster, and C compilers got better, ASM was relegated to use by only a few. During the transition, ASM programmers were valuable and continue to be so for very targeted tasks, but they grow increasingly unnecessary. For example, in all the time that I've developed software (17 years), I've needed ASM exactly *once* (and then I just used Keith Brown : ). To this day, I have to admit that I can neither write nor even read x86 assembly. I've always meant to learn and I admit to being embarrassed that I can't, but I've never needed it. Each platform I programmed for, I started after the platform had moved away from ASM being the dominant programming environment.

As Microsoft ships increasingly stable betas of .NET towards a final release, we're nearing the end of a long and messy transition from processor-specific low-level programming to programming at a higher level on the Windows platform. To be honest, most Windows programmers are already there and have been for a while. They're the forward-thinking Visual Basic programmers. They recognized that they had no need to learn Win32 or COM. They could program at a comfortable level and make their C++ programmer friends do the grunge work for them. C++ programmers that haven't moved to VB yet had two reasons: the programs run too slowly and VB doesn't let me do what I want. With each successive release of VB, the efficiency argument has gotten weaker and weaker. Now that VB6 uses the same intermediate language and backend compiler that VC6 does, speed's really no longer an issue. The 2nd reason, "VB doesn't let me do what I want," is real and continues through VB6. The problem is really the language. There is one feature that no C++ programmer can live without: implementation inheritance. It's so useful for day-to-day programming chores that we can't give it up.

This one fatal flaw in VB6 was made very clear to me the other day when I was doing .NET programming using C#. Before we go any further, let me make one thing perfectly clear: VB.NET *is* C#. The only difference is the syntax. The language features are all the same but one: you can write "unsafe" code in C#, but not in VB.NET. Unsafe code in C# is the equivalent of  inline ASM: when you need it, you can't live without it, but you probably won't need it. So, when I'm programming C#, I could as easily be programming VB.NET. And the beauty of my experience of programming C# caused me to examine the difference between my previous VB6 experience and my current C# experience. I had a form-based drag-n-drop environment in both. I had IntelliSense in both. I had a programming model that was much simpler than raw Win32 in both. In short, C# and .NET gave me everything that VB6 gave me, but with one addition: implementation inheritance. When I needed to model the data for my application, it was so easy because I had inheritance but would've been so much harder without it. That feature made all the difference to me and is the reason that C++ programmers will finally feel free to move into the VB-like environment that .NET provides.

Will everyone abandon the Win32 API when .NET ships? No. Will everyone eventually move their code over to .NET? No. Will most folks spend most of their time programming .NET within 18-24 months of ship? Absolutely, yes. It's too compelling a platform with too many real advantages to ignore.

Does that mean you should stop all development and wait for .NET to ship? Absolutely, no. Build you components in COM today and you'll be able to move them over to .NET when the time is right (which may be never). The .NET backwards compatibility story is a good one. You'll be able to continue to make use of most of your COM components and DLLs in .NET, which means that the code you're working on today will continue to be useful long after you've moved your day-to-day programming activities to .NET. To ease the transition, I recommend marking your COM interfaces with [oleautomation] if possible. This limits your method parameters to types and attributes that .NET is particularly good at marshaling.

 .NET via C# and VB.NET is the future of programming for Windows, leaving Win32 and COM as the ASM of .NET.

0 comments




No older posts       510 newer posts