Anybody want to stage an intervention?

Craig blogged a response to my AOP post refuting the idea that AOP is in any way useful. Err, let’s see if I get this right:

    This is so full of holes you could strain your pasta through it. It’s a classic case of overgeneralization, and in and of itself that’s enough to render his argument moot. However, I’d like to examine it in slightly more detail.

Well, hey, at least he thinks they’re little holes, right? 😉

(Craig’s a friend, so while I feel no abrasion at the "tough love" approach to his response, neither do I feel any compulsion to be nice in return, so…. *ding* Round Two!)

Craig paraphrased

    Ted’s basic argument is that since XSLTO uses declarative attributes to drive execution of code, and since AOP is based around more or less the same thing, that the two are equivalent. I disagree: XSLTO is a proper subset of what AOP advocates. It is a specific, specialized utilization of declarative programming. In this case, it’s essentially a translation of XSLT into the C# realm, giving you the ability to process XML documents via recursive descent.

Well, aside from the double usage of the term "specific", I don’t disagree with what Craig suggests, except that the idea of using a subset of AOP is somehow not doing AOP. If I create "things" that contain both state and behavior, yet don’t support operator overloading, am I writing an object? The act of using a subset of the AOP feature set is the first step towards AOP–after all, look at the degree of success (COM+ and EJB being two of the most notable successes, CORBA and Java dynamic proxies coming shortly thereafter) enjoyed by using just the simplest pointcut (interception) and the ability to weave code around it.

Craig later "dissects" my argument regarding inheritance and OO by suggesting that

    I don’t miss multiple inheritance in C#, despite it being a mainstay of C++. Adding more constructs to the language adds complexity, and that complexity adds cognitive overhead that can make the tool less useful in many situations. We have this conversation on the FlexWiki mailing lists all the time: people are constantly proposing extensions to the wiki syntax that bring it closer and closer to doing everything HTML can do. Of course, at some point you cross the line where you have to wonder why you should bother with having a wiki language at all? It’s like Spider Man taught us: with great power comes great responsibility.

I didn’t say "multiple implementation inheritance", I said "multiple inheritance", as in, how useful would you find C# without the ability to inherit from a base class or one or more interfaces? I submit you wouldn’t be programming in C# or C++ if this were the case.

Craig later says,

    Just like XSLTO and AOP, XSLT is a specialized tool useful for a few very narrow problems. And just like XSLTO and AOP, it should be viewed as – although perhaps not a last resort – something you only pull out when you have a specific need, not a general-purpose tool. … At the end of the day, I guess what Ted and I disagree on is the extent to which AOP concepts are useful. I say, ?very little, but not zero?, and he takes a view that is presumably much broader than that. I view XSLTO as a useful replacement for some of what XSLT does. And I view XSLT as a useful replacement for some of what the .NET XML APIs do. But most of the time I’m going to stick with my favorite API, XmlSerializer, and stay the hell away from frameworks that drive execution via declarative means. I take the same attitude towards (other) AOP frameworks: I’ll use them when I’ve exhausted other options, and not before.

That’s fine, Craig–take the drug in small doses if you must. Just remember, the first hit’s free, kid…. 😉

Predictions for 2005

I’m taking a shot at this a little earlier last year’s, where I wrote my predictions on January 1st, but I’ve got a bunch of things to work on coming up, and I don’t want to ruin the tradition. Yes, folks, it’s that time of year again where I look back at the predictions I made last year for 2004, see how right or wrong I was, then take a stab at what I think might (or might not) happen for 2005.

First, a look back; for 2004, I predicted….

    .NET will gain in acceptance. This time, I admit it–I have a definite reason for wanting this to happen, but I can’t say anything concrete until the 13th of this month. Keep your eyes (and blog aggregatrs) peeled….
    Java adoption rates will hold steady. As I said above, between the J2EE 1.4 release and the J2SE 1.5 release forthcoming (we hope), and the gradual restoration of our economy (assuming our Fearless Leadership in Washington doesn’t screw it up somehow), Java should once again start to see some serious work happening.
    J2EE/.NET Interoperability will rise. Hey, if neither platform is going away anytime soon….
    Peer-to-peer will finally go away. I hate to break it to you, but peer-to-peer technologies are basically all about "discovery" as a lookup technique–once you have that, you’re back to plain vanilla communications options. Can we just let the term die in peace, please? It’s not going to democratize the world, folks….
    XML will start to lose its luster. People are finally beginning to see the object-hierarchical impedance mismatch, and realize that "objects" and "XML" don’t, in fact, go together like peanut butter and chocolate. More like apple cider and wine, if you ask me. XML will continue to be in demand, but on its own, as a data format, rather than as "another way to express an object".
    Microsoft will get sued again. Hey, it’s as certain as the sun rising on a hung-over nation tomorrow.

