Chapter 16. Whither now?
- The evolution of C#
- .NET meets computer science
- How you can make a difference
- The wider world of computing
So that’s C#—as far as version 4, anyway. Rather than leave you with an abrupt context switch from Code Contracts to the appendixes, I wanted to wind down with a few thoughts about how far we’ve come and where we might be going.
Of course, any forward-looking statements expressed in this chapter should be taken with a large bucket of salt. Please don’t try to return this book for a refund if I’m completely wrong. Retrospective statements are likely—but not guaranteed—to be more accurate.
These musings cover more than just C#, but that’ll be our starting point. From there we’ll work outward, through the .NET ecosystem to the whole computing industry.
16.1. C#—mixing tradition and modernity
C# has come a really long way—and in a short space of time, for a mainstream language. The more users a language has, and the less tolerant they are of pain, the harder it is to introduce change. Banks and other large enterprises aren’t likely to be overjoyed if they hear that your latest and greatest release is incompatible with earlier versions. As such, the C# team is extremely cautious about breaking changes: they do exist, but they’re rare and usually provoke a compile-time warning.
Within that restrictive environment, C# has taken its Java-like roots and raced away, developing features that massively increase productivity and maintainability. I know, I sound like a complete fanboy... but if you’ve been reading this book from the start and I haven’t yet convinced you about the truth of this statement, then frankly I’ve failed.
Despite being in its fourth major version, C# feels like a lean language to me. Admittedly this is entirely in terms of the code you end up writing: C# has inevitably gained weight in terms of language complexity, and the designers will need to be wary of just how many more features they can add before they end up with a language that’s too big for anyone to know well. But the efficiency of expression is appealing—as I mentioned in chapter 1, C# has learned some lessons from dynamic languages while remaining almost entirely statically typed.
So what’s coming next? At the time of this writing, little is known about C# 5. The concept of a “compiler as a service” has been discussed, but it’s not clear exactly what that means or when it’ll come. Will it allow custom code to be injected into the compiler pipeline? Will it allow small sections of code to be compiled and executed without requiring whole class definitions? Will it actually change the language itself at all? We’ll have to wait to find out.
There’s more that C# could take from functional languages, mind you. The Mono team have already implemented more support for .NET 4’s Tuple types within the C# language, and options for pattern matching and better support for immutable types would be welcome, too. Though languages such as F# have advanced type inference (going well beyond what C# provides with implicitly typed local variables), I’d personally be surprised to see this make it into C#. But then again, I was surprised by the support for dynamic typing in C# 4.
What’s becoming increasingly clear is that we’re living in a heterogeneous world. Web developers already have to know HTML, CSS, and JavaScript as well as whatever backend technologies they’re using—and the same theme is taking hold on the server and desktop too. Let’s think about what else is happening in .NET, and the effect on C# developers.
16.2. Computer science and .NET
It feels to me like the nature of development is changing. It’s hard to measure—at least as an individual—but it seems that computer science is having something of a revival. After years of some developers complaining that nobody ever seems to know about fundamental data structures, the community is talking about monads, proving code correctness, patterns of asynchronous computation, and any number of other topics that were previously the realm of the academic computer scientist.
Of course this is a slight exaggeration—there have always been pockets of industry doing interesting work like this—but Microsoft is bringing more of these theories and technologies into the mainstream. Whether by design or coincidence, .NET has become a wonderful experimental playground for advanced technology with its roots in old computer science.
In this book I’ve given you a taste of technologies such as Code Contracts, Parallel Extensions, and Reactive Extensions. There are many other projects though, at various stages of completion:
- Pex tries to “explore” your code, generating automated tests to take every possible path by passing in different data, generated through intelligent code analysis (see http://mng.bz/0iAW).
- CHESS finds bugs in concurrent code that could be hard to spot by inspection, hard to test for with normal unit tests, and hard to spot in production (see http://mng.bz/FM55).
- F# is a functional language that aims to bridge the functional/object-oriented divide, and which is now fully supported in Visual Studio.
- Axum is a new language for parallel programs, based on actors and message passing (see http://mng.bz/Zyus).
This isn’t an exhaustive list, and each of these projects is ambitious with a lot of potential. But it’s not at all obvious which ones will make a lasting impression on the developer community. In five years, will contracts be as common as unit tests? Will we think back on synchronous RPCs and shudder in horror? Will we switch effortlessly between Python, C#, and F# (or something even newer) without needing a coffee break to change mental gears?
I’m convinced of one truth: the future of these projects will depend on the alpha geeks of the .NET world as much as anyone else. The fact that you’re reading a fairly advanced C# book suggests you probably belong in that set, so I’d urge you to consider picking up one of these technologies and running with it. Blog about it. Show it to your colleagues. Speak about it at a user group.[1] Be passionate about it, and change the world.
1 Public speaking isn’t as terrifying as it sounds. Or rather, it’s terrifying and exhilarating in equal measure. I advise the use of a sock puppet as a prop: if the whole thing falls apart, you can blame the puppet.
16.3. The world of computing
In fact, the world is going to change whether you do something or not. I finished drafting the first edition of this book in late 2007... around the same time that Android was announced, and I saw an iPhone and a netbook for the first time. Google AppEngine and Windows Azure hadn’t been announced; Amazon EC2 was still in beta.
We live in a different world today. Perhaps this hasn’t impacted your daily work yet, in an obvious way, but it will. Even if you don’t write mobile applications or use cloud computing, the APIs, standards, and engineering techniques will affect how you write code... and maybe when you do need your code to scale to hundreds or thousands of servers, it won’t be quite as hard as it would’ve been without these changes.
The shift to parallel processing continues unabated, with even netbooks gaining multicore processors. Projects such as Parallel Extensions and Reactive Extensions will certainly help, but they’re no free lunch. Moving beyond the imperative model will be painful, but fascinating at the same time.
Meanwhile, the performance trade-offs we’ve always had to make are changing too. Solid state drives are becoming increasingly affordable and networks are becoming more diverse, ranging from ulta-fast connections in data centers to “occasionally connected” mobile broadband connections—which themselves vary immensely in terms of bandwidth. Software engineering has to account for the environment in which the code will run, which can affect all aspects of the design and implementation. As developers we need to be receptive to different ideas and approaches—and with the staggering pace of technological change, we have to be able to learn at speed too.
16.4. Farewell
It’s my fond hope that this book has shaken you up a bit. If most of the material has been new to you, then I hope it’s made sense—and that the bits which didn’t quite sink in on a first read are more comprehensible next time you look at them. If you’re already an experienced C# developer and this was a refresher, I hope you’ve still found something new—whether that’s an aspect of the language you weren’t aware of, or perhaps a different approach to thinking about a problem.
Beyond that, I hope I’ve helped to nurture a sense of excitement—not through screaming exclamation points and shiny examples, but through a sense that C# can help you to express your ideas more clearly and concisely than ever before. This doesn’t have to be a passion about the language itself—it’s really just a tool, after all—but about what it’ll let you achieve. Don’t think of the vehicle in isolation; imagine where you want to go, and be glad that C# will make the journey that bit easier. With any luck, this book will have helped you to steer in the right direction and get the most out of the language. It’s time we parted, so farewell and bon voyage, wherever C# takes you.