Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
Just a couple of quick links today.
First: One of the questions I get most frequently is "can you recommend some good books about learning to program better in C#?" The question is usually asked by a developer; the other day I was surprised to get that question from one of the editors of InformIT. She was kind enough to post the list on the InformIT web site, so check it out.
Second: Bill Wagner posts his own follow-up article on my recent MSDN magazine article about async/await. Check it out.
Really? No C# in a Nutshell? That seems like an unfortunate omission.
I've never read "C# in a Nutshell", so I can't in good conscience recommend it one way or the other. I have heard others praise it. Incidentally, I was the technical editor of "VBScript in a Nutshell, 2nd edition" and I can heartily recommend it. :-) Eric
Great list ! I rarely read programming books, but you made me want to read Effective C#...
A good list indeed. The only other book I always recommend is "CLR via C#". Very good for understanding what's happening underneath the covers as it were. Though both Jon Skeet's book and the effective books are excellent as well.
Excuse me for off topic, but I have some questions about Roslyn Project:
1) Code for creating and modifying syntax tree is chatty, and this fact is clear for many people. The only way to improve this is to add to language some functional constructions, something like F# Active Patterns, and syntax for immutable object "modification" (now we have problem that calling method with optional value cannot be distinguished from explicitly setting null value) . What do you think about being more functional? isn't it more appropriate for compiler building?
You make some good points. We have been concerned on the C# design team for some time now that programming in an immutable style is somewhat "chatty" as you say. It would be nice if it were more elegant. We've got a few ideas but nothing that is in good enough shape to talk about it yet. -- Eric
2) The slogan "open compiler" cannot be the goal. This is the viewpoint of the manufacturer, not the customer. Better goals are maybe "leverage metaprogramming" as Nemerle or Scala (project Kepler) do. Or "support DSL writing". Don't you think that open C# compiler is insufficient for real goals?
Excuse me for my english.
You are absolutely right; there is quite a bit of confusion about what Roslyn is, and what the goals of the project are from the standpoint of consumers. The goal of the project is neither to allow metaprogramming nor to support DSL writing. I certainly expect that there will be people who use Roslyn to do those things, but those are not explicit goals. Rather, the goal is to make available a set of basic low-level code analysis tools for C# and VB, so that our customers can use those low-level code analysis tools to build even better code analysis tools. The market of "people who build code analysis tools" is small, but one of the reasons it is small is because the barrier to entry is so high! We hope to greatly lower that barrier. -- Eric
Thanks for the reading suggestions. If you were to recommend a single book out of that list, which would it be?
C# in a Nutshell is a great book for those who already know C# or at least some other language. I would suggest learning C# from online videos or MSDN!
I've read about half of those ... Jeffrey Richters CLR Via C# is my favourite book on C#.
I'm also surprised by the lack of CLR via C#. Is this due to the material being covered by the books you did recommend? Admittedly, I never read Wagners, but afaik those are a whole different ballgame.
Agree with previous commenters, I was shocked by not seeing Jeffrey's CLR via C# in the top of the list.
I'm really surprised to learn that you've "never written so much as a line of Java code". Given the obvious parallels between C# and Java have you never been tempted to have a play with the competition, or is this a decision taken to ensure a "clean room" environment?
When Java was first released in 1995 it really hit a "sweet spot"; the Java designers did a really good job of making a language that was clear to C/C++ programmers while avoiding many of the pitfalls of C and C++. Its type safety, automatic memory management, and so on, were very attractive. At that time, I was indeed intrigued by Java and considered learning it. However, there were no courses at Waterloo that I was interested in that did programming work in Java; I was finishing up my degree and interning at Microsoft on the Visual Basic team, so there was no professional need to learn Java, and so I never did.
Nowadays, I have no impetus whatsoever to take Java for a spin. I work every day in a language with aunified type system, unsigned integers, high-precision decimals, nullable types, tuples, pointers, partial classes, anonymous types, properties, events, user-defined operators, user-defined conversions, indexers, object and collection initializers, explicit interface implementations, optional arguments, named arguments, iterator blocks, extension methods, conditional methods, partial methods, generics that actually work, lexical closures, homoiconic expressions, query comprehensions, local variable type inference, generic methods, generic method type inference, checked arithmetic, verbatim strings, conditional compilation with regions, native/COM interoperability, dynamic runtime analysis and typesafe generic covariance, just to name three dozen major features that Java lacks. No, I am not tempted to use Java any more than I am tempted to see how well I can type with one arm tied behind my back. I don't need to try it to have a pretty decent guess about how unpleasant it would be.
That said, of course it is valuable to understand the characteristics of other languages when designing one yourself. Fortunately I do work with several people who used to be Java language designers and implementors, so I get all the insight I need into the pros and cons of Java by just asking them for opinions.