Jon Skeet，谷歌软件工程师，微软资深C# MVP，拥有10余年C#项目开发经验。自2002年来，他一直是C#社区、新闻组、国际会议的活跃技术专家和Stack Overflow总排名第一的用户，回答了数以万计的C#和.NET相关问题，他还建立了Joda Time的.NET版本Noda Time。Jon著有《深入理解C#》，他常年维护博客Coding Blog。外国程序员们调侃他的段子"Jon Skeet Facts"也很有趣。
iTuring: No doubt you are a C# expert and you have written the book C# in Depth for several editions. Do you have plans in writing about other languages or tools you are proficient in?
Jon: Unfortunately, there are very few other languages or tools that I am proficient in. I work professionally in Java, but I get the impression that there are already plenty of books about that.
For years I've been telling myself to learn F#, Go and maybe Ruby... at some point I should really get round to it. I like the idea of recording screencasts of myself learning F#, ideally with a concrete goal in mind. I hope that others watching the process of how I learn may help them too.
iTuring: How much time have you spent on answering questions every week? What is the biggest rewarding for you?
Jon: It's very difficult to work out how much time I spend on Stack Overflow - and it's not something I really want to study too carefully, as I might not like the answer. There are lots of different kinds of rewards - I love it when I learn something new through answering a question, but it's also really nice when I receive a comment on an answer I wrote years ago, from someone who faced the same problem and solved it using my answer.
iTuring: Many readers of yours are curious about your job in Google. Are there some projects in Google written in C#? What are they?
Jon: I can't say very much about my work at Google, but I can say that I've written two C# projects within Google: my Protocol Buffers port to C# (in 20% time) and the first version of the Windows Phone 7 Google Search App.
There are also C# projects for accessing Google APIs, with the Google APIs Client Library for .NET being the root of this.
iTuring: Does being a Google software engineer and a Microsoft MVP conflict with each other sometimes? If it does, how do you manage to sharpen your skills in Google?
Jon: Well, I'm an MVP in name only, effectively - I'm not under an NDA, and I can't receive gifts such as an MSDN subscription from Microsoft. But I'm very pleased to still be an MVP, with Microsoft recognizing my contributions to the .NET community.
Sharpening my skills at Google is quite different to sharpening them elsewhere, as the challenges of coding at Google are often miles away from the challenges elsewhere. In terms of keeping up to date with C#, that's done on personal time - including my work on Noda Time, for example.
iTuring: Indeed C# is elegant, convenient, and normalized language, but in your opinion what is the biggest problem of this language? Are there any other existing languages have solved this problem properly?
Jon: Again, I don't know many other languages - which makes it somewhat hard to say what problems there are in C# which have been solved elsewhere. For example, until I got used to closures in the form of anonymous methods in C# 2, I didn't appreciate how useful they were, despite having been told about them before. This is an example of the Blub Paradox. I'm very happy with the way that C# has made it easier to work with data (via LINQ) and asynchronous code, however. I don't tend to use dynamic typing much in C#, but I like the way C# has integrated it into the language. I suspect that future languages may use a mixture of dynamic typing and static typing, but right from the start - which could avoid some of the places where the two come into conflict in C#.
One problem in C# which is being addressed in C# 6 is the amount of boilerplate code required to implement immutable types. I've long been a fan of immutability, but various improvements in C# over the years (such as object initializers) have only really helped with mutable types. It's nice to see primary constructors and read-only automatically implemented properties addressing this.
iTuring: What feature would you like to see in C# in the future? The concurrent execution ‘goroutines’ of Go? Or pattern matching like F# and Scala?
Jon: I think pattern matching might have a place, but I'm not sure about goroutines... it feels like C# has chosen its path for asynchrony, and it would be odd to mix and match that with goroutines.
In terms of other features - the best new features in C# have always been the ones that have surprised me. I suspect that some features I might like would require CLR changes as well, but that doesn't mean they're out of the question, of course. I'm keen on code that makes it clear what kind of data you're working with, ideally stopping you from performing inappropriate operations on it. Along those lines, I think I'd like some enhancement to the type system allowing a single implementation to be shared between multiple types, each of which only expose a limited subset of the underlying API. In some cases there might be multiple types with identical APIs, but which would still be entirely separate types - possibly with explicit conversions between them. Some of the ideas from F#'s Units of Measure could well be part of that thinking too, of course.
iTuring: It seems that C# or .Net can only be run on Windows or Mono under Linux, the prospects of C#’s development are not very reassuring for C# developers. Do you think .Net should develop cross platforms compatibilities?
Jon: I've been tremendously excited by the work that Xamarin has done in allowing C# code to run on both iOS and Android - and indeed I have an iPad and a Mac Mini purely for the sake of exploring that space. By the time you can run C# code on all the major mobile platforms, as well as Mac, Linux and Windows, it feels like it's not terribly restricted. Mono still has a few rough edges - as I've discovered when looking at corner cases of internationalization for Noda Time - but it's still amazing how well it does work. The fact that Roslyn is now open source and can be used by Mono is also very encouraging.
iTuring: WP’s license fee under 9” has decreased to 0. Do you think this will increase the number of C# developers? What is you expectation for WP?
Jon: Given the conflict of interest between Windows Phone and Android, I think it's better if I don't answer this one, I'm afraid.
iTuring: As an expert in C#, do you have some advices for C# fresh men? If one has a programming background, what he should pay attention to in his learning process?
Jon: I would focus on the core aspects of the language first. Too many beginner books (in my view) start off with some GUI talking to a database in chapter 1 - before the reader has any idea what the code they're typing in is doing. That's simply biting off too much in one go. I've always found that it's better to make sure you understand the language before you learn a lot of libraries... that way even if you don't know exactly what a particular call does, you can at least understand the mechanics of the code you're looking at, and then consult the relevant documentation for the rest.
The most commonly-misunderstood aspects of C# (and Java) appear to be the differences between variables, objects and references - if you can make absolutely sure that you understand that difference, you've got a good start.
iTuring: There are rarely programmers over 40 in China. Most of the developers would turn managers when they are older. Do you have any suggestions for Chinese developers? What do you get most from your coding life?
Jon: The transformation from software engineer into manager is a common one in the west too, and I suspect that sometimes it's a good thing, but often it's not. I wouldn't be surprised to find that a lot of managers are secretly pining to do the coding work that the engineers that they're managing are actually up to. That said, a really good manager will be able to use their experience to help to make junior engineers more productive than they could be otherwise, sharing their experience and coaching as well as managing.
Personally, I'm happy to do a bit of both - I wouldn't want to isolate myself from coding, but a certain amount of management responsibility can be a good thing too.