Who needs value types anyway?

  • Article

I've totally lost my voice (quite literally cannot talk) here at the PDC and had to miss the Ask the Experts session just to try and get it back before my panel discussion tomorrow. But while I could still talk I've enjoyed conversations with all sorts of people here in LA. I attended a BOF which contrasted .NET with J2. In the spirit of a BOF I kept my mouth shut to listen to the community feedback. There were some interesting points.

The crowd was mostly self selecting working in Enterprise software. They had some high level key points that most (but not 100%) agreed with:

  • Productivity is key. These folks make their money getting projects done on time with simple and maintainable code.
  • Performance needs to be good, but most of these folks weren't going to eek 100% out of their code.
  • All generally felt good about the fact there is healthy competition in this space and hoped it would continue.
  • There was a balanced conversation on the pro's and con's of each environment, the tools, and features. In the end I don't believe a clear winner was declared outside of a specific context here and there.

There were a few conversations worth mentioning:

Value Types

Many felt that Value Types weren't necessary, especially when writing Enterprise software. Classes were deemed sufficient, and having this extra construct was just one more thing to see in the language. I can understand this desire for simplification. I've seen James Gosling make similar statements of dislike for things like 'unsafe' pointer access too (his argument being rooted in security ramifications). But we had many segments in mind when designing the CLR type system. It really is our desire that one can write a broad range of code and get "on the metal" when you need to with the system. A system like Avalon requires that kind of advanced support to get the right kind of performance. Having a structure that can be laid out "in-place" (on the stack or in an object instance) is very useful for performance. It allows us to do very fast in-process remoting for example, and reduces the overhead of tracking. The good news is a .NET language can pick and choose what it would like to support (don't like unsafe? don't expose it). The user can chose to do the same, and back it up with static code analysis rules if you like.

Generics Comparison

Ahh the classic debate. This one always boils down to two points: (1) kudos to .NET for making generics intrinsic to the CLR itself (faster and readily accessible at runtime) and not using type erasure, and (2) kudos to Java for shipping faster than we did. The usual debate after that comes up: do I really need all these silly incomprehensible <<>> stuff in my code and aren't collections the only killer? It is true that collections are the "poster-child" for generics. But consider that having generics in the CLR type system enables LINQ to easily statically compose expression trees. You will find generics heavily leveraged through the LINQ definitions. Generics are also key to solving another vexing problem, Nullable data types.

Speaking of LINQ

Many that saw the five minute demo of LINQ in Jim Allchin's keynote were tempted to call it a EJB knock off. I hope they were able to attend Anders' full session because I think people weren't seeing past the table/attribute mapping syntax used to declare SQL tables (a very minor part of this story). I wouldn't call that piece an EJB knock off, rather I'd point out that embedded SQL has been doing automatic mapping of SQL metadata into field definitions for a few decades now. The interesting thing about LINQ to me is the seem less way in which you can compose any IEnumerable<T> source into an expression (SQL data, CLR type data, and XML). As with most of the designs Anders' comes up with, it is quite simple and elegant. In contrast, a SQL precompiler can only handle SQL syntax and basically just turns that syntax into database library calls under the covers. As to other concerns, there are also designs in LINQ to handle query optimizer hints and other required features so you don't wind up sucking all the data down in unhealthy ways. I'm very excited to see what people will build with this stuff.

The other more generic thing that is interesting about LINQ is the fact it could be built up stack from the CLR on the 2.0 code base with no changes. A rich type system including Generics makes that possible. We still have a lot of things I'd like to add to create an even stronger base (LCG was a great start for dynamic language support, but we have more coming). But it is interesting to see the innovation start to move upstack from the engine.

 

We are still here tomorrow in the lounge, and we are running several more CLR sessions tomorrow. Please make sure to come see us, and please have a safe journey home after the conference.