So let’s see how the year in review looks:

    .NET will gain in acceptance. I don’t have any numbers to back this (and you shouldn’t trust numbers unless you know the source, anyway), but anecdotally it certainly feels this way. More importantly, my comment about the 13th of 2004 was of course related to the official launch of TheServerSide.NET, and I’d like to think that in a very small way we had an effect on bringing .NET to the world. (Note I said "very small way"; I sincerely mean that. Very, very small. But still something.)
    Java adoption rates will hold steady. Again, no hard numbers, but I haven’t heard of companies abandoning Java in droves, so I’m guessing this was also right. Where did all the .NET growth come from, then? Mostly people migrating from legacy COM projects up to .NET, I believe. There was a few situations where Java folks "crossed over" to .NET, but those folks were looking for Java-on-Windows solutions in the first place anyway. And, for what it’s worth, there were a few .NET-to-Java "crossovers", as well, so thus far I think it’s been something of a push in the long term.
    J2EE/.NET Interop will rise. Not substantially, but people are starting to talk about it. I got a lot of requests (about 60/40 from .NET and Java groups, respectively) to talk about this, and more than just the Web services story.
    Peer-to-peer will finally go away. Napster who? Oh, by the way, did anybody pay attention when Napster relaunched? Turns out that sharing music really isn’t about p2p, after all…
    XML will start to lose its luster. People are coming around to hate XSD Schema. Critics are popping up everywhere. Dave Megginson has a new book out, in fact, that basically takes everybody in the WS-* stack to task over creating specs before seeing if they’ll actually work. In fact, the only successful application of XML thus far that anybody but a developer feels is weblogs and RSS, which obeys none of the classic rules of an XML spec. (Read his book, by the way–it’s an eye-opener, particularly if you’re one of the XML faithful, or if you’ve been thinking that XML will somehow make the computer world a safer, saner place. I’ll put the Amazon link in here when I get a chance, but it’s his latest from Addison-Wesley; shouldn’t be too hard to find.) XML is useful, but we’re starting to see the warts, and behave accordingly.
    Microsoft will get sued again. Hey, there’s only 10 more days left, but there’s been no major lawsuit thus far, so I guess I missed this one pretty badly. (Of course, the April 2nd agreement pretty much took away Microsoft’s major aggressor out of the picture, so unless IBM files suit over something….)

Overall, I guess I did pretty well, but then again, these weren’t exactly eye-popping predictions, either. I’m certainly no Nostradamus.

In fact, I think I’m going to hold off posting my 2005 predictions for now; I think I need some good meditation time (and a couple more cups of heavily-spiked eggnog) to figure out what 2005 holds in store for us, and what that might mean for us all.

In the meantime, I wish all of you a very happy–and safe–holiday season. May you find in this week and next the happiness and relaxation and spiritual/soulful fulfillment we all need to get through the next 365 days. (And maybe a cool present or two, too.) 🙂


VirtualPC ran too slow, and VMWare runs too fast?

Frustrated with VirtualPC’s stubbornness about running on my T42p with anything resembling decent performance characteristics, I decided to try converting a few VPC images over to VMWare 4.5 and give that a spin instead. My basic reaction thus far can be summed up as:

    "Hmm, kinda works a lot like VPC."
    "At least it runs faster than VPC does; that’s a relief."
    "Wait, why is my clock out of sync with the host…?"

Turns out that inside the VMWare guest image, the clock is running faster than on the physical hardware, and I’ve not the slightest clue as to why. Google hasn’t yielded up any secrets here–lots of hits on why the clock is running faster inside a Linux guest, yes, but not when the guest is a WindowsXP image. Anybody got any good leads on how to correct for this? It’s annoying at best, but I fear for what happens if I get going on some serious development and the clocks aren’t synced across VMWare images using shared folders, since tools like Ant and others tend to rely on accurate representation of time to do compiles….

Any help?

Dude, what happened to my language?

Way back when, before I got into C# or Java, I was a pretty hard-core C++ developer. I knew the rules for member overloads, I understood the ambiguity rules, I could play with pointers, the whole nine yards. I wasn’t a master in the sense of the true C++ Adepts (Meyers, Alexandrescu, and so on), but I certainly qualified for Journeyman or possibly even Master status.

While playing around with Google this week, looking for something completely unrelated, I came to realize that the "stagnant" world of C++ that I more or less left behind back in 1998 hasn’t been all that stagnant. Oh, sure, I knew that people were sort of playing around with templates and other things–Alexandrescu’s book "Modern C++ Design" was a great read, and I thoroughly enjoyed it immensely, even if I had to admit to myself that it’s been a LONG time since I understood C++ template rules (not helped by the fact that they’ve changed some since I last did C++ on a daily basis)–but I had no idea things had gotten so… advanced.

