Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

What is the value of the common runtime?

When I first heard of .NET, I was at an MS conference on mobile devices, learning about C#, and why I should learn C#.  The language (which I still want to call "C-pound" :-) is compelling in a number of minor ways, but at the time I couldn't see any advantage to dropping my productivity to zero for a couple of weeks to learn it over the languages I already knew (C++, Java, Perl, and several ECMA script-based languages).

The reason I thought I could make this assertion is that according to MS, all the languages use the same runtime and play together seamlessly.

The flaw in that assertion, it turns out (at least as far as I know) is that the only way that C++ and the other languages play well together if you really intend use .NET technologies is if it is "managed" C++.  Managed C++ seems to be a bastardization of the C++ spec to include all the COM stuff that MS has been pushing for a while now, and it makes C++ look and act a lot like C#.  Not that I'm actually complaining that they simplified what until now has been a maze of macros and template arguments, but it's not really just C++ anymore, and I have to learn some new syntax and usage anyhow.

So, I guess the guy at the seminar was right afterall when he said we should learn C#:  It appears to be much more tailored to the task at hand (managing all those COM interfaces), and you're not worried about how the MS bastardization of the language is going to affect your coding style, since C# was designed to do this stuff in the first place, and there's no pesky standard (or preconceptions) to adhere to.

So, It appears that the true value of the common runtime is to provide an affirmative answer to the market when it asks "But does it support X, the language I'm used to?"  Of course, I think they should also disclose that the language you're used to is no longer going to be familiar...

[Please correct me if you think I'm wrong:  I love being wrong, because it's one of the best ways to learn something new.]


Greg Spencer
Thursday, September 19, 2002

Managed C++ has to make some concessions to be able to interoperate in the world of managed.NET code.

If it was just C++ then you would have to constantly do all the interop leg work yourself which is tedious and prone to errors.

From what I have seen of .NET, part of the benefit of the runtime is considerably more compatibility between types and languages. You can now write classes in VB.NET call them from C# and have the types marshalled quite seamlessly. Previously you had to use IDispatch interfaces, BSTRs and VARIANT types to get this behaviour.

For me personally they have done a pretty good job with the libraries, providing much more consistency between the Windows App world and the ASP.NET web world. More consistent librarys and a much simpler way for people to use languages such as C++ to write code to process web pages and provide smart logic in C# without having to use VBScript or ActiveX (I personally always found the world of "everything  is a variant" less helpful for programming). Faster to write, and more consistent.

There are obviously trade offs, traditionally in the C++ world I avoided things like MFC ..etc because the performance hit was considerable, they linked to most known DLLs statically (not even delay loaded) bloating application working sets considerably.

With .NET I am more included to give it a better chance.

One of the theories of the CLR is that having an overview of all your application it should be able to assist in performance automatically particularly with memory management, although its still no substitute for good programming.

Chris Turner
Thursday, September 19, 2002

I think it's a bit deeper than being able to say "Yes, we support Object Snobol."

Learning a new language is really rather easy. 90% of the differences are just cosmetic - a different way of saying the same thing. Picking up the bits that are truly different isn't that hard.

What brings you to a screeching halt is the new library. New organizing principles, new names, new parameter orders. You can't do anything without checking the documentation.

To me, the big promise of the Framework classes is that they co-opt one of Java's big wins: "Learn once, work anywhere." Once you learn the FCL, you can switch gears to work in pretty much any .Net language - the differences are just in the syntax, not in each every primitive routine.

Jon Shemitz
Thursday, September 19, 2002

Agreed. The CLR makes many of the COM-centric things that create headaches go away.  .NET is really just a better COM.

We were just discussing the other day how much time we spend -syncing- code to work with other code(VB and C++), than actually writing the logic code to do the work.  .NET takes care of the syncing for us.

The idea of including metadata with the IL code, is reason enough to give .NET a chance.  Ever had a typelibary get called up that NO-ONE has updated for years? Now that's a headache i really don't need....

Thursday, September 19, 2002

Hmm, so maybe the real message should be "you should learn the FCL and the rest of the .NET interfaces" instead of "you should learn C#".  I agree that new languages are easy (Actually, C# is even easier than most, especially if you already know C++ and Java).

Greg Spencer
Thursday, September 19, 2002

Good point, Greg.  In fact, when people ask me if I'm a C# or VB programmer, I tell them I'm a "CLR Programmer". 

David Weller
Thursday, September 19, 2002

The original post makes an interesting point about having to learn a new language. I think the idea was to enable programmers to transfer to the CLI without them having to learn a new language.

So, what is so special about the CLI? The safety of the managed execution environment in the CLR. This makes serious component-based engineering possible. (Portability is just a bonus.)

And what other popular environment has managed execution? The JVM! So the goal for the CLI is differentiation: I think Microsoft's play with the CLI is to build a modern platform that will create a supporting component market, whilst reducing the cost of adoption by allowsing programmers to use whichever language they happen to be most comfortable with.

I think the language "story" has not been well-realised so far. C# is, in my opinion, a nice language; but the many changes to Visual Basic, and second-class support for C++, has made C# the language of the "C# Language Runtime".

I think Microsoft will take care of these problems in future releases by supporting C++ better, and providing easy wrappers for Visual Basic programmers to consume.

Dominic Cooney
Thursday, September 19, 2002

*  Recent Topics

*  Fog Creek Home