Daniel Earwicker

Daniel Earwicker danielearwi​cker I used to be language agnostic, now I'm language atheist

I blog therefore I think.

Niner since 2008

  • Using the Windows Runtime from C++

    The more I read/watch about WinRT, the more it seems the list of "things you can suddenly do" seems inescapably identical to the claims being made nearly 10 years ago for the CLR.

    A common type system (which in fact builds on a metadata format taken straight from the CLR), a common platform that multiple languages can interoperate with, a big and ever growing library of APIs exposed via that platform, starting with a common system of collections, and then a common way of doing generic types, etc.

    Just as C++/CLI meant that C++ was part of the CLR environment, in precisely the same way we now have C++/CX for WinRT as described in this talk. As the team discovered, C++/CLI has a lot of good stuff in it, so it just makes sense to do it that way. One reason for this is that the CLR (while by no means perfect, lacking multiple implementation inheritance) has a lot of good stuff in it, and C++/CLI was an elegant projection of that feature set.

    IL code can have pointers and can so corrupt the entire process address space if it feels that would be helpful (available in C# via unsafe code). So that is not a unique capability of native code. Again, CLR and WinRT are (sadly) of one mind on that score.

    So far all I've been able to detect that is different between the two is that CLR has a compacting generational mark/sweep garbage collector and WinRT does not.

    Viewed from this angle it seems largely like an exercise in repeating the entire CLR design program but this time not using a sophisticated GC, substituting in its place very basic reference counting in a free store, per OLE circa 1990.

    Is there anything being announced here that could not have been achieved by building the whole WinRT atop the CLR? Bearing in mind that Herb's advice (use ISO C++ everywhere except at the boundaries) could also be followed in exactly the same way in C++/CLI.

    The flat memory space is just an abstraction. It is not necessarily a more fundamental underpinning than any other (it has to be simulated by the virtual memory system). And if you are concerned about security, it's a poor choice of abstraction for application programming, to judge by the constant stream of exploit opportunities being discovered and patched in code that has buffer overruns, dangling pointers, etc.

    So, not a step backward (because all the old stuff is still there), nor a step forward (because it so closely resembles a subset of the old stuff). A step sideways?

    The piece I'm missing from all the talks/articles is a justification, a philosophical basis, an over-arching motivation, for why Microsoft needs (and MS thinks the world needs) something exactly like the CLR but without the GC.

  • The History of Microsoft - 1995

    This "Microsoft BOB" sounds excellent! I hope it's ready soon... And with over 14 years of development time it must be even better by now than it appears in the video!

    Cool

  • Raja Krishnaswamy and Jesse Kaplan: CLR 4 - Inside No-PIA

    It becomes more of a problem as a project evolves over several years, especially with independently developed components going into it.

    Over time, the number of cases where proxy classes are needed grows until they blot out the intention of the "actual" code, which is when a language feature becomes valuable.

  • Raja Krishnaswamy and Jesse Kaplan: CLR 4 - Inside No-PIA

    Bah... based on this, I'm guess the answer is no.

  • Raja Krishnaswamy and Jesse Kaplan: CLR 4 - Inside No-PIA

    So this Type Equivalence... are we talking about something that might be the basis of "static duck typing" as in C++ templates?

    e.g. public static void Foo<T>(T arg) where T : IBar

    Currently this means T must implement IBar... will type equivalence open up the possibility that T could be something that satisfies the method signatures of IBar, but doesn't necessarily have to implement it?

    That would be great. Suppose I have to work with several third party classes, they all have a method:

        void Log(string str)

    but they don't implement any common interface. I might write:

        interface ICanLog { void Log(string str); }

    Would I then (with some attribute magic?) be able to assign instances of those third party classes to variables/parameters of that interface type?

        ICanLog canLog = new ThirdPartyThing();

     

  • Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

    Thanks for that answer. I'd certainly hope that there is no intention to drop everything from VB.NET into C#. Several people have mentioned XML literals as something "cool" to bring into C#. XML may have been cool when that feature was added to VB.NET, but JSON has taken over since then, and who knows what will be next? The C# approach is already much better: anonymous types give us free-structured object literals, which can easily be flipped into any stream format by a library function (e.g. JsonResult in MVC), so C# already has this problem solved.

  • Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

    So does this mean that C# will be getting the equivalent of VB.NET's "When" keyword that can appear after a Catch, to control exception filtering?

    To briefly recap the issue, in C# today we can only filter exceptions by their exact type, or by their location in the type hierarchy (catching a base type). Unfortunately that isn't very useful because exceptions are not generally organized into useful type hierarchies. Deriving from ApplicationException to indicate "non-fatal" is now discouraged, for example, so in fact it should be expected that custom exception classes will all derive from Exception. Meanwhile, due to the lack of flexible exception filtering, the Exception Handling block of the Enterprise Library suggests catching the universal Exception base class, which directly contradicts the advice of the CLR program manager. The CLR team also suggest using VB.NET (or hand-written IL) to get access to "Catch/When" functionality from languages that don't have it such as C#.

  • Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming

    I love the way Erik says "Func" at about 10 minutes into the video. It reminds me of the classic "Rock Me Amadeus" by Falco!

  • Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming

    Yes, I saw that Hoare quote. That's the same conclusion I get to in that blog post, i.e. "It's not immediately obvious that it is [a bind function], because a Bind function talks to its caller in terms of values wrapped in the monad, but deals in "naked" values with the function passed to it. But IfNotNull uses ordinary reference variables in both situations. This is because there is a feature missing from C#. It ought to be possible to somehow tag a reference variable to say that it is definitely not null."

    In Spec# they used MyRefType! (exclamation suffix) to mean non-nullable; so the default is wrong but they were aiming at backward compatibility with C#, so they had to go that way. And then they would just look for an if (myVar != null) and silently make myVar non-nullable within the truth block.

    It looks like the closest we'll get to this in real C# is the Code Contracts library in CLR 4.0, but I really wish non-nullable was the default. Unfortunately it complicates the syntax in some areas (where should non-nullable instance fields in a class be initialized?) but it would surely have been worth it, as Hoare says.

  • Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming

    Given that reference variables can already be null or else point to something useful, don't they already have what is needed to represent the maybe monad? All that's lacking is the convenience of bind. An extension method can act as the bind operation and that's all you need, isn't it? Or have I missed something (I'm relatively new to Haskell!)

See more comments…

Staff

Here is a list of Channel 9 staff members.

Creative Commons License

© 2012 Microsoft. Except where designated as licensed by
Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License,
Microsoft reserves all rights associated with the materials on this site.