Where on earth did Larry go?


No, nothing bad happened to me, I just got a bit caught up in work stuff.

 

I spent the last three weeks volunteering to help another team at Microsoft finish off the final set of work items on a new tool they’re building – one of the developers on the project quit for family reasons and they had a major milestone coming up last week and nobody to complete it.  Since the team doing the work knew that the tool would help in an area in which I was passionate, they asked and my manager was gracious enough to let me help them out.

Actually, it was a bit funny – I’ve never used Visual Studio as a development environment for anything real before, I hadn’t realized how amazing it is as a development environment (the ability to set breakpoints inside an XSL transform seems like magic).  It’s also a much more intense development experience than I’m used to.  For most of the past 30 years, my normal development cycle has been (in college I didn’t have the “copy it to my test machine” step, but otherwise it’s essentially been unchanged):

    1. “write some code”,
    2. “compile it”,
    3. “copy it to my test machine”,
    4. “test the changes”,
    5. got to #1.

Using Visual Studio changes the tempo of the cycle dramatically.  The JIT compiling, edit-and-continue support and the speed of the compiler combine to make a much more rapid turn-around time on changes than I’m used to.  This shows up in subtle ways – normally I have no trouble keeping up with my incoming email flow – I switch to Outlook while I’m in step #2 and #3 to read my email.  But while I was working in VS, I didn’t have time – there were no significant slow times in the process – the edit/compile/test cycle was sufficiently quick that I didn’t have the ability to keep up with my email.

Go figure.

 

Anyway, I’m back :)  I’m in a class all day today, so nothing more interesting, but I AM planning on finishing up the series on volume.  Oh, and I’ve got a new “API that should be banned” to write about :)

Comments (17)

  1. Matteo says:

    Next question is: what did you use so far if not VS?

  2. senkwe says:

    wait…did you just say JIT and "edit & continue"…could it be…nah. Not Larry :-)

  3. LarryOsterman says:

    Yeah, JIT and E&C.  The project was in C#.

    I have no problems at all with using C#.  And VS is quite nice when dealing with it.

    And what I usually use is Epsilon as my text editor and the NT build environment for compiling (I compile from within Epsilon, but it doesn’t change the workflow).

  4. El Guapo says:

    What the… you have to be kidding me??? What about the VS debugger. You never used it??? What the???

  5. Anony Moose says:

    I swear, there’s nothing like embedded software development (including downloading over a slow serial link for all testing and excluding any form of actual debugger – printf() and a few spare LEDs as your only debugging tools is fun) to make you appreciate a good IDE. And for all the complaints I have about details in Visual Studio, the debugger is still probably the finest Microsoft software I’ve ever used.

  6. LarryOsterman says:

    El Guapo, I mostly use windbg, sometimes I use the kernel debugger.

    The problem with the VS debugger is that it requires installing VS.  I reformat my test machine every week, installing VS would take literally hours that I simply don’t need to spend (windbg’s install takes about 5 minutes).

  7. EL WTF says:

    Larry, why not create an image of your test environment with VS installed.  That way, when you blow away your test machine, you have this image to fall back to.  No waiting for VS to be installed.  Also, what about setting up and using a VM for this?  I’ll admit, I’ve not jumped on the VM bandwagon yet, but I was wondering how dev folks in MS felt about this.  Also, from a work flow perspective, how did you ever get anything done using your old environment?

  8. m.k. says:

    Larry – Do you use this Epsilon editor – http://www.lugaru.com/ ?

    I respect your choice but am curious what special features it provides which Emacs or GVim for Windows don’t in a significantly better way?

    I use GVim always for coding and cannot imagine why anyone could use anything else for coding! (I also like the VC6/7 editor with VAssistX  but that’s when I need an IDE.)

  9. Norman Diamond says:

    > I reformat my test machine every week

    Bingo.  Install VS on your development machine, test the executables on your test machine.

    Besides, dogfooding calls for using VS and sending frequent crash dumps.

  10. LarryOsterman says:

    EL WTF: I can’t – the reason I flatten the test machine is to install a new version of Windows – I believe that it’s technically possible to build a version that also installs VS, it’s not worth the time.

    m.k.: I use Epsilon for several reasons.  First off, I went to college with Todd Doucette and Steve Doerfler, who wrote Epsilon.  Secondly, it’s fast.  Way faster than GNU Emacs.  GVim doesn’t have EMACS keybindings, and at this point they’re burned into my fingers.

    If I was to change editors, I’d probably switch to Source Insight, which has just about the best source code browser I’ve ever seen.

    Norman, I sent in MANY crash dumps during my 3 weeks of using Visual Studio.

  11. Norman Diamond says:

    > First off, I went to college with Todd Doucette and Steve

    > Doerfler, who wrote Epsilon.

    That doesn’t count.  I didn’t go to college with Bill Joy (vi) or Bram Moolenaar (vim).  Nor with the Bell Labs people who preceded them with qed and then ed (ed = castrated qed).

    > Secondly, it’s fast.

    You mean EMACS is still true?  Emacs Makes A Computer Slow?  Good thing no one else makes editor bloatware like that.

    > GVim doesn’t have EMACS keybindings, and at this point

    > they’re burned into my fingers.

    Yup, that’s the reason I still use gvim.  My fingers are all burnt by it, and I don’t have enough fingers to be burnt by emacs.

  12. Sven Groot says:

    You could just install the remote debugger on the test machine, then use VS from your development machine. :)

  13. LarryOsterman says:

    Norman, the last time I tried it, Emacs was pretty slow.

    Sven, IMHO, the VS debugger doesn’t provide enough value beyond WINDBG – and it doesn’t have a usable command line or support WINDBG’s debugger extensions.

  14. El Guapo says:

    "The problem with the VS debugger is that it requires installing VS.  I reformat my test machine every week, installing VS would take literally hours that I simply don’t need to spend (windbg’s install takes about 5 minutes)."

    What the??? *Rubs eyes, shakes head and looks again*  … HUH????

  15. nugget says:

    "Sven, IMHO, the VS debugger doesn’t provide enough value beyond WINDBG – and it doesn’t have a usable command line or support WINDBG’s debugger extensions."

    VS debugger is very handicaped compared to WindDBG, when it comes to real debugging, nothing beats WinDBG, it’s the best debugger I ever used.

  16. Massif says:

    Well, there’s a challenge to the VS team – make remote debugging such an awesome experience that Larry will change his habits.

  17. m.k. says:

    Larry> GVim doesn’t have EMACS keybindings, and at this point they’re burned into my fingers.

    Never say no in OSS world!! :) Some one already wrote Vimacs – Vim emulating Emacs. All the benefits of Vim plus you get to keep your Emacs habits!

    Couldn’t ask for more – http://www.algorithm.com.au/code/vimacs/about/index.html

    Try it out and see how it goes – Vim everywhere!!