Hacker News new | comments | show | ask | jobs | submit login
Eric Lippert is leaving Microsoft (ericlippert.com)
123 points by amazedsaint 1783 days ago | hide | past | web | 65 comments | favorite

One has to wonder if that's not related to how C# and .net are being treated as second class citizens nowadays at Microsoft.

As we saw recently:


they're looking for someone to work on a C# to native code compiler. Even if .net as a VM and the C# to IL compiler are far from gone (and probably never will be), it doesn't look like C# and .net are in favor at Microsoft nowadays.

Oh well, as long as Eric keeps on blogging...

There were many factors that led to this decision. I described the primary factor in my posting: I've been at this job for sixteen years at the same company, I am turning 40, and it is very common for people at that age to want to make a change.

I assure you that "how C# is treated" was in no way a factor; C# is treated extremely well at Microsoft. Moreover, think it through: I would not have taken a job that continues to improve the broader C# ecosystem if I thought that the .NET platform was some kind of dead end. It is vital.

I was going to say something similar. It's odd how, in a community that exhorts its members to constantly be seeking the best opportunities, someone leaving a company after over a decade is considered a sign of some deeper problem.

Thanks for the feedback Eric.

As a long time fan of C# and how it evolved (started with .net beta 1), and even more so of Roslyn, I for one would be very disappointed to see C# not being considered from Microsoft as I consider it.

Good luck in your next position, I heard that Coverity for .net is using Cecil :)

Don't get all conspiracy theory on us.

Sad to see Eric go (just started working with him!) but glad that he's moving on to other great things.

Huh, I'm definitely not going “all conspiracy theory” on you. And by you I guess I mean Microsoft?

The perception from the outside, or let say, my perception, is that both .net and C# along (C# being the flagship language for the platform) don't have the same place in Microsoft's strategy than they had say 4 years ago.

Eric being one more visible .net profile leaving Microsoft, I'm just saying it's interesting to wonder if that's related.

...I'm not saying that we didn't land on the moon, I'm just saying it's interesting to wonder if it really happened.

But you're absolutely right -- I'm glad I know now that I'm working on a new C# compiler for a dead language that no one uses.

Oh, and by "us" I meant HN. If you haven't noticed, I've been part of this community for quite a while.

Edit: This comment is maybe snarkier then I meant it. Add an eye roll or two and you'll get the gist.

  > ...I'm not saying that we didn't land on the moon,
  > I'm just saying it's interesting to wonder if it
  > really happened.
I don't think that conflating speculation with conspiracy theories is necessarily productive. It's not like Microsoft doesn't have a track record of abandoning partners in the past[1] (e.g. Plays 4 Sure).

  > If you haven't noticed, I've been part of this
  > community for quite a while.
I'm not sure that 'pulling rank' is necessarily constructive either. It just reminds me of those Slashdot threads where people with increasing smaller UIDs would reply with, "You must be new here," or "get off my lawn."

[1] Though I agree that completely abandoning C# would be suicide in the enterprise market.

I don't think that conflating speculation with conspiracy theories is necessarily productive. It's not like Microsoft doesn't have a track record of abandoning partners in the past[1] (e.g. Plays 4 Sure).

Conspiracy theories are just speculation too. One could argue that the US government has a history of all kinds of activities and thus many of the current conspiracies are in keeping with history. The essence of a conspiracy theory is speculation not grounded in evidence or probability.

I'm not sure that 'pulling rank' is necessarily constructive either. It just reminds me of those Slashdot threads where people with increasing smaller UIDs would reply with, "You must be new here," or "get off my lawn."

My comment was directed quite clearly at the insinuation that I was speaking on behalf of Microsoft, which I do not do.

I may have been snarky, but only because I see this quite a lot on HN -- that people are the company they work for. We're just members of this community like any other.

This. It is unbelievable the number of times where people will say something like "I understand why you feel that way..." (if I am say arguing in favor of some MS product/decision) as if, because I work for Microsoft, I must be some non-thinking shill or purveyor of FUD. It is unfortunate because it prevents me from even wanting to participate in any conversation here involving any tech company because everything I say is apparently interpreted through the lens of my employer, because clearly people are that one-dimensional :)

Microsoft seems to be focused on Metro as the way forward. I don't think it's that much of a stretch that they might be pushing JavaScript to the fore-front of their development strategy while starting to side-line C#. I could draw parallels to Apple's sidelining of the Carbon API in favor of their Cocoa API. IIRC, Photoshop is still using the Carbon, even though the majority of development now is in Cocoa.

