![](https://csdnimg.cn/release/download_crawler_static/10737550/bg13.jpg)
PREFACE
xviii
to use dBase, FoxPro, Borland Delphi, Borland C++, PowerBuilder, Visual Basic 3,
QBasic, QuickBasic, and much more. Oh, and I had to be able to set up the Novel Net-
ware 4 network at the office and convert everyone from dumb terminals to DOS and
Windows 3.x PCs. The languages were different, the UI layers were different. There
was little to no compatibility between any of these packages.
Change was the norm. It was expected.
Fast-forward to today. As developers, we’ve never had more pressure on us to be
productive, but at the same time, we’ve never had the longevity of tools, platforms,
and languages that we have today. If you started with .NET 1.0 or the alphas/betas (as I
did), you’ve been able to use the same programming language and core runtime for
almost 13 years. If you’ve been a Java programmer, you can claim an even longer run.
The only people who had those kinds of runs in the past were FORTRAN and COBOL
programmers.
Lately, things have begun to change a bit more. To keep up with the demands of
users and the heavy competition in the mobile space, we’re seeing programming lan-
guages and underlying platforms rev more frequently. A natural consequence of this is
deprecation or sunsetting of platforms that don’t fit the new interaction models and
the emergence of newer API sets, compilers, and more. The JavaScript space has argu-
ably had the most rapid innovation, with new tools and libraries emerging seemingly
daily. Many of those have, over the years, completely altered the language in ways that
would make modern JavaScript completely foreign to programmers who learned it 10
or even 5 years ago.
On the Windows side, we’ve seen some amazing work in the .NET and XAML space.
Interestingly, despite the changes of underlying platforms and the names of the prod-
ucts, .NET and XAML have remained far more compatible than many other platforms
over the years. If you started learning XAML with WPF (or a year later with Silverlight),
modern Windows Store XAML will easily become familiar, much like learning BASIC
on the Commodore 64 and then learning to program the Apple II. Sure, the PEEK
and POKE locations may be different, and there are a few other syntax differences, but
there’s far more that’s compatible than incompatible.
As someone who has made a career of .NET since the first time I gave the two-day
.NET 1.0 seminars in the .NET 1.0 alpha days, it’s heartening to see that my C# skills are
still just as valid today as they were 13 years ago. I’m also happy to see that my invest-
ment in XAML starting back in 2006 has served me well across every client platform
Microsoft has created. By combining XAML and C#, I can code for the Windows
Phone, Windows Store, and the desktop. If I stick to just C#, I can code for everything
from tiny ARM microcontrollers on Netduino and Gadgeteer all the way up to massive
servers. Through all of this, I’m staying within a tightly focused sphere of develop-
ment that centers on Visual Studio and C# (or VB, if you prefer).
That’s a solid return on investment.
As developers, we tend to focus on the differences in the Microsoft platforms. It’s
just natural, because it’s those differences that give us headaches and make us take up