Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Daniel Earwicker

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

Niner since 2008

  • The Future of C#

    @Levente Nagy: You're talking about the VB type switch feature?

    Type switches are needed sometimes. "Polymorphism" traditionally means that the method implementation is chosen based on the type of a single object, AKA "single dispatch". But this means it is no use if you have two objects and you need to use different code for different combinations of types, AKA "multiple dispatch".

    Often when people encounter a situation like this they think "Oh, I must have designed my program all wrong. If I'd done it right, this situation wouldn't have happened". But it's not true. Some situations involve dynamic dispatch based on the type of more than one object.

  • Inside .NET Native

    Just adding my voice to the clamour for Desktop support!

    Would love to see a way to statically link those parts of the .NET framework that I'm using into a native code EXE or DLL, allowing it to be used to write shell extensions, office extensions and other kinds of native components that have previously been hamstrung by heavyweight side-by-side runtime versioning issues.

  • Anders Hejlsberg: Introducing TypeScript

    Lots of critics saying "why not just use an existing language"? One thing people seem to be missing about TS is that it already has a BETTER type system than most previous mainstream high-level languages.

    It's structural instead of nominal. In C# and Java you can have an interface IFoo with method Bar, and a class C that has method Bar with exactly the right signature, but C doesn't implement IFoo unless you edit the definition of C accordingly.

    Whereas in TS, C already implements IFoo merely because it has the right structure.

    This is already an excellent improvement, but when they add generics to TS it's going to be a big  improvement on C#. An interface could be used to specify a constraint on a generic parameter, but it doesn't mean that a generic argument has to nominally implement the interface. It just has to have the right structure.

     

  • Anders Hejlsberg, Steve Lucco, and Luke Hoban: Inside TypeScript

    Obviously there are advantages to TS being a very thin layer over JS, so the output code is recognisable (having tried it the results are very impressive I think).

    The main difference here is improved tooling enabled by static type declarations. What does that remind me of? The "concepts" feature that was originally mooted for C++0x. Like a lot of people, when I first read through the C++0x feature list, I weeded out the stuff that compiler implementers would do last (or possibly never bother with). And concepts stuck out like a sore thumb. And sure enough it got dropped from the eventual standard.

    TypeScript is a very similar project, in that it overlays a system of declared structural typing over an existing system that already works okay without it, with the aim of improved tooling.

    Yes, TS adds classes and modules, but (as the examples show) it doesn't really need to do very much to implement those. They are easy patterns to follow. (Okay, classical inheritance gets tricky when you start inheriting implementation, but most modern OO books warn against doing that too much anyway.)

    The => syntax is nice, but I'd class that alongside CoffeeScript - not interesting in itself, because all it does is make the code "look" pretty in the most superficial possible sense (to me, it's already pretty in the sense that matters!) I wouldn't turn down => as part of a bundled deal, but it's not a deal-maker in itself.

    Having played with TS for a day, it's a beautiful demonstration of how static typing is a genuinely valuable productivity tool. And this implementation of it is unusually good (it already appears to be better than Java and C#, due to the underlying structural nature, as opposed to dumb nominal typing).

    But at the same time, over the last couple of years I've found it quite possible to build large, complex, modular applications in JavaScript. It's already workable. Static typing would be luxury, but I can get by without it.

    However, the number one, constant, irritating pain is the lack of support for continuations in the language. Fix that somehow in TS and I will jump at it like a starving leopard. (Async/await, or even just the yield keyword as implemented in Mozilla).

    Then the static typing and other bits of sugar will be a fantastic bonus.

  • 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.

See more comments…