Leaderboard

As for the structure, you may wish to watch the JeffK+Mercer presentation at NI week you can get here My understanding: basically it is a disable structure where instead of manually enabling/disabling, the compiler will run through all cases and enable the first case which doesn't cause a compiler error. When used in conjunction with a vim you can do fancy things. For example if you wanted to make 1 node that did "concatenate stuff" you could have two cases, 1 assuming the inputs are strings and 2 assuming they are scalars or arrays. If the type passed in is not a string, that case1 will cause a compiler error and it will go on to case2 with the more flexible build array, which will compile. In the NI week presentation it sounded like it was mostly solid but too early to be comfortable throwing it out to the masses yet.

Again, we're not talking about a non-strictly-typed language here. All the type checking can be done at compile time. Have you done any programming in F# or another ML derivative? I've mostly seen this in those functional languages. For example, generics allow you to write a sorting algorithm that takes a list, and a comparison function that operates on elements of that list. The compiler verifies that the comparison function matches the list element type, so you can't have a run-time type mismatch. Right now you can't do this in LabVIEW. You can either have your list contain variants, in which case you could get a run-time type mismatch, or you could wrap your data in a class that implements a comparison function, but since LabVIEW doesn't allow implementation of interfaces, this only works if your data class inherits from some Comparable class, which won't work if you actually want to inherit from some other class that might not allow comparison. I would love to see this in LabVIEW.