06-09-2014 10:48 AM
Well, what I was saying is that if you offer a quick and dirty solution, make sure they know it is a quick and dirty solution.
06-09-2014 10:51 AM - edited 06-09-2014 10:55 AM
@billko wrote:
Well, what I was saying is that if you offer a quick and dirty solution, make sure they know it is a quick and dirty solution.
That is a good point. Due to writing quickly I could see how "The easiest way" was a poor choice of wording on my part. "Easy" does not always correlate to "quick and dirty". But I feel like @DFGray already cleared this up quite well in his/her post, which is why I acknowledged it in my next reply and gave Kudos to make ensure the OP got the message. 😄
And I believe he/she did by stating:"That will do for a newbie i think"
06-09-2014 11:00 AM - edited 06-09-2014 11:01 AM
@MrHappyAsthma wrote:
@billko wrote:
Well, what I was saying is that if you offer a quick and dirty solution, make sure they know it is a quick and dirty solution.
That is a good point. Due to writing quickly I could see how "The easiest way" was a poor choice of wording on my part. "Easy" does not always correlate to "quick and dirty". But I feel like @DFGray already cleared this up quite well in his/her post, which is why I acknowledged it in my next reply and gave Kudos to make ensure the OP got the message. 😄
And I believe he/she did by stating:"That will do for a newbie i think"
If he didn't speak up, it was likely that you started another newb down the path to the dark side.
But you got me seriously thinking about this because your point was VERY VALID. How do we make it easy for someone inexperienced with LabVIEW to make something that just works?
This was something I've always pondered every time someone new to LabVIEW posted to the forum.
06-09-2014 11:18 AM - edited 06-09-2014 11:19 AM
@billko wrote:
If he didn't speak up, it was likely that you started another newb down the path to the dark side.
But you got me seriously thinking about this because your point was VERY VALID. How do we make it easy for someone inexperienced with LabVIEW to make something that just works?
This was something I've always pondered every time someone new to LabVIEW posted to the forum.
I would have eventually asked him about the project requirements to address the issues with my solution, but any mention of Local Variables originally came in edits/posts after he responded with a picture wiring together two while loops. I figured if the user didn't understand dataflow entirely, they would have trouble with more advanced architectures and data structures. And then before I even got a chance to get to this step (which I agree, I should have immediately made clear), the flaws of Local Variables were pointed out for me in another reply.
Your wording in your last reply was really good (which is why I quoted you above). It is, indeed, quite tough to know where to start the teaching the user and when to give them a "working" solution to their problem. As I did (and often do), I always recommend new users spend more time actually learning LabVIEW before jumping into a project, but often users want a solution without the necessary ground work of learning the constucts that will lead to the most appropriate solution. As a result, I start with a simple approach with the least complex elements as a starting point. Once the user grasps this, I can try to show them a more elegant way to solve their problem that avoids the issues with the fastest "plug-and-play" approach, if necessary. But this is probably a flaw on my end for taking a bad approach answering posts by introducing "bad" habits first, as a way to quickly answer their question.
06-09-2014 11:28 AM
I don't know if I'd call it a "flaw." There are just so many factors that would influence my decision on how to approach the issue. Especially this issue here. How can the user grasp the concept of queues when they are struggling with dataflow?
I have more questions than answers at this point.