Eric lippert - Amazon Web Services

ecently: basically, it was to become a
domain expert by answering as many
user questions as I possibly could. But
the best programming advice is a bit
harder to put my finger on. I learned so
much at Microsoft from world-class
experts in programming language
design, performance analysis and many
other fields, that it is hard to name just
one.
Here’s one thing that has stuck with
me from even before my Microsoft days
though. One day many years ago Brian
Kernighan gave a talk about
programming at UW. At one point he put
up a slide showing some code that was
clearly wrong. You knew it was wrong
because what the comment above the
code said and what the code actually did
were opposites. Kernighan said
something to the effect of “pop
quiz: what actually runs, the code
or the comments” I still ask myself
that same rhetorical question
when I’m trying to understand a
piece of buggy code; it is
frequently the case that the
comments are misleading,
out-of-date or just plain wrong,
and it is frequently the case that
the comments are right and you
don’t even bother to read the
buggy code that follows them.
Kernighan’s talk changed my
attitude towards commenting
completely. Since then I’ve tried
to write comments that explain
what the goal of a particular piece
of code is, rather than trying to
explain how it works.
DNC: When your team started the development of C#, what were
some key goals in your mind Are you happy the way C# has
matured
EL: To be clear: I started working on C# just as the final corner
cases in the design of C# 3.0 were being hammered out and
development was beginning in earnest. I have followed C#
carefully since its creation over a decade ago, but I wasn’t actually
a part of the C# 1.0 or 2.0 team.
When thinking about goals, I try to distinguish the “business” goals
from the “technical” goals; these goals are strongly aligned, but
they are different perspectives. From a business perspective, the
primary goal of the C# product was – and continues to be – to
create rich, compelling language tools that enable developers to
take advantage of the .NET platform specifically, and more
generally to improve the state of the art for the whole Windows
ecosystem. Better tools means more productive developers, more
productive developers means better applications for their users,
and better applications means the platform becomes more
attractive, and everyone wins.
From a language design perspective, there are a number of core
principles that the design team goes back to over and over again.
The language is intended to be a modern, relevant and pragmatic
general-purpose programming language, used by professional
programmers working in teams on line-of-business application
software. It’s intended to be object-oriented, but not
dogmatically so; the language design team happily takes ideas
from other programming paradigms and incorporates them where
they make sense.
C# 1.0 started off as a pretty typical modern language. Obviously
it was heavily influenced by C and C++; the design team sought to
mitigate some of the shortcomings of C/C++ while still permitting
access to the raw power of unsafe code. But in the decade since
it has grown in leaps and bounds, adding a generic type system,
sequence generators, functional closures, query comprehensions,
dynamic language interoperability and lately, greatly improved
support for writing asynchronous workflows. I am thrilled with
how the language has evolved over the past twelve years, and it’s
been a privilege to have been a part of it for some of the most
exciting changes. I’m looking forward to continuing to work in the
C# ecosystem.
DNcmagazine www.dotnetcurry.com | 37