NV: Do you think that C# and the managed world as a whole, could be "threatened" by C++ 11 ?

EL: Is C# "threatened" by C++11?

Short answer: no

There's a saying amongst programming language designers - I don't know who said it first - that every language is a response to the perceived shortcomings of another language.

C# was absolutely a response to the shortcomings of C and C++. (C# is often assumed to be a response to Java, and in a strategic sense, it was a response to Sun. But in a language design sense it is more accurate to say that both C# and Java were responses to the shortcomings of C++.)

Designing a new language to improve upon an old one not only makes the world better for the users of the new language, it gives great ideas to the proponents of the old one. Would C++11 have had lambdas without C# showing that lambdas could work in a C-like language? Maybe. Maybe not. It's hard to reason about counterfactuals.
But I think it is reasonable to guess that it was at least a factor.

Similarly, if there are great ideas in C++11 then those will inform the next generation of programming language designers. I think that C++ has a long future ahead of it still, and I am excited that the language is still evolving in interesting ways.

Having choice of language tools makes the whole developer ecosystem better. So I don't see that as a threat at all. I see that as developers like me having more choice and more power tools at their disposal.

NV: In this age ruled by the Virtual Machine and managed code should a high level programmer be exposed to low level-system programming ?  

EL: Joel Spolsky said over a decade ago:

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

“All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a little, sometimes a lot.”

This is undoubtedly true. The abstractions that we program against are valuable because they free us from having to think about the implementation details of the abstraction, right up to the point where the abstraction fails us, and then we do have to think about it.

For example, in C# the garbage collector frees you from having to think about the implementation details of memory management, 99% of the time. In a few rare cases though, the abstraction fails and you need to tell the garbage collector “don’t collect this right now” or “don’t move this memory” or whatever. In those cases, the abstraction is leaky and you have to think about what the garbage collector is really doing: moving blocks of memory around to coalesce the heap, and not what the abstraction is giving you: the illusion that you have unlimited memory and therefore do not need to free it.

My advice to people who program against any abstraction is to try to have at least a working understanding of one level of abstraction down, but not necessarily two.

If you’re writing C# code, it’s useful to have a basic understanding of how the CLR does its job of managing your memory, JIT-compiling your code, and so on.  

If you’re writing C code, it’s useful to have a basic understanding of how memory is being laid out, how the stack grows in your operating system, and so on. That way when you run into an abstraction leakage, you’re prepared.

 So yes, I think there is some value to being exposed to lower-level programming even when working in higher-level languages.

NV: What is you reply to the voices saying that C# has grown out of proportion and that we've reached the point that nobody except its designers can have a complete understanding of the language ?     

EL: I often humorously point out that the C# specification begins with “C# is a simple language” and then goes on for 800 dense pages. It is very rare for users to write even large programs that use all the features of C# now. The language has undoubtedly grown far more complex in the last decade, and the language designers take this criticism very seriously. The designers work very hard to ensure that new features are “in the spirit” of the language, that design principles are applied consistently, that features are as orthogonal as possible, and that the language grows slowly enough that users can keep up, but quickly enough to meet the needs of modern programmers. This is a tough balance to strike, and I think the designers have done an exceptionally good job of it.

NV: Can attempts aimed at helping the developer's life, like adding a new feature to the language, sometimes end up having the opposite effect of complicating it?

EL: Absolutely. It is always the case that design is a process of choosing amongst many mutually incompatible goals. Power and simplicity are often opposites. LINQ, for example, on the one hand adds a lot of power to the language. It makes writing queries that look like the business rules very easy. But it also complicates the language; there are new rules to understand and new techniques to learn. The languages designers think very hard about this tradeoff.
 
NV: For example, do the myriad ways of constructing and calling a delegate confuse or help ?

There is a pretty broad consensus that if we had a chance to do it all over again, almost everything to do with delegates would be a lot simpler. In particular, no one likes the fact that there are two syntaxes for anonymous functions. Neither syntax is bad per se; both were designed with usability in mind. But the designers of C# 2.0 did not know that LINQ was coming in C# 3.0; if they had, anonymous methods would have been lambda expressions in the first place.

Is NOT breaking backwards compatibility a panacea ?

The Hippocratic Oath begins “first, do no harm”. Keeping the number of backwards-compatibility breaking changes as small as possible is a harm-reduction goal, but that’s the beginning, not the end. There are a lot more problems to solve.

NV: Where is programming as an industry heading at and will an increasingly smarter compiler that will make programming accessible to anyone, something very positive of course , on the other hand pose a threat to the professional's programmer's job stability?

EL: I can't find the figure right now, but there is a serious shortage of good programmers in the United States right now. A huge number of jobs that require some programming ability are going unfilled. That is a direct brake upon the economy. We need to either make more skilled programmers, or making writing robust, correct, fully-featured, usable programs considerably easier. Or, preferably, both.

So no, I do not see improvements in language tools that make it easier for more and more people to become programmers as any kind of bad thing for the industry. Computers are only becoming more ubiquitous. What we think of as big data today is going to look tiny in the future, and we don't have the tools to effectively manage what we've got already.

There is going to be the need for programmers at every level of skill working on all kinds of problems, some of which haven't even been invented yet. This is why I love working on developer tools; I've worked on developer tools my whole professional life. I want to make this hard task easier. That's the best way I can think of to improve the industry.

Related Articles

C# 6.0 Features

.NET Goes Open Source 

C# Gets A New Operator - Safe Navigation

RyuJIT - The Next Gen JIT .NET Compiler

Microsoft tells C# developers to learn JavaScript!?       

Microsoft Team Explains Language Stagnation       

Other Interviews

Catalyst And More - An Interview With Matt Trout

Where is Perl Heading? Interview with Jonathan Worthington

Perl 6 and Parrot - In Conversation with Moritz Lenz

Perlito - An Interview With Flávio Glock

Niecza - Perl 6 Implemented in .NET   

More from Eric Lippert

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin,  or sign up for our weekly newsletter.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info