Granted, I don't follow the Microsoft development community closely, so there may be something that I'm missing out on, but I don't see it to be as 'out there' as claiming vast conspiracy theories surrounding historical events.

Focusing on WinRT as the way forward != pushing Javascript to the forefront and sidelining C#

I didn't say that one implied the other. Just that it didn't seem as 'out there' as moon landing or holocaust deniers.

Right, the "conspiracy theory" phrase is weird (what is the conspiracy supposed to be?)

No offense but you're reading waaay more into it than what they wrote. "Difference in strategic position" doesn't equate to "dead language that no one uses" and a question into the departure of a high-profile MS exec doesn't rise to the level of moon landing lunacy. Unless you have some sort of inside knowledge about what the parent comment to yours actually meant I can only assume that this discussion in general is hitting too close to home for complete objectivity on your part.

I also don't think that being signed up for a site for a longer duration of time inherently gives you any right to speak for the entire site, even in a conversation with one of relatively less "seniority" on the site (whatever that even means). It's nice that you clarified what you meant by "us" but that wasn't being debated and it didn't add to any points you've made.

I am neither high-profile nor an executive.

You're definitely high-profile amongst the engineer grunts and on various internal mailing lists. I don't know if that wins you any private soirées with Soma or not, but it's something :)

Much like the other commenters have mentioned, you're "high profile" if only because I've actually heard of you and read your writings with interest before (via the same means legions of other developers will have done so). I'll remove "exec" if I still have Edit perms though, apologies.

I've heard of you, and I'm usually the last to the party.

You're a fucking hero to some of us.

.NET Champion perhaps? :)

The only consistency in Microsoft's strategy for developer tools is constant change.

Doesn't take a conspiracy theorist to figure out C#/.NET is no longer Microsoft's sole flagship strategy for developers...

Microsoft have recently discontinued their only managed .NET cross-platform managed UI effort in Silverlight in favor of the multi-language Win 8 SDK with JavaScript, C# and C++ bindings. Most Windows applications are still being written in C++ where you would barely notice the difference if Windows didn't have .NET installed, this is in stark contrast for instance with Apple's positioning of their own XCode/Obj-C development platform they've used to build OSX, which essentially would be a glorified terminal if you took away all Obj-C libraries and applications.

Microsoft have also made significant investments in JavaScript and node.js, with even Anders moving off C# to work on TypeScript for a bit.

Basically they're business models have changed where they're now positioning Azure (their new server strategy) as a multi-platform cloud strategy with support parity for .NET, node.js, Java, PHP and Python: https://www.windowsazure.com/en-us/develop/overview/

So I don't think it's a stretch to observe there has been in-fact a "Difference in strategic position" with Microsoft's attitude towards C#/.NET.

> Doesn't take a conspiracy theorist to figure out C#/.NET is no longer Microsoft's sole flagship strategy for developers

"Sole Flagship" strategies, be they for language or DB, whatever, are doomed to fail. The company has "picked a winner," reducing internal diversity and competition between approaches. Past a certain size threshold, a big company has become a number of interlinked ecosystems. Promoting standards to reduce friction of internal information sharing is the way to go. This enhances the positive effect of internal competition, instead of squashing it.

>> "Sole Flagship" strategies, be they for language or DB, whatever, are doomed to fail.

Riiight, cause standardizing on a single platform and maintaining one set of documentation and cultivating 1 shared knowledge-base is really hurting Android's use of Java and Apple's use of Obj-C.

I was talking about internal big company directives. The ones I've seen failed (Shell Oil), unless they were about infrastructure. (Amazon, Wells Fargo)

Android and iOS are a different case. The diversity they both want, they are getting. The diversity iOS doesn't want is controlled. In a big company, the ecosystems have mostly been internal, and standardizing interoperation has traditionally been about internal efficiencies. App ecosystems aren't necessarily like that -- they are for external consumption. (Though one could make the argument that Intents are about efficiency within the Android ecosystem.)

From this I see that C# as a UI language is not the future, that's hardly surprising.

There is no doubt that Azure is being pushed as a back-end, and front end is targeting web ui, metro, and other mobile devices. Silverlight never got market traction, so needs to be dropped.

But all that code on the Azure servers - that's all going to be .net based. Of that there is little doubt.

I think the problem here is conflating UI language usage with language usage in general. The bulk of app code is going into service layers, and they are all written on C#.

