C# 4.0: Meet the Design Team | Charles

Charles
Welcome Change

#Jul 12th, 2008 @ 3:17 PM

"what I thought you were trying to ask was.. is there any thoughts to changing .NET CIL, as in add to the capability that CIL can describe (such as something like contracts being defined as a pure CIL construct (library aside)."

Well, what I asked I in fact thought about before interpreting and conceptualizing ideas, constructing the word patterns to describe the idea and finally delivering it by mouth. Smiley

The question is based on the notion that

If your runtime and default libraries are capable of providing functionality that can address specific hardware configurations (especially the runtime engine, but so too the collection of classes that you program with...), then the languages used to manage the manageable parts of the runtime can be very thin. TPL and CCR demonstarte that libraries (with support in the base virtual machine when necessary(e.g., Generics, etc) can provide sufficient capability to program (express) parallelism. So, my question was aimed at exploring the necessity of adding the same or similar functionality to the syntax of the language.

C

wil2300
Super #

Charles, that is a good point about libraries vs. language constructs. I assume that we are still a little ways from C#4.0 and in the mean time, the TPL library is being consumed and improved. Given that Joe Duffy and Anders seem to talk all the time, then it seems that the TPL library will provide a good test bed for parallelism, which, if successful, can be implemented in the next c# version. I mean the framework exists and not just for c# but LINQ as well. Anyway, just my 2.5 cents.

sylvan

Charles, when you're interviewing them next time, it would be great if you could delve into the "intersection" between meta programming (which they said they were working on) and dynamic compilation of code (which they also talked about).
It sounds like there's an exciting opportunity here to combine those two and get run-time specialization of code.

E.g. if you have a regexp matcher that takes a regular expression and a string and returns true if it matches, you could specialize the first parameter of that function for a specific regular expression (which isn't known at compile time, only at runtime) and then run that specialized version on ten million strings. The benefit is that the regular expression would get hard coded into the specialized version so that the matching doesn't have to "interpret" it each time. There's a cost involved in doing thie specialization, but quite often you'll use it so often that the benefit outweighs that cost.

Seems to me like compilation can be viewed as basically the act of "baking in" known facts about your code (e.g. the size of a variable) into machine code so you can execute it faster. Well I'd say that many applications will have "known facts" that may not be true for the entire duration of the program, but will at least be true for "long enough" that it's worth baking them in anyway. Another example is an image filter, where you take the filter kernel and compile it down into machine code and then run it over the image (because the kernel won't change for the duration of the filter operation). A third example is a game where you load a game level, that level won't change for several minutes at least so it would be cool if you could "bake it in" and do all sorts of optimizations under the assumption that the game level is "constant" for some duration of time (e.g. inline calls that are virtual, but since the data is constant you know exactly where you need to go, unroll loops, recursion, do standard constant folding etc.).

Anyway, this is my pet idea for a "killer app" where you'll see all C++ advocates gladly switch to C# for the increased performance, and if you have both meta programming *and* runtime code generation/loading you're basically almost there.

staceyw
Before C# there was darkness...

In reply to wil2300

#Jul 12th, 2008 @ 5:07 PM

I think the tpl works pretty well as an library already (from an perspective). As Anders said; would it make more sense to bake in a "ParallelForeach" keyword in the language - what are you adding? Not sure. Linq needed this kind of sugar in the language to make is cleaner/easier to call the apis. Not sure tpl, as it exists today, would benefit the same way. Some new pattern (that will become obvious when we see it) will probably benefit from lang sugar. I think the big win will be when the pattern becomes "parallel correct" by *construction - which would be a combination of lang features, patterns, compiler, and libraries. I think a pattern of being correct-by- construction (e.g. Erlang) has the most legs.

evarlast

Are you taking requests?

Here is my list: http://jrwren.wrenfam.com/blog/2008/05/15/c-vnext-feature-request/

Left out of that list is my request for an extensible literal system. We already have the wonderful TypeConverter system in the BCL. The compiler could use that and I could have extensible literals in the language. Short of that, just list and dictionary literals would be great.

Judah

Guys, for over a year now, I've been telling folks at Microsoft that what we want is language constructs that help you write less buggy code.

It should be obvious, but this is the thing plaguing software teams; we write buggy code and we spend a lot of time writing unit tests, physically testing, debugging, and doing formal code reviews -- all in an attempt to get rid of bugs.

C# 4 should add some constructs that help us write software with fewer bugs in it.

For me, this means integrating some of the excellent research done over the last several years by the Spec# guys. The design-by-contract stuff would help us rid our codebase of mistakes developers often make when working on large, complex, real-world software systems.

JChung2006

Great video, Charles!

With regards to the dynamic typing-static typing dichotomy, it is not either-or. It is not only-but also. We want not only the affordances of dynamic typing but also the assurances of static typing. Type inference sorta fakes us out into believing that it provides this, but it's still static typing, and there are limitations to that approach that cannot be worked around until changes to the type system are made.

Java and C# have been around for a while, long enough to where people will grumble if you make too many changes to the language. If it is impossible to make changes to the language without incurring "-1000" penalties, then maybe it's time for a new language (or perhaps an old one whose time hadn't quite yet come...) to step up and pave the way for programming language innovation. Better ways of getting the job done is the goal.