LabVIEW
Question about Global Variables and String Outputs
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@sidnchan wrote:
It won't let me connect the global variable to a string indicator because the variable itself is an indicator type.
Right click the global instance, select 'Change to Read' to change it to read.
Globals are not control or indicator, they are globals. You can read and write to any global.
Globals are not the solution here though (they never are). However, we need code to recommend a good solution.
Globals have their place. They're not inherently evil, but they do have very specific usage cases. (This is not one of them.)
(Resisting the urge to comment on the place globals have 🤣. Almost succeeded.)
I didn't say they're evil, just that they are never the solution 😉.
Globals can appear convenient, but there are always better solutions. Sometimes the alternatives are only marginally better, but usually by far. The alternatives are often a lot more work, and the downsides of globals usually come out when sizing up which might never happen. So, not for me, but YMMV.
That's an old joke, and it is a joke. A guru wouldn't name a global (nor indicator) 'Boolean'.
@billko wrote:I don't about "by far"; most of them seem pretty technical and specific to certain use cases, but for what globals are made for - that is, holding write once/read many data - they work just fine.
That's not the problem. Of course they do what they are supposed to do.
The problem is that in using them you potentially couple code more tightly, bypass dataflow and often prevent opportunities for using your code more then once in the same code (which isn't a problem if the global is truly a global).
In functional programming, implicit input (vs explicit inputs) is an absolute no-no, as it makes testing a lot more difficult. I'd have to look up the wording, but the argumentation against implicit inputs are pretty compelling, and not just theoretical. Testing code that only depends on by value inputs is a lot easier then code that has 'state' (globals, references, shift resisters, locals, etc.).
Globals fit a 'pragmatic' programming style, and they do indeed do as advertised. I'm all for pragmatic programming, but globals are to far south of that spectrum for me. They just don't solve enough of my problems, compared to the problems they cause.
But if they work for you, great! We all work under different circumstances...
I will do a deep dive into what you said so I can potentially become a better developer.
I haven't read it completely yet, but Grokking Simplicity - A book on Functional Programming explains functional programming really well.
The teachings of functional programming apply to OO as well (it's complementary) and most of it can be used in any language. Both is explained in the 1st chapter of the book.
You can find it online (the preview has quite a bit), but if you want to read it, nothing beats a physical book, although this one is a bit pricy.
For now, my biggest take away is that I understand much better why code is sometimes much harder to debug then other code.
Search LabVIEW like a graph! 
It's funny how this turned into a long discussion about global variables even though the solution to the original problem has nothing to do with them. 😄
@altenbach wrote:
It's funny how this turned into a long discussion about global variables even though the solution to the original problem has nothing to do with them. 😄
I never learn that I should never reply with a non-solution post because I always drag a topic off-course. 😞
@billko wrote:
@altenbach wrote:
It's funny how this turned into a long discussion about global variables even though the solution to the original problem has nothing to do with them. 😄
I never learn that I should never reply with a non-solution post because I always drag a topic off-course. 😞
This happens a lot more without feedback from OP...
I still have no idea if the answer is "concatenate string" or "architecture", or anything left, right, north, colder, above or in between.
