Comments

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.

 

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.

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.

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!

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.

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

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();

 

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.

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

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!