Will C++0x affect Managed C++? Will it trigger a Managed C++0x?
Nov 20, 2007 at 6:30 PMAnother great F# / Don Syme et al interview.
Now you need the equipment to be able to do 2 hour interviews, Charles.
Some words from the realm of obviousness.
The world is in constant flux. People will flow towards the languages with the fewest compromises. The languages that have the most powerful abstractions, are the easiest to learn, the easiest to use, compile to the fastest code on current hardware and help the most with debugging (compile time, or runtime.)
C# isn't the final language, and can't be evolved into it a hundred years from now - unless you forget about backwards compatibility and you don't - that's the only reason not to invent a new and better language from scratch. CIL is not the final IM and the same evolvability constraints probably goes for it as well. Same with the CLR, etc.
I've always felt that the languages of the future will melt with IDE's. In a sense a DSL with a visual abstraction constitutes this melting and blurring of distinctions, just as functional languages blur the distinction between function and value. The real sign of this blurring of lines will be when languages are expressed in graph metaformats (the idea of XML, but more general), allowing flexible program visualizations and transformations.
Maybe just a dream.
Oct 25, 2007 at 12:09 PMHalf-way through there's already been some simplifications, albeit for the sake of the audience. A couple of points...
First; statically typed languages don't have to always have types expressed explicitly, that's where type-inference comes into play, both in C# 3 and F#. That's one benefit of dynamically typed languages taken away.
Second; polymorphism may be restricted to use explicit (intensional) subtyping in C#, but there's also the concept of structural subtyping. I've encountered this in the excellent little language haXe, which has this concept of static compatibility. There is no need for explicit relationships, it just checks for "accidental" compatibility of signatures. That's a great feature. In fact it goes perfect together with object literals.
In some cases, one may want to force intensional contracts, and then one can use explicit class and type inheritance. As a static feature, that does not support dynamic incidental compatibility, but it also doesn't break dynamically for a lack of such compatibility.
It's one of the best JAOO videos on channel 9 though (also liked Gilad Bracha's somewhat). Too bad there aren't any actual presentation videos here.
This interview is quite shallow, it doesn't really reveal anything, does it? It's general considerations and strong emphasis of the non-importance of SP1, all adding up to a flat feeling having watched the interview. Charles does give Mike Nash some reason to sweat with a frank question. That was the highlight, heh. On the other hand, maybe there isn't really anything to tell, except to expect more compatibility and performance, which is great in and of itself.
Oct 13, 2007 at 2:24 PM
I assume there is a reason why you have to explicitly say you want your code parallelized. It's still an imperative world with islands of declarativeness. But I assume that in the future the compiler or CLR will auto-parallelize some code, where it can determine the safety of it.
But the team has its priorities right. It first creates the foundation for parallelism. Then later it can start to think about (or someone else can) the cases that are safe to parallelize - and where it makes sense to do so.
Maybe, with all the threads running on the machine, it wouldn't make sense to parallize some tasks, even though it would be possible to do so.
Just a thought...
One thing is for sure. The C#/CLR team has a great understanding of how to maximize impact and value whilst keeping disruption minimal.
One thing I didn't pick up from the video - is the Parallel Task Lib built on top of the existing Thread Pool stuff?
Another great video.
Nice video, nice sandbox.
I do want to know how to playback an in-memory (synthesized) sound. How do I do that in Silverlight?
I don't see a lot of audio stuff there.
It almost looks like I'm going to have to create the audio in-memory, then post it to a server and then stream it back in the client from another address. I'm mistaken, right?
If not, then that's going to be one hell of a latency...
(I like big, quality, downloadable videos as well; downloading...)