Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Where on earth did Larry go?

Where on earth did Larry go?

  • Comments 17

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

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

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

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

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

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

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

  • 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?

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

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

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

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

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

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

  • "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????

  • "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.

Page 1 of 2 (17 items) 12