New Week, New Job. [The .NET Guy]

So the .NET guy has gone from downtown Denver to Colorado Springs?  Brad, I hope you live in Castle Rock and not Boulder:-)

Interestingly, I also heard today that Qwest is doing a lot of .NET and has adopted XP (the process, not the OS) across all their development groups.  That sounds like big stuff, now we get to blame .NET for our phone service ;-)  Although if you're against the BigCo mentality, Qwest is probably dead last on the list of potential employers in Colorado.

Why do developers choose one programming language over another for a given task? [Joel on Software]

There's lots of reasons why, but for me, I think the answer is another question: What programming language will make me most productive trying to accomplish this task?  A brief list of considerations:

1. What languages do I already know?
2. How much bit twiddling do I have to do?
3. Does a particular language have features that lend themselves to the task?
4. What languages do I like best?

I'll freely admit that I could often make better choices on languages.  #1 for me is the primary constraining factor.  And regardless of the amount of bit twiddling involved, I can't think of a reason to execute MASM ever again.  One thing I've always loved about Perl is the fact that you can do a tremendous amount in 1 line of code, but I think that that's been my barrier to adoption: I can do so much in a few lines that I never bother to write more.

I think that the strength of .NET must be in the framework class library.  The FCL is the great leveler among languages; for example, now I have Regex parsing on a par with Perl's in any language on .NET.  I think that in the future, C# will, for better or worse, become the defacto standard on .NET, if it isn't already.  But I also think that there's more to productivity than what component architectures offer, and more to it than the syntactic sugar a language provides.  Maybe all the recent controversy has been over whether we prefer braces or indentation or if...then...endif, and Joel seems to think that having a choice of languages is a bad thing, or at least a red herring.  I disagree; I believe that there's a compelling case for a language that allows me to glue components together in a natural way.  So maybe the VB vs. C# vs. Managed C++ doesn't make for a very compelling argument.  Let's throw something interesting in the mix and see what happens then.

Sam Ruby and Guido Casper have some coverage of David Bau's essay on JWS. This is interesting stuff; I'm trying to learn about constructing web services in Java because, well, because my employer says to. But that's another story.

It looks like JWS aims to implement something like the .NET style attributed programming using Javadoc extensions. For example, jws:operation is functionally similar to [WebMethod]; it causes a method to be exposed in the WSDL interface. The XML map feature looks very interesting as well, though the .NET approach would be to add attributes to the definition of the class being serialized. I've been experimenting with alternate ways to do this in .NET, using SoapExtensionReflector. I should say that Attributes are one of my favorite things about .NET, and I'm going to miss that in Java.

On the other hand, the asynchronous operation semantics built into JWS look very interesting, and I don't know of a way to accomplish the same thing in .NET.  This is related to something that I've had on a low simmer on the back burner since seeing Patrick Logan and Peter Drayton's presentations at DevCon; namely the idea of a callback style web service interface.  I don't think that it would be too hard to do and I have a specific application in mind for my employer, but I just haven't had the time to pursue it.  I believe that all this would take in the simplest case is that the caller would have to provide a soap endpoint that implemented a predetermined WSDL contract.

Finally, the concept of JWS controls looks to be really powerful, although in the specific example of a JDBC control, I think .NET gives a really nice framework to begin with.  One thing that concerns me though, is the emphasis on JMS for messaging and pub/sub style services; it seems to me that maybe the tuple spaces implementations that I've been reading about might be a more generalized choice.  But I'm really in over my head here, I need to learn more about that topic before I go spouting off about it.