Foreword

At the end of the previous millennium, a small team of designers met in a small conference room on the second floor of Building 41 at Microsoft to create C#, a then brand-new language. The designers wanted the language to be easy to understand but not simplistic, familiar to C++ and Java programmers but not a slavish copy of either, safe by default but not too restrictive, and practical but without abandoning a disciplined, consistent, and theoretically valid design.

After many months of thought, design, research, development, testing, and documentation, C# 1.0 was delivered to the public. It was a pretty straightforward object-oriented language. Many of the details of its design were carefully chosen to ensure that objects could be organized into independently versionable components, but the fundamental concepts of the language all came from ideas developed in object-oriented and procedural languages going back to the 1970s or earlier.

The design team continued to meet three times a week in that same second-floor conference room to build upon the solid base established by C# 1.0. By working with colleagues in Microsoft Research Cambridge and the CLR team across the street, the type system was extended to support parametric polymorphism on generic types and methods. They added “iterator blocks” to make it easier to build collection types. Generic types and iterators had been pioneered by earlier languages such as CLU and Ada in the 1970s and 1980s. They also added anonymous methods; the idea of embedding anonymous methods in an existing method goes all the way back to the foundations of modern computer science in the 1950s.

C# 2.0 was a huge step up from its predecessor, but still the design team was not content. They continued to meet in that same second-floor conference room three times a week. This time, they were thinking about fundamentals. They realized that programmers manipulate data by combining relatively simple operations in complex ways; those operations typically include sorting, filtering, grouping, joining, and projecting collections of data. The concept of a syntactic pattern for “query comprehensions” that concisely describe these operations was originally developed in functional languages such as Haskell but also works well in a more imperative language like C#. And thus LINQ—Language Integrated Query—was born.

After ten years of meeting for six hours a week in the same conference room, the need to teleconference with offsite team members motivated a change of venue to the fifth floor. The design team looked back on the last ten years to see what real-world problems were not solved well by the language, where there were “rough edges,” and so on. The increasing need to interoperate with both modern dynamic languages and legacy object models motivated the design of new language features like the “dynamic” type in C# 4.0. And they threw in typesafe covariance on certain generic interfaces for good measure.

Still the design team was not content; they were always looking at real-world developers to see what vexing problems they faced that could be solved with better language tools. They identified dealing with latency as a stumbling block for many modern application developers. In a world of multicore machines connected over networks, the milliseconds that elapse between requesting a result and processing it further ought not to be wasted, but it is very difficult to write clear, understandable programs that work well in high-latency environments. This motivated the addition of asynchronous methods in C# 5.0, which enable a program to do useful work while a method is waiting for a high-latency result to become available.

I figured it might be a good idea to do a quick look at the evolution of the C# language here, in the foreword, because this is certainly not the approach taken in this book. And that is a good thing! Authors of books for novices often choose to order the material in the order they learned it, which, as often as not, is the order in which the features were added to the language. What I particularly like about this book is that Scott chooses a sensible order to develop each concept, moving from the most basic arithmetical computations up to quite complex interrelated parts. Furthermore, his examples are actually realistic and motivating while still being clear enough and simple enough to be described in just a few paragraphs.

I’ve concentrated here on the evolution of the language, but of course the evolution of one language is far from the whole story. The language is just the tool you use to access the power of the runtime and the framework libraries; they are large and complex topics in and of themselves. Another thing I like about this book is that it does not concentrate narrowly on the language, but rather builds upon the language concepts taught early on to explain how to make use of the power afforded by the most frequently used base class library types.

As my brief sketch of the history of the language shows, there’s a lot to learn here, even looking at just the language itself. I’ve been a user of C# for more than ten years and am a member of the design team, and I’m still finding out new facts about the language and learning new programming techniques every day. Hopefully your first 24 hours of C# programming described in this book will lead to your own decade of practical programming and continual learning. As for the design team, we’re still trying to figure out what comes next; I’m looking forward to finding out.

Eric Lippert
Seattle, Washington
September 2012