What I ran across, of course, was the Boost libraries, which provide a whole slew of free/open-source C++ template libraries, ranging from "function" ("Function object wrappers for deferred calls or callbacks") to "mpl" ("Template metaprogramming framework of compile-time algorithms, sequences and metafunction classes"), to "pool" ("Memory pool management"), to "preprocessor" ("Preprocessor metaprogramming tools including repetition and recursion"). They’ve even got "lambda", which describes itself as "Define small unnamed function objects at the actual call site, and more". Sounds kinda like closures….

In short, Boost contains more than 50-some libraries that provide some pretty interesting functionality, including one that I’m going to have to spend some serious time exploring: "spirit": "LL parser framework represents parsers directly as EBNF grammars in inlined C++". Hmmm…. C++ as a language for expressing DSLs, anybody?

Gotta admit, maybe it’s time to go back and explore my programming roots; some of this stuff sounds pretty interesting and, better yet, pretty powerful. Maybe I was too quick to jump to the managed world…

Is, or is not. There is no should.

As a kid, one of the most powerful philosophies I heard was Yoda’s admonition of Luke in the swamps of Dagobah:

    Luke: All right, I’ll try.

    Yoda: (emphatically) NO. Do, or do not. There is no try.

For some reason, that quote stuck with me all through my late childhood and adolescent years. Either accomplish what you set out to do, or don’t bother. Just "trying" implies that you accept the possibility of failure, and to accept the possibility of failure implies that you aren’t going to give it your full effort.

(As a side note, just in case my folks ever read this blog entry, I didn’t say I always obeyed this philosophy–there were a number of tasks I "tried" rather than "did"–but it stuck with me nonetheless.)

Frequently, when I teach a class, students often call me over to their machines to help debug lab problems, because the results they expect aren’t the results they get. When I ask them what’s happening within the code, they often say, "Well, the system should be…." That’s when I have to stop them with my own rendition of Yoda’s quote:

    Ted: (emphatically) NO. The system is, or it is not. There is no should.

See, when programmers start to believe in "should", they’re making an assumption that the system is behaving the way they think, and those very assumptions turn out to be what’s not happening. But because they have faith in the "should", they never go back to verify their assumptions, and as a result, spend hours banging their heads against the wall trying to figure out why it’s not working.

Any time you find yourself saying (either to yourself or your teddy bear–you DO have a teddy bear debugging tool, right?) "The system SHOULD be ….", remember Yoda (and the sharp crack of his gimer stick on your head) and verify your assumptions. Look at the output of the code that SHOULD be sending rpc/literal SOAP messages to the server. Look at the generated code for the server that SHOULD have been built from the WSDL document. Look at the connection status of the socket that SHOULD be open. Look at the server that SHOULD be running, deployed, and available. More often than not, a quick verification of your assumptions will reveal the problem far faster than a rigorous debugging "binary chop" algorithm. And at the end of the day, anything that speeds my debugging is a Good Thing if you ask me. 🙂


VMWare guest-to-guest networking

I’ve been trying to live the VMWare lifestyle for a bit now, and I’m having a familiar problem that I ran into in the VirtualPC world, that of getting two guest OS’es (both Windows, for now) see each other and be able to contact one another.

In particular, I started by trying to get Simon’s "axis.tcp" sample to run talking to one another, and neither one seemed to want to talk to the other. I realized that Windows Firewall was getting in the way, so I shut it down on both sides, and it appears to enable basic networking–I can telnet from the Java/Windows guest to the DotNet/Windows guest over port 80, and vice versa, so obviously basic TCP/IP is working, at least for HTTP. But FTP doesn’t want to work for some reason, and I can’t get Simon’s simple TCP sample to run, either. So before I start hunting up all sorts of reasons why, I want to verify my basic assumptions about how VMWare networking works and make sure that I’m not missing something.

I’m assuming that the TCP/IP stack in Windows will essentially choose whichever of the two network adapters (VMWare’s "NAT" and "Host-only" network adapters, respectively) is enabled and able to communicate, but I’m concerned that when running in disconnected mode (that is, my laptop isn’t plugged into a network) it decides wrongly and tries to use a network adapter that requires a host IP address; this is where I’m not sure what’s going on, precisely–does the NAT adapter require a host IP address? Should I assign static IPs to the guest OS’es so as to avoid this problem, and if so, which network adapter should I use?

For the record, I really don’t care about accessing the public Internet from the guests–it would be nice, but not required. And Google hasn’t helped much, at least not with my naive keyword-based queries. Any pointers to help on the topic (including VMWare 5, which I’ve just downloaded but haven’t installed yet) would be awesome.

Practical Indigo Troubleshooting Tip #1

While firing up an Indigo service on a fresh VS2005 Feb CTP/Indigo Mar CTP install, I ran across an interesting exception from the service when I pinged it (with a GET request from a browser):