I think that you're reading the tea-leaves all wrong. You also have made a few unproven claims.

Chief among them to my mind, is that Microsoft has made a "significant investments in JavaScript and node.js". Significant compared to what? Certainly not compared to .NET which has been a gargantuan decade+ investment.

In my opinion: A strong cross-platform C# eco-system is simply not good for Microsoft. They had to kill Silverlight. By backing Javascript, they bought some time. Silverlight was getting too good. Microsoft does not want a good, easy-to-use cross-platform kit with static-typing and native capabilities to exist. Anything cross-platform from Microsoft is a head-fake, a bare-bones concession, or someone's pet-project that grows into a monster which will have to be killed.

I could be wrong, but I don't think that I am.

>> Significant compared to what?

Significant, in the fact that there's now a less clear choice of what to use when developing a Windows 8 UI or server application.

>> In my opinion: A strong cross-platform C# eco-system is simply not good for Microsoft.

In that case it's a conflict of interests, as it may not be good for Microsoft, but it's certainly good for the .NET community which lets .NET developers re-use and leverage their work on multiple platforms. Fortunately we have Xamarin filling this void, but if it wasn't for them .NET developers would be missing out on the most exciting mobile platforms to date: iOS / Android.

I know nothing about this particular situation but it pretty well known that power-struggles are the default mode of operation in many large corporations (and Microsoft in particular) and that further almost any manager who leaves a company without being escorted out in handcuffs is going to be "leaving for great things" according to all concerned. Thus speculation about power struggles and corporate emphases is natural unless the company is unusually transparent and/or all of the managers' product are doing well.

Not that managers don't leave for better things on a regular basis but making that the leaving-mantra sadly has reduced its credibility.

Edit: It would be "conspiracy theory" to light on one explanation and push it blindly without overwhelming evidence. But speculation in the dark is fine if it is labeled as such. Real, concrete information is better than speculation the dark. If one could count on such concrete information from Microsoft and others, one would want avoid.

>any manager who leaves a company without being escorted out in handcuffs is going to be "leaving for great things" according to all concerned.

That may be true, and would perhaps be applicable to this case, if Eric were a manager. He is not. He is (was) a Principal SDE. This means he writes code and likely has lots of input into high level architectural/design decisions. Any influence he had over the actions of others is likely due more to respect for his technical acumen than any kind of managerial title. I suspect the closest he would come to being a manager would be any mentoring (official or unofficial) that he did, which is likely more effective than being someones official boss :)

Sure but isn't the point that he is high enough on the "totem pole" that diplomacy needs prevail over all else?

It's not their particular authority over others but their general importance to the company's image and the company's importance to their image which incentivizes everyone to use euphemisms in the situation of a departing of manager. It seems logical that the case of a Principle SDE would be similar.

"they're looking for someone to work on a C# to native code compiler"

I wouldn't read too much into that. My guess is they are looking for something easier to work with for device driver developers.

I'm not even sure why that's necessary. If you need a block of performant code, use unsafe C# (no array bounds checking, unmanaged pointers, etc). Otherwise, C# runs pretty fast the way it is.

I don't think it would be a speed thing. It would let you write C# that ran in kernel space without needing the CLR.

I'm inclined to agree.

Getting support issues nailed with the .Net framework has started to become a PITA in the last year or so. It does feel like they are winding it all down.

I think .NET will always be there, I think C# will continue to grow and evolve as a language (with the help of its big brother F#).

Nice to see a move to Coverity. I use their product and it is one of the best static analysis tools I have used. Maybe we will see support for more languages rolled into the tool.

Hey Eric while your there how about you make the CLI tool suck less. I want a simple invocation to test for the presence of failures.

Me too, love Coverity although I'm only using it for C right now.

This is quite a shock. I worked at Coverity about 7 years ago, but I didn't have much faith in static analysis (now I'm at Microsoft, ironic).

I wonder why you lost or never had any faith in static analysis. On Apple's platforms it's becoming a really big "thing". Also John Carmack talked about the benefits of static code analysis at QuakeCon 2012.

Also a good read: http://www.altdevblogaday.com/2011/12/24/static-code-analysi...

It's a huge big deal in enterprise software security; lots of Fortune 500 firms deploy it (most of them use Fortify, not Coverity).

I'm not a fan either.

I'm a big +1 for static code analysis as a "silent observer" of code practices. We have various static checks run on each build and if a certain threshold is crossed, the build will kick out an error (we've decided not to have it fail entirely, although some could argue that's a reasonable thing to do).

