9 ms·

Eric Lippert is leaving Microsoft

123 points by amazedsaint 14y ago

nathanwdavis 14y ago
If you've never read Eric's blog, I highly recommend it for anyone into language design and implementation (C# or not).
dkhenry 14y ago
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.
- zwieback 14y ago
  Me too, love Coverity although I'm only using it for C right now.
sergiotapia 14y ago
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.
dklounge 14y ago
Enjoy the time off & Merry Christmas! Good luck at Coverity.
seanmcdirmid 14y ago
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).
- jacquesm 14y ago
  Why would you not have much faith in static analysis? Have you changed your mind on this?
  - seanmcdirmid 14y ago
    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.
    - jacquesm 14y ago
      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.
      - seanmcdirmid 14y ago
        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.
        munin 14y ago
        java and C# still allow casting, so I think there you will still want static analysis outside of existing language features.
- PedroBatista 14y ago
  Looks like your career is a string of bad bets.. (joking)
  - seanmcdirmid 14y ago
    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.
    - mdonohue 14y ago
      But then I wouldn't have had a job. :) Good to see your name again Sean.
- wsc981 14y ago
  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-analysis/ http://www.altdevblogaday.com/2011/12/24/static-code-analysi...
  - MattRogish 14y ago
    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!
  - loumf 14y ago
    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.
    - InclinedPlane 14y ago
      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.
    - eblade 14y ago
      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.
  - 14y ago
jbevain 14y ago
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: http://news.ycombinator.com/item?id=4842024 http://news.ycombinator.com/item?id=4842024 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...
- tonyedgecombe 14y ago
  "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.
  - tkellogg 14y ago
    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.
    - wtetzner 14y ago
      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.
- ericlippert 14y ago
  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.

123 points by amazedsaint 14y ago

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

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.

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

sergiotapia 14y ago

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.

dklounge 14y ago

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

seanmcdirmid 14y ago

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).

jacquesm 14y ago
Why would you not have much faith in static analysis? Have you changed your mind on this?
- seanmcdirmid 14y ago
  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.
  - jacquesm 14y ago
    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.
    - seanmcdirmid 14y ago
      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.
      - munin 14y ago
        java and C# still allow casting, so I think there you will still want static analysis outside of existing language features.
PedroBatista 14y ago
Looks like your career is a string of bad bets.. (joking)
- seanmcdirmid 14y ago
  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.
  - mdonohue 14y ago
    But then I wouldn't have had a job. :) Good to see your name again Sean.
wsc981 14y ago
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-analysis/ http://www.altdevblogaday.com/2011/12/24/static-code-analysi...
- MattRogish 14y ago
  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!
- loumf 14y ago
  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.
  - InclinedPlane 14y ago
    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.
  - eblade 14y ago
    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.
- 14y ago

jbevain 14y ago

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: http://news.ycombinator.com/item?id=4842024 http://news.ycombinator.com/item?id=4842024 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...

tonyedgecombe 14y ago
"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.
- tkellogg 14y ago
  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.
  - wtetzner 14y ago
    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.
ericlippert 14y ago
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.