Leaderboard

I'm no doubt a minority given the current list of replies, but I'd say warnings or feedback isn't the way to go. I'd prefer effort go to building safe constructs that leverage the existing strengths of the language. I mean a DVR is almost there, what if you could have implicit named globals that are selectable by name at the boundary of an IPE structure? Instant "safe" global, the user doesn't need to know anything about the synchronization going on behind the scenes. I realize of course this is no safer than a normal DVR but you'd be solving a lot of synchronization issues surrounding globals right out of the gate using pieces that are already there... Even better if these named variables need not be global, but could be local or arbitrarily scoped data. Basically I don't believe it's the IDE's job to teach the programmer, which is what a warning system is if it's not completely ignored. The IDE's job is to give me rock solid tools I can use easily.

Please go here for more info. We need the support of all CLAs. Here's your chance to be heard. Shape the CLA Summit, get recognition and spread knowledge among the community. If you don't have access to the forum there then please request to be added if you're a CLA.

Thanks for the feedback, everyone. This is one of those "years away on the horizon" projects for me, but I wanted to get a feel for how to start thinking about it. Let me ask the question another way -- there is a body of research out there on software constructs that cannot create race conditions. Certain operations are simply ruled out even if they are frequently ok because they open the door to problems but it is too hard (or unknown) to prove whether a given usage of an operation is safe or not. Assume that LabVIEW retained the ability to have a raw global or a free-for-all DVR to do the "I just want to do this and have it work the easy way" solution, we could also have a separate feature -- let's call it a "safe global" for the moment -- which didn't allow all the flexibility but in return allowed you to know that you didn't have issues. Would there be interest in LabVIEW developing that as a parallel solution? Or would you rather LV focus on improving the warning feedback for questionable cases in the easier-to-use-but-error-allowing solutions? The two areas are somewhat orthogonal.