debugging comparison LV vs other languages. Opinions?

[Ben_Phillips]

I was using the LV timing profiling tool and thinking it brilliant after characterizing/fixing a couple nasty bottlenecks in my own designs, it occurred to me to ask, how do other tools/languages compare in terms of debugging? Are they more or less useful and/or profound? I've become particularly interested in C# and Objective C (and now Swift) but can't claim any prowess. But just grasshoppa stage now.

Would like to hear other opinions since I'm addmittedly not very cross-language yet.

I am familiar with Python's easily uncompiled checks for assertions at compile time, but beyond that really almost nothing.  As in, it won't compile unless it's true at least to those rules, but it runs just as fast as ever when in exe mode.

[MrHappyAsthma]

I've used Xcode for Objective-C before.  It has a pretty standard debugger.  It also has good memory profiling tools.  Some other nifty features.  But it is not as user-friendly as LabVIEW (in my opinion).  I strongly believe "highlight execution" has saved me more hours of debugging than any other tool I've ever used. 

[JÞB]

Well, since its still on my clipboard from another post-

https://www.ni.com/docs/en-US/bundle/labview/page/vi-execution-speed.html

Find another development environment that has a help file section like that to explain the inner workings of code.

Now let me ask- are you concerned about debugging or optimization here?  Yes there is a bit of overlap between the two but, I want to opine on your objective.

[Ben_Phillips]

Thanks for the replies.  

I wish I could edit my post now to make it half as long, but can't figure out how to do that.  I'm pretty sure I see post-edited posts elsewhere around here.

[MrHappyAsthma]

---

@Ben_Phillips wrote:

Thanks for the replies.  

I wish I could edit my post now to make it half as long, but can't figure out how to do that.  I'm pretty sure I see post-edited posts elsewhere around here.

---

I have no official info on this, but it seems as though after a certain amount of time, posts become un-editable.  I personally find it annoying.  But you do with what you have 😛

[crossrulz]

There is an edit timeout.  I want to say it was set to 10 minutes, but I won't guarantee that, especially as many changes they have made to the boards since I heard that.

But you can always report post to the moderator and ask them to change it for you.

[tyk007]

Well if you push me...

LabVIEW's debugging tools are ok. They do their job, and they normally do it quite well. I come from a .Net environment (primarily using Visual Studio with the typical add-ons) and here are some of the debugging features that are present in that ecosystem for comparison:

• You can set a break-point somewhere, run the code, hit the break-point then re-wind time (ie the entire call stack) and look at the execution of statements and the values of variables all the way to the entry point. You can't do that in LabVIEW unless you already have probes setup which assumes you already know what you are looking for. This is a feature Microsoft calls Intellitrace, is unbelievably useful, and is available for use even for applications running on remote computers (if you pay for a high enough version of Visual Studio that is). There are a number of relatively cheap alternatives available as addons that perform this same task.
• You can, at a break-point, edit un-executed statements during execution and then continue. This is a feature called Edit and Continue and supports x86 and now x64 targets and means you don't need to stop and re-start your application. Used this on more than a few occasions when I noticed a typo or five. Sounds awesome and it is - but like most features it has limitations.
• Watch windows are available (ie. probe windows) of course but Visual Studio also extra watch windows that capture the state of all local variables that exist in that method as well as the returns of any methods that are not stored to a particular variable ("Autos") without you lifting a finger. Think of Autos as data on a wire in LabVIEW.
• If you are interested in performance there are tools that allow you to look at single line execution times, memory allocation and de-alloaction etc. These are similar to to the tools in LabVIEW but rather than just providing raw data are able to present that information in a useful way to allows you to pin-point performance bottlenecks (eg. hot paths through the code, memory profiles, snapshot comparisons etc.). If only the Desktop Execution Trace Toolkit had these metrics to speed up the analysis 
• Want to know whats hapening with your asychronous system? With a large enough system it can be hard to see in LabVIEW without adding your own debugging code. Visual Studio comes with the ability to see what is happening with every thread of execution, every abstracted Task and the history of those said items. And you don't have to drill through the code to find them or add debugging tools to the code in order to provide the same features. Its out of the box.
• In terms of documenting the "inner workings" - this is all fully documented down to the native level in the Microsoft implementation and released as a set of (large) ECMA standards. They are available for download and exist as part of the help file installation set. Even the .Net Framework, the huge set of base class libraries that all .Net applications use (ie. primitives or the add-on modules/toolkits in LabVIEW world) is available online as source (http://referencesource.microsoft.com/). That's right, you can browse inside those libraries and see how they tick. No password-protected VIs here folks. Are the help files small and simple? Nope. The scope here is also much, much larger so it also takes a greater amount of time to read through the documentation and understand those same inner workings.
• The .Net Framework base class libraries can be debugged during execution. Some base class method throwing an exception? If the documentation doesn't help, no worries. Just debug into that pesky base class method and see whats up.
• And if you want a new debugging feature? Write one yourself and plug it into the IDE. And there are plenty of third-party add-ons that do just that - add more debugging or performance tools into the development environment. Chances are though you won't write one - just download a free one or buy one from a company that specialises in selling them. Personally I use dotTrace, dotMemory, dotPeek, Oz-Code and .Net Reflector. No need to buy the expensive versions of Visual Studio. Spend a few hundred bucks and get all the tools from other suppliers. 

These are the features I'm aware of but the reality is I barely tap into the debugging potential of what is available.

I know it seems like I'm ragging on LabVIEW here and being a bit of a Microsoft evangelist but the reality is that the user base and complexity of the .Net ecosystem is orders of magnitude larger - and thus the need for improved debugging tools triggers a larger business and community response. When I'm programming in LabVIEW I don't often complain about the debugging tools available so they are obviously fairly fit for my purpose.

[billko]

I don't think you were ragging on LabVIEW, you just said what you liked about Visual Studio and .NET debugging tools.

[JÞB]

I'll kudos that.

Thank you.  (Now what is your opinion)

[Ben_Phillips]

Thank you, well written reply.