Abstract: We are thrilled to have Eric Lippert to talk to us once again in our 4th Anniversary edition of the DNC Magazine.

Dear Readers, we are thrilled to have Eric Lippert to talk to us once again in our 4th Anniversary edition of the DNC Magazine.

Download this interview in a PDF format and read it along wiith the rest of the articles.

Eric needs no introduction to the C# folks out there, but for others, here's Eric's Bio in his own words -

Eric Lippert is a developer who works on language tool infrastructure at Facebook. Previously he worked on the Visual Basic, JavaScript, VBScript, and C# compilers at Microsoft, and on static analysis tools at Coverity. He’s a frequent contributor to StackOverflow, and writes a blog about having fabulous adventures in coding at ericlippert.com.

1. We heard you recently joined Facebook. Tell us more about your work at Facebook.

I’ve been at Facebook since the beginning of 2016, and I’m having a marvelous time. Facebook is putting a lot of time and effort into open source developer tools, and there are a lot of interesting problems to solve in this space, particularly at the sort of scale that Facebook needs to work at. Specifically, I’m working on improving the Hack language and its compiler; Hack is a gradually-typed version of PHP with an interesting type system.

2. If you were starting out now in your career, what languages would you learn and why?

The specific details of various languages are just that: details. The important thing at the beginning of a career is to get the conceptual tools in your toolbox that you can use to solve problems. I’d suggest to beginner programmers that they learn at least one OO language – C++, C#, Java, Visual Basic – and at least one functional language – F#, OCaml, Haskell, Scheme, and so on. Once you have the concepts solid, it’s not hard to move from language to language.

3. As a developer, what's your greatest success story?

Looking back, the thing I’m proudest of is the “Roslyn” C# compiler architecture. Building a new, industrial-grade compiler starting from a blank page, that’s a rare treat in this business. I was very lucky to be a part of that project from the very beginning; I am thrilled that it finally shipped and is successful.

4. How much does the fact that Roslyn is a "compiler as a service" with public API affect its internal structure? How similar is it still to a standard "black box" compiler, as taught in a compiler course at the university?

Two things come to mind. First, the Roslyn API was designed to have a very “functional” flavor while still of course being written in an OO language. Syntax trees, for example, are immutable; you don’t ever change a syntax tree, you produce a new syntax tree that is the result of editing an old one. Baking that design choice deep into the compiler architecture had far-reaching implications.

Second, the performance requirements of Roslyn are very different from those of a traditional compiler. Roslyn needs to deal with both the “batch” scenario, where the compiler is handed a huge pile of source code and needs to generate assemblies as quickly as possible, and also the “IDE” scenario where many small edits are being made per minute, and the analysis needed for IntelliSense has to be up-to-date and accurate. A huge amount of work went into optimizing the compiler for these two scenarios; you would typically not see that in a traditional compiler.

5. During Roslyn development, did you encounter any discrepancies between the specification and the existing compiler? If so, how did you handle them: does Roslyn's behavior follow the specification or the original compiler behavior?

Constantly! And resolving every one of them required a judgment call that involved meetings between the developers, designers and testers. The spec is 800 pages long, and there are a lot of places where bugs can creep in.

Typically, what I would do if I found a spec violation was first, produce the simplest possible program whose behavior differed from the specified behavior. It is a lot easier to understand these things with a minimal example.

Next I would think about whether there was a realistic example: are there real-world programs out there whose correct behavior relies on the C# compiler not implementing the specification exactly right? If yes, then that is points towards either changing the spec to match the implementation, or deliberately not fixing the bug and being in violation of the specification forever.

If you want to see examples of that, just get the Roslyn sources and look for the words “deliberate spec violation”. I did not want anyone to discover the bug later on and fix it, if we had decided to not fix the bug, so all the ones I worked on I very carefully documented.

6. Asynchronous programming with async/await keywords is probably one of the most prominent features, originally introduced in C# 5.0, but has now found its place in many other languages like JavaScript, Python, Dart etc. This feature was improved in C# 6.0 with support for asynchronous calls in catch and finally blocks. Could this programming model be expanded further, e.g. with support of asynchronous iterators (async Task<IEnumerable<T>> that could both yield and await)?

First off, just to clarify the question: asynchronous waits were introduced to C# in C# 5.0, but there were other languages that had features like this much earlier. The design of the feature in C# 5.0 was heavily influenced by asynchronous workflows in F#, for example.

Could the feature be extended further? Absolutely. There is no logical impediment to that sort of combination of features. Like all features, it’s a matter of prioritization; someone has to design, implement, test and document every feature, and that means doing work that is then not spent on other features that might be more useful.

7. Although you are not a part of the C# team anymore, are you following the language design for C# 7.0? How do you like the new features? Which one is your favorite and why?

I am following the process with interest, but not participating much. Between working on languages all day, editing programming books, and writing a blog about programming, I don’t have a lot of extra time to participate in the C# design process. I do stick my head in occasionally though, and the design team has been good enough to invite me over for lunch every now and then.

