Testy

This is one example of how awesome discriminated unions would be in LabVIEW. They would force you to handle the possibility of an error. They've actually been proposed on the idea exchange and unfortunately got shot down: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525 I think F# is has a lot of good examples of functional features that could be implemented in LabVIEW: generic programming, discriminated unions, lambdas, and partial application. What I think makes F# such a good example of what LabVIEW could do is that it implements these features while allowing side effects, supporting OOP, and other non-functinal features just like LabVIEW.

I disagree with this. Composing IO monads with Haskell's do-notation looks almost exactly like effectful imperative programming. This isn't problematic. VIs that return multiple values are analogous to functions that return tuples. This is true for some functional concepts like purity and referential transparency. But there are other immensely useful language features common in functional languages that could be implemented in LabVIEW without breaking current language features, like parametric polymorphism, disjoint unions, lambdas, and partial application. I think generic higher-order functions and laziness are what make Haskell difficult to reason about for beginners. I don't think laziness would ever be a good fit for LabVIEW and developers could avoid generic higher-order VIs if they didn't like them.

I don't think there's anything wrong with it, as it's what I chose to do. But as you said if the channel state gets more complex, it would probably be cleaner to switch to classes. However the Exchange Idea I linked to would be just as good (I think better) than either of these solutions regardless of the complexity of the channel state. I was more curious about choice of data structure to represent the state channel than I was about handling displaying the data. What would you put inside the XControl's Data.ctl?

The problem: I have a digital channel that can be configured as an input or an output. If it is an input, I only car about seeing its state. If it's an output, I want to be able to configure it as either a simple digital output (on/off) or a PWM output (frequency and duty cycle). I want to be able to request the state of this channel, and I want my views to receive an update when its state changes. How would you express the state of this channel in a LabVIEW data type? This idea was shot down: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525 However, if this idea was a LabVIEW feature, it would allow this concise definition of the state of my channel: Using this data type to update a view would be simple: This is just an implementation of statically typed sum types http://en.wikipedia.org/wiki/Tagged_union in LabVIEW. We already have statically typed product types (clusters), so why shouldn't we have their counterpart? I chose to use a cluster to represent my channel. It contains the direction, state, output mode, frequency, and duty cycle of my channel, and I just ignore the fields if they are meaningless (ex. output mode if the channel's direction is input). What data type(s) would you use? Classes? Enums and Variants? Something Else?

I've had this issue. What worked for me was to continuously read data and buffer it, only timing out if no new data arrived:

I am a fan of statically typed programming. I'm also a fan of message passing to share data between parallel sections of code. Because of this, I wish this idea would get more traction: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wire-Class-To-Case-Selector/idi-p/1457642 And here's why- Suppose I have modules in my application that broadcast messages using a User Events. Any other code module can register for these events and receive the messages. But if these messages can carry different data, I have no pretty, typesafe, way of guaranteeing at compile time that the message carries the appropriate type of data. I could dynamic dispatch on a message Do.vi, passing in a class that inherits from some class the Do.vi calls a dynamic dispatch vi of. For each event registration I have to create another class. Including interfaces in LabVIEW OOP would alleviate this. However, I think the above linked idea provides a cleaner implementation. Another option I have is to attempt to downcast the parent message class to all of its children, and do something once a downcast is successful. This works fine, but if there are a lot of child messages this design pattern becomes large. The linked idea would achieve this in a much more compact, readable way. I'd also like case classes in LabVIEW - classes with no private data or methods, that include child classes beneath them in tree fashion in the project explorer, making it very clear what possible concrete data types can manifest at runtime.

An example of what I'm doing: Given: [1,2,3; 2,2,2; 2,4,4; 3,1,1; 3,3,3] Output: [1,2,3; 2,3,3; 3,2,2] So that the output array has unique values in the first column, the values in the other columns being the average of the rows with the same value in the first column. The code I have right now is this: Is there a simpler way to do this?

An example of what I'm doing: Given: [1,2,3; 2,2,2; 2,4,4; 3,1,1; 3,3,3] Output: [1,2,3; 2,3,3; 3,2,2] So that the output array has unique values in the first column, the values in the other columns being the average of the rows with the same value in the first column. The code I have right now is this: Is there a simpler way to do this?

Couldn't you use two Get LV Class Path.vi's and compare the outputs for equality?