The tracking (workstation) service is not running
Description: An unhandled exception occurred during the execution
of the current web request. Please review the stack trace for more
information about the error and where it originated in the code.

Exception Details: System.Net.HttpListenerException: The tracking
(workstation) service is not running

Short story: make sure you’re running the "httplistener" service in the background–for some reason it doesn’t look like it gets started by default. "net start httplistener" usually does the trick.

(Mucho thanks to Kenny Wolf at MSFT for this tidbit.)

I’m going to Amsterdam

Just got this email from Arvindra Sehmi and Beat Schwegler, who are the track chairs for TechEd Europe (July 5-8):

    Arvindra and I co-own the Architecture and the Connected Systems tracks @ TechEd Europe. In this capacity, we’re responsible for selecting the best speaker together with their best sessions. That’s why we’re really excited to have you as a speaker in our tracks.

    We’d like to confirm that you’ve been scheduled for the following two sessions:

        The Fallacies of Enterprise Development
        The Day Indigo met the Tiger

    Ironically, that second presentation was one I also proposed for JavaOne….

    This won’t be the only time I’m off to Amsterdam this year; in fact, I’m headed out there for the SDC show at the end of this month:
    which should be fun, because I’m doing a suite of four talks on Indigo, mostly based around the slides Microsoft gave at the most recent Indigo SDR–then I get to repeat the experience, this time with Steve Swartz to help bail me out of the hard parts, at DevTeach in June. 🙂

    Indigo, Ho!

C’mon guys, please?

So I’m playing around with VS 2005 Beta 2 tonight, specifically the System.CodeDom.Compiler APIs, and I’m intrigued by one method on the base class CodeDom interface: Parse, taking a System.String, returning a CodeCompilationUnit, which is the root of the CodeDom interface. I’m thinking, "Now this is an interesting enhancement", because in the v1.x bits, the ICodeParser implementations of CSharpCodeProvider and VJSharpProvider, among others, were null (yep, just returned the constant null–no implementation whatsoever), depriving the .NET world of a doorway to some incredibly useful functionality.

So I fire up a CodeDomProvider for C#, call Parse… and get a NotImplementedException. WTF? VJSharpProvider… NotImplementedException. How about ANYone? Nope: JScript, MC++, VJ#, JScript, C#, not a single one provides an implementation to the Parse() method.

This is an open call to the .NET CodeDom team: If you’re not going to provide even a single implementation, then just rip the damn thing out and quit teasing me. Actually, go one step better, and actually provide what would be an awesome enhancement to .NET 2.0. Disgusting.

Carlos tries to one-up the .NET BCL team

Carlos wrote (in comments) in response to my last CodeDom post:

    After all these years, still no way to build an AST from source. Tsk, Tsk, Tsk. Recall, you had this in Java when they moved the compiler away from native, that was when? JDK 1.2, just look at the internals.

Carlos, quit being silly–if I wanted to look at internals, I would go read the source for the publicly-available and openly-licensed C# compiler that comes with the SSCLI tarball. That’s not the point here. The CodeDom already has the capacity to go from source to compiled assembly (something which Java still lacks, by the way) using the ICodeCompiler interface of the CodeDomProvider class (which Microsoft dutifully provides for each and every one of their languages, by the way). That’s not what I’m looking for; what I want is the ability to go from source to CodeDom tree representation (a CodeCompileUnit), so that I can go into the AST and hack up–or amend, or weave, or whatever you want to call it–the code from there, then feed it back into the Compiler and have good code come out the other end. And, since CodeDom is language-agnostic, it means I could conceivably… (wait for it) have aspects that are language-agnostic, as well.

This is not a hard problem to solve, in many ways–I could, for example, get hold of the various language grammars individually, feed it into ANTLR or SableCC, then compile into standalone assemblies and use that to produce the AST desired. That’s not the point, either. I want the CodeDom functionality–to take source, go to a DOM-like tree of elements that I can muck with, then from there go either back to source or to compiled output. I can go from source to compiled assembly in a snap, as well as from DOM to compiled assembly (meaning I don’t have to worry about doing bytecode generation). What’s missing is source-to-DOM.

But in the meantime, let’s also quietly ignore the fact that, unfortunately for Carlos, technically you can’t redistribute anything you write that makes use of the javac classes/internals (since you’re not allowed to redistribute the JDK or any of its constituent parts outside the JRE). Carlos, I hope you don’t get any phone calls from Sun legal staff anytime soon asking to take a look at your code for license violations….

And, if I’m not mistaken, the rewrite occurred with JDK 1.3. (I can check with Neal Gafter or Josh Bloch if this is a serious point of contention; they probably remember a lot better than anyone.)

So, with all due respect, Carlos, once again you’re playing at FUD. Sad, really, because Java has enough good reasons to hold its own against .NET that it doesn’t need this kind of "support"; it just makes Java proponents seem like zealots.