I am very pleased with the proposed slate of features for upcoming versions of C#. We worked so long and so hard on Roslyn to make it a solid foundation for rapidly developing new features, and now it is. The features I am most looking forward to for upcoming versions of C# are those that are inspired by functional languages, like tuples and pattern matching. I’ve been working in OCaml for a few months now and I have gotten very used to having both at my disposal!

8. Why doesn't C# support converting a lambda expression with a statement body into an expression tree? Is it hard to implement? Or did the C# design team not give much importance to it? Do you know if it will be included in a future version?

Converting lambdas to expression trees was one of my features for C# 3.0, so I’m quite familiar with this one! Extending the feature to statements was not implemented in C# 3.0 because it is not necessary to make LINQ work and we were very short on time for that release. The thing about LINQ is that it required a large number of language features to all work together effectively, so any part of those features that was not necessary was cut.

Again, it comes down to opportunity costs. The feature is not conceptually hard, but it is a lot of work. There are a great many statements in C# and you need to write the logic to transform all of them into expression tree formats. There’s a lot of tests to write, a lot of documentation to write, and so on. It’s a pretty expensive feature but it doesn’t add much power to the language; that effort could probably be better spent elsewhere. If we could get it for free, then sure, it’s a nice thing to have, but we can’t get it for free. I don’t know if there are any plans here; I have not heard of any.

9. Many new and upcoming C# features make functional programming with C# easier. Where do you see this going? How do you foresee the future of functional programming with C#? Amidst this, do you see a future for F# or is it just going to be a laboratory for functional features that eventually show up in C#?

As I said above, I love this trend and I see it continuing. There has been a real renaissance of functional programming over the last couple of decades and it is still going strong. The benefits of programming in a functional style are numerous: code is easier to reason about when there are fewer side effects, code can be parallelized more easily and more safely, and so on.

The hard part will be getting these features into C# while still keeping the “spirit” of the language the same. The first time I saw the “pattern matching” feature proposal for C# I was really impressed by how the designers managed to take a feature usually associated with functional languages like OCaml or Haskell, and make it feel like it was a natural extension to C# rather than something grafted on.

I see a bright future for F# as well. Both C# and F# are hitting sweet spots; C# is attractive to OO developers who can benefit from more functional features, and F# is attractive to developers who like programming primarily in functional style but have to interoperate with a whole world full of libraries designed to work with OO languages. The .NET platform is fundamentally a multi-language strategy; there’s lot of room for F# in there.

10. We have seen a massive change in Microsoft's attitude with .NET going Open Source and all. Hypothetically, if this would have been the case when C# was introduced to the world, how would have the language been shaped compared to what it is now?

I think whether the source code is public or private doesn’t really affect the design of the language. The factor in Microsoft’s astonishing switch to embrace open source that will most affect the design of the language is that the design process itself is now open. Getting ideas out for criticism by the public earlier certainly has costs, but the benefits greatly outweigh them.

It’s hard to say how things would have been different had the design process been more open from the beginning. I suspect that it would have been harder to get good discussion on big, complicated, far reaching features, like generic types or LINQ, and easier to get feedback on small “productivity” features that affect day-to-day developer life.

11. You have had a remarkable career. How does one become as good as Eric Lippert? What sort of qualifications (both academically as well as professionally) are required to be as successful as you are?

That’s kind of you to say, but I want to deny the premise of the question. I know many, many successful developers both in the tools space and elsewhere that have a completely different background than I do. I know people who have PhDs in type theory and people with no formal CS education at all who are successful in programming language design. Personally, I found that having studied computer science at Waterloo was a great preparation, but that is neither a necessary nor a sufficient condition for having a fun career.

The things I see in common amongst the successful people in this industry who I admire are a drive to learn new things, taking enjoyment in passing knowledge on to others, and willingness to stick to it for a long time.

12. Any new hobbies/personal projects that you have been working on since we last spoke to you? We would love to see a video of you playing the Piano or the Ukulele!

I have been pretty busy learning several new-to-me programming languages since I joined Facebook, and thus I’ve been neglecting my hobbies. There’s a nice piano in the Facebook cafeteria though, and I’ve started playing again recently. I’ll see if I can put together a video!

Editorial Note: Due to Eric’s tight schedule, we have not received a video of him playing the Ukulele yet, but once we do, we will update this interview with the link.

13. Finally to wrap up, share your favorite C# gems or hidden features with our readers.

I’ll leave your readers with a little puzzle that is a favorite of mine; it illustrates that the C# type system is maybe more complicated than you think:

public class A<T> { public class B : A<int> { public void M() { System.Console.WriteLine(typeof(T)); } public class C : B { } } } public class P { public static void Main() { (new A<string>.B.C()).M(); } }

What do you think this little program prints out, and why? Now actually run it and see if you were right! If your first guess is wrong, don’t feel too bad. I got it wrong the first time I saw it too!

***

Thank you Eric! It was a pleasure interacting with you.

The interview questions were curated by Damir Arh, Suprotim Agarwal and Yacoub Massad.

This article has been editorially reviewed by Suprotim Agarwal.