A Face Made For Email, Part Four
Good heavens, this just keeps on happening to me.
If you're interested in what we're musing about for future versions of C#, check out this video of Anders Hejlsberg, Scott Wiltamuth, Paul Vick, Mads Torgersen, Matt Warren, Jim Hugunin and, off in one corner, me.
Working with this caliber of people every day is a huge part of what makes this the best job ever.
https://channel9.msdn.com/posts/Charles/C-40-Meet-the-Design-Team/
Comments
Anonymous
July 14, 2008
Yes, the rest of the dev community is I suspect hugely envious of working in such a team. Must be extremely exciting :-)Anonymous
July 15, 2008
I've moved almost completely over to C# from VB.NET, but there is one piece of syntactic sugar that I miss from VB...With. Especially when you are dealing with structures or objects that are nested extremely deeply (see XNA or even some ASP.NET code-behind scenarios), With was a godsend. I'd love to be able to do something like... with (a = Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For) { a.Property = x; a.Property2 = y; a.Property3 = z; a.Property4 = w; } Admittedly, the compiler would just expand a out, but even so, that little shortcut it what I miss more than anything.Anonymous
July 15, 2008
You already have it: var a = Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For; a.Property = x; a.Property2 = y; a.Property3 = z; a.Property4 = w; It even takes fewer characters than your suggestionAnonymous
July 15, 2008
I think the ex-VB crowd may be missing something like this: with varname = Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For; { .Property = x; .Property2 = y; .Property3 = z; .Property4 = w; } This way a programmer could only change the variable name in one spot.Anonymous
July 15, 2008
I'm more worried about something in the Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For returning null. With the move to more immutability method chaining becomes much more attractive except for that pesky null ref exception. You can make null objects but that has downsides in a language that is still largely imperative. You can make a chain-safe extension method for every method, but that seems like a bad idea. I'd like to see something like a new chain-safe opperator .. which would return the default of the method return type if calling on null. Some..Deep..Object..Or..Structure..That..Would..Take..Forever..To..Type..Or..Use..Intellisense..For ... or something like that.Anonymous
July 15, 2008
The comment has been removedAnonymous
July 15, 2008
The comment has been removedAnonymous
July 16, 2008
Mmmm. Watched the video. Not much in the way of upcoming features. Just how Eric likes to code by himself :P.Anonymous
July 16, 2008
Is there any analysis done that talks about the general distribution of programs that are CPU-bound vs IO-bound? It seems there is a lot of talk about parallelizing programs and how important that is. It would seem that this would be particularly beneficial for programs that are CPU-bound, but possibly disadvantageous to programs that are IO-bound. Though I realize a function that does IO would not be pure and unlikely to be parallelized. In general, I'm wondering about the target market for parallelization. It would seem that it would be the intersection of the set of people who do scientific computing and the set of people who have trouble doing their own threading.Anonymous
July 22, 2008
Hi Eric I have a question unrelated to this topic (but I can't see your email address anywhere, so here it goes) : It appears that a x64 version of msscript.ocx does not exist. Why so? TIA RudifAnonymous
July 22, 2008
"We can finally do in csharp what we have done in jscript for 8 years..." Nice ;) DanielAnonymous
July 30, 2008
The comment has been removed