Out of all the presentations I have produced I like the immediacy one the best. In it I talked about functional programming and what I now call Immediately Testable VIs (ITVI). Thanks to James Mac for the terminology clarification.
The thing for me that makes LabVIEW stand out from the software crowd is how close you are to the final running bit of software.
Let's look at a simple VI.
We can tinker with it, probe it and change stuff. If you program in text based languages this is pretty fantastic stuff.
Now we stick a framework around our code, giving us all sorts of useful stuff. But with every benefit, there is usually a cost.
As an example I'm going to pick on Actor Framework but I imagine this applies to any framework (including our own SSDC templates). All of the Actor framework projects I've been exposed to have a very low percentage of VIs that you can just run and experiment with. To clarify it means that a VI cannot run on it's own, it needs the whole or part of the framework to be running to be able to run itself. I call this Framework Coupling.
Here's our queue component and it is a non-ITVI, to test this VI I would need a teststub or to run the entire application.
As we design we need to think about framework VIs and ITVIs and we need to keep them separate. That way we can get all the advantages of LabVIEW in the parts we need it and the carrier VIs etc for your framework just get on with their work.
So here's an example from a client, they had an actor that talked to a VISA instrument and the comment was "I like Actor Framework but it's hard to debug", my response was to suggest putting all the VISA stuff in a standard VI that you can just run to completion. I then suggested that they should then separate out framework VIs from VIs that do stuff. And magically it wasn't so hard to debug any more.
I know it's a pretty simple concept, but I've described it to enough experienced programmers and it's been helpful to them, maybe it will help you too.