back to article Azure Pipelines go Slack while Microsoft frees data breakpoints from the shackles of C++

Microsoft emitted an Azure Pipelines app for Slack today while also reminding devs of the tweaks made to breakpoints in the upcoming combo of Visual Studio 2019 and .NET Core 3.0. Devs hiding in the hipster world of Slack were given the bad news today that there is no escape from Azure Pipelines as Microsoft made an app …

  1. bombastic bob Silver badge
    Meh

    whoopee, ".Not" got something that C++ already had for, like, EVAR

    No matter how much Micro-shaft tries, they'll NEVER replace C++ and native Win32 calls with their bloatware ".Not" no matter WHAT they call it.

    And I'd be better off targeting GTK or Qt if I want cross-platform. Trying to shoehorn ".Not Core" into POSIX operating systems is laughable, at best, frightening at worst, and yet another "Embrace, Extend, Extinguish" attempt to those of us who actually KNOW better.

    I was a total Microsoft Windows fan up until the announcement of the ".Not Initative" when Ballmer took the reigns. The 1997 PDC here in San Diego was the last conference I went to. I instinctively knew that Micro-shaft had made a sharp turn and was heading into the WRONG direction.

    So the idea that they've taken something that worked really well in DevStudio for C++ applications ('data changed' breakpoints, something I have made use of before, LONG ago) and _FINALLY_ got around to putting into the ".Nonsense" side of things, it's no great accomplishment. Wheee.

    I got used to MFC with the old 'Visual C++" stuff, back in the 16-bit days, even, and I think *THAT* IDE [which was VERY typist-friendly] is STILL BETTER than anything that Micro-shaft has produced since they went all VB-ish with their "properties" windows for dialog controls, etc.. Class Wizard and dialog control properties, the way it was in DevStudio '98 (pop-up tabbed dialog boxen) was MUCH easier, especially for dialog boxes.

    Anyway, I've always liked the integrated debugger, having had to use CodeView before that, with dual monitors even. But I don't do C-pound nor ".Not" and so it's no wonder I didn't know the features were missing...

    Icon, because this is all like "whoopeee" and "wheeee" without the exclamation points, bold text, nor capitalization.

    1. Anonymous Coward
      Anonymous Coward

      Re: whoopee, ".Not" got something that C++ already had for, like, EVAR

      Previously the domain of C++ coders (from Visual Studio 2017 15.8)....

      Right.

    2. TDog

      Re: whoopee, ".Not" got something that C++ already had for, like, EVAR

      So you've .not been holding the grudge for long then?

    3. RyokuMas
      Facepalm

      Re: whoopee, ".Not" got something that C++ already had for, like, EVAR

      "I was a total Microsoft Windows fan up until the announcement of the ".Not Initative" when Ballmer took the reigns. The 1997 PDC here in San Diego was the last conference I went to. I instinctively knew that Micro-shaft had made a sharp turn and was heading into the WRONG direction."

      Trying new things is called "innovation". Sometimes it works, a lot of the time it doesn't (Microsoft seems especially good at this side of the equation), but without it, we wither and die.

      Basically, you're saying they tried something new that you didn't like and you're bitter about it. Boo hoo. If your comment had read like a rational argument, then maybe it would have carried some weight. But no - here is the same old rant being trotted out again, complete with name-calling ("Micro-shaft", ".Not"), attempts to establish superiority ("those of us who actually know better"), and 90s AOL style use of caps, stars, underscores and deliberately incorrect spelling ("EVAR") in an attempt to draw emphasis.

      We get that you do not like modern Microsoft. We get that you do not believe that their current UI style or initiatives are the right way to go. But, like it or not, this is the direction they have decided to go. If there is a specific issue that comes up in an article that you feel the need to comment on, then raise it and discuss it like an adult - these "it was better in the old days" rants and they way they are written are just plain boring now.

      At least Eadon's explosions were mildly entertaining. Grow up.

      1. dajames

        Re: whoopee, ".Not" got something that C++ already had for, like, EVAR

        Trying new things is called "innovation". Sometimes it works, a lot of the time it doesn't (Microsoft seems especially good at this side of the equation), but without it, we wither and die.

        True ... but probably unimportant.

        .Net was conceived as Java with a Redmondian accent, back when Sun Micrososytems were getting shirty with Microsoft for putting non-portable things in to Java. If there was innovation then it was Sun's not Microsoft's.

        Actually, though, I'm not sure there was innovation, as the only "new" thing in Java was that it used an interpreted intermediate code that could be run on any platform -- and, in particular, in a browser ... and the only part of that that was new was targeting the browser, because UCSD did the intermediate code for portability thing with their Pascal P-System 20 years earlier.

        Just think what good tooling for C++ we might have today if Microsoft had taken all the resources they threw at .Net and used them to improve the C++ development environment instead! Just think of the fancy debuggers, profilers, refactoring editors, and all the other stuff they might have been able to develop if they hadn't wasted their effort on an unnecessary runtime environment that nobody needed.

        Microsoft ended up buying a slice of Sun, anyway, so the spat over Java went away. They didn't need to invent C-Hash and port all their huge codebase of Java to it ... they could have got on with something that produces material benefits for their users, instead!

  2. Czrly

    Performance?

    I wonder what the performance impact of these new breakpoints is, at debug time.

    In my experience, the closest existing feature must be the conditional breakpoints that have been available in Visual Studio for forever. The problem with them is that they're super useful and also super slow -- at LEAST a factor of 10 slow-down just for setting a single one.

    As a consequence, I never use them and end up writing stuff like `if (.. condition ..) Debugger.Break();` all over the place, removing the lines before committing. Saves hours of waiting in debug.

    Would be cool if that becomes a thing of the past.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like