Although we're a Ruby and JS shop, we take advantage of different services and libraries that perform different checks. In dynamic-language land it's a lot harder to do some of the things that static complication provides, but it's a heck of a lot better than nothing!

I hated every attempt at static analysis until I started programming with Xcode. In my usage, Build and Analyze is always right -- that's the difference. Other tools (lint, FXCop) are too noisy. Even warnings in some compilers are an annoyance that you have to code around to eliminate.

Fxcop is massively overused. The rules are designed for teams who are building libraries and frameworks (thus the name, Fx is short for framework). For ordinary app development many of the rules are inappropriate, which can lead to an impedance mismatch and frustration.

Yeah, I read that Objective-C got it's ARC feature after static analyzer was integrated to Xcode. No more manual reference counting is definitely a plus.

Why would you not have much faith in static analysis? Have you changed your mind on this?

I am a firm believer that the best way to fix programming is through better programming languages, which I learned about myself while working at Coverity. Otherwise I think it was a great place to work: lots of very smart people, a very good business plan, great startup stock (back then), but I'm too idealistic!

Static analysis tools are very pragmatic in a world where better languages aren't adopted very often.

I've been 'around' static analysis a decent amount in the past 10 months or so, and my conclusion is that the deep solution is ML/Haskell/etc, not static analysis.

Writing in C/C++ is like asking to be shot in your foot. So you get static analysis, which gives you a modicum of help.

Do you think better languages will make static analysis useless? I would think the combination to be better than better languages alone. Or are you arguing that static analysis by compilers should be improved (1) so far that separate tools for static analysis aren't useful anymore?

(1) almost all compiled language systems do _some_ static analysis. For example, many compilers and linkers do dead code elimination, and Java and C# must, by spec, do static analyisis to prove that variables won't be used before set.

Static analysis is about performing heuristical non-local analysis on a code base to find bugs. We aren't talking about modular type checking that is performed by the compiler and explicitly enabled by the programming language design.

If you eliminate potential bugs to be found, static analysis is devalued significantly. So while static analysis may seem necessary for C++ code (very buggy, not much safety), it has less value for Java or C# code, where the easy-to-detect bugs and the remaining bugs are much more difficult to find.

Really depends on the type of code you are writing. If you're writing a Mars Rover, you're probably not using a single dynamic feature and static analysis works quite well in this case. So long as you're writing 'dead' software, you're better off with static analysis.

As soon as you try to write living software, that is, software able to evolve over time without restarting, static analysis goes out the window. Design by contract and test suites are your friends in this case.

Ok, that explains your position in a way that makes good sense to me. I agree that better programming languages would be good (and in fact, we do have them) but I'm a pretty pragmatic person and any tool that helps me to do the job that I need to do better is welcome.

Until better languages are much more common static analysis can save you a lot of time tracking down obscure issues and for that alone it gets my vote. I'll be more than happy to ditch all that for a better way to develop software (not necessarily just better languages) it feels as if we're doing something terribly wrong but I can't quite put my finger on what it is.

It feels as if we're building fragility right into the process from the ground up when in fact we should be doing the opposite.

Right. I should have replaced "faith" with "excitement."

If you program in C++, you need static analysis. I'm not so sold on it for Java or C#, their is a lot less low hanging fruit in a moderately modern statically typed language.

java and C# still allow casting, so I think there you will still want static analysis outside of existing language features.

Yes, and they have null pointers also, but such bugs aren't as horrible as they are in c++, they show up more quickly during tests and are easier to debug.

C++ remains the market maker for the static analysis industry.

static analysis is always going to result in a deluge of false positives

i think the future is symbolic execution, which due to a lot of factors is becoming practical

symbolic execution is very similar to static analysis in purpose, if not name (closer to verification). You are right about the false positive rate, but I don't see why you think its becoming more practical?

what do you think about klee.llvm.org?

Looks like your career is a string of bad bets..


Quite true. I'm sure it would have worked out well financially if I hanged around in San Francisco (probably working for Coverity) rather than go to Lausanne to do a postdoc.

But then I wouldn't have had a job. :) Good to see your name again Sean.

If you've never read Eric's blog, I highly recommend it for anyone into language design and implementation (C# or not).

C# was my first programming language and no doubt what caused me to love my trade. I wish Mr. Lippert the best of luck and I hope he finds happiness and new found direction in this new transition.

Enjoy the time off & Merry Christmas! Good luck at Coverity.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact