Teaching LabVIEW: Start with programmers or non-programmers?

[DougKU]

This is my first post to Lava and not what I expected to be writing about, but I realize that many of the issues in this thread are actually very important to me. I work at the University of Kansas and have the benefit of the NI Academic Site License. I pushed the purchase of this license through KU because I saw it as a great value while I was at Duke where I started programming in LabVIEW in 2001.

While I was at Duke I was working with control theory so LabVIEW and Simulink were my tools. However, from the beginning I felt that I should get as much of the code to work in an open source development environment, and began a parallel exploration into Linux- a process that I continue to this day. As I have become a better LabVIEW programmer (especially since using LVOOP), I have become more comfortable being a programmer in general (not my background), and less afraid of diving into Python, or using C++.

In my job, I provide software and instrument design support for about 8-12 faculty and their graduate students. I am not in the School of Engineering but instead work with Neuroscientists, and Psychologists (LabVIEW and NI DAQ devices were being used in at least one lab when I arrived). Due to my familiarity with LabVIEW, the responsiveness of NI support, the availability of NI field reps, the need to port applications to multiple platforms, and the need to develop DAQ, control, and embedded systems, I decided early on that I was going to use LabVIEW whenever possible. I decided I would use LabVIEW as a general purpose programming language (because it is).

In general, I think my plan worked well, but for the problem of hiring LabVIEW programmers. Ideally I would hire students (graduate or undergraduate) that know LabVIEW programming. Many mechanical and electrical engineers use LabVIEW, but typically I find that they aren't yet ready to be programmers. Students from computer science generally have little familiarity with LabVIEW. I find it takes almost a year (10-20 hours /week) to get someone programming by themselves in LabVIEW even if they are very good at Java or another language. Of course I also have them learn to use Subversion, and a few other tools at the same time, but I think this is a good estimate. What is a shift register? How do you wire effectively? It takes time. I think LVOOP might speed this up...

So I am trying to make LabVIEW accessible to graduate students that aren't computer scientists or engineers. When the programming involves DAQ or control I am confident that I am correct in choosing LabVIEW. For other applications I am less confident. I am very aware that I am creating a dependency that they may have to take into their future academic or industry positions. When I create an application that they can install and use in the future I am not creating that dependency. However, when I teach them to use LabVIEW, I am ensuring that they will have to pay for a development package in the future to continue to be able to program using LabVIEW. I justify this in part because I think LabVIEW is a very good software to learn programming with, however it is actually a great concern of mine.

For myself I know that I will always have the choice to translate my code to a different development environment or purchase LabVIEW. I have always thought that it might be a good idea to have a license that a group of developers could share based on total time used. Something to allow someone that knows LabVIEW to use it on a limited basis without having to pay for an entire seat. Actually, this probably exists?

[ShaunR]

.....I find it takes almost a year (10-20 hours /week) to get someoneprogramming by themselves in LabVIEW even if they are very good at Javaor another language.....

That's where your problem lies. I find it takes 1-2 months for a non-programmer that is eager to learn. You spend 6 months listening to text programmers whining about how they used to do it.

Edited October 27, 2009 by ShaunR

[asbo]

That's where your problem lies. I find it takes 1-2 months for a non-programmer that is eager to learn. You spend 6 months listening to text programmers whining about how they used to do it.

I thought the 1y time frame was kind of large as well. I'm a CE undergrad and I have perhaps 9mo of experience with LabVIEW through my co-op job; I have a lot of other programming background, but even at three months I considered myself to be pretty well established in LabVIEW. I think it's much more intuitive for people with little programming experience, particularly engineers. If it's taking a year to get your guys up to speed, they're only using it a few times a month or you're just not pushing hard enough.

[DougKU]

That's where your problem lies. I find it takes 1-2 months for a non-programmer that is eager to learn. You spend 6 months listening to text programmers whining about how they used to do it.

I am about to try the experiment. I will teach non-programmers and see what happens. I am pretty sure it will work out well, certainly for the ones that use NI hardware.

The Java programmer that worked with me was excellent and didn't whine. She really liked the event structure and case structure, and was happy to learn a lot about functional globals. However, it takes more than 1 o r 2 months at 10 hours a week to learn any programming language. I wish that I had been able to use LVOOP at the time because she thought in classes and interfaces. I really think that LVOOP will simplify learning LabVIEW.

[Gary Rubin]

I really think that LVOOP will simplify learning LabVIEW.

As a non-OO programmer (LV or otherwise), I think this is only true when trying to teach programmers. IMHO, if you try to teach non-programmers OOP, you're adding an extra layer of complexity that they have to learn. To me, understanding what a For loop does is much more intuitive than trying to understand classes, inheritance, etc.

[DougKU]

As a non-OO programmer (LV or otherwise), I think this is only true when trying to teach programmers. IMHO, if you try to teach non-programmers OOP, you're adding an extra layer of complexity that they have to learn. To me, understanding what a For loop does is much more intuitive than trying to understand classes, inheritance, etc.

I think I am hijacking this thread. I am also confusing the issue. I am pretty sure that OOP of some form in LabVIEW is more attractive to an OOP programmer from another language than no OOP in LabVIEW, but I too am uncertain about using LVOOP with beginners. I am a very poor OOP programmer that is really enjoying learning. I think LVOOP is a tool that I can use to simplify coding for others. I will try the experiment.

I think that LabVIEW objects can be used without adding the complexity you talk about. I also point out that non-OO programmers are usually very comfortable using C++ and .Net classes in LabVIEW. You don't have to know how to create a class to use a class.

But I am sure there is a topic about this elsewhere.

[ShaunR]

I think I am hijacking this thread.

I think it was dead anyway

I am also confusing the issue. I am pretty sure that OOP of some form in LabVIEW is more attractive to an OOP programmer from another language than no OOP in LabVIEW, but I too am uncertain about using LVOOP with beginners. I am a very poor OOP programmer that is really enjoying learning. I think LVOOP is a tool that I can use to simplify coding for others. I will try the experiment.

Indeed. I believe LV OOP was invented to give C++ programmers a warm fuzzy feeling and entice them to use Labview.

The advantage for beginners that Labview brings is that they are able think in a sequential manner to start with and lay down code in the same order as their thought process when analysing problems. This means that they learn the environment a capabilities of LV quickly whilst still producing tangible results (i.e code that works) without being encumbered by how it works. Once they get used to using LV as a symbolic "scratchpad", they quickly move on to more complex subjects as a natural progression. They also don't have to worry about pointers, memory management and all the other obnoxious stuff that makes other languages so flexible so their time is spent on the problem rather than managing code.

However, if you sit them down and explain that you have to spend 3 weeks writing code with (from their point of view) no discernible benefit apart from being able to make other code work. They quickly get confused, frustrated and bored. If they can sit down and in 10 minutes turn a light on and off, or make the computer beep every time they walk past it.....then you have an audience

I think that LabVIEW objects can be used without adding the complexity you talk about. I also point out that non-OO programmers are usually very comfortable using C++ and .Net classes in LabVIEW. You don't have to know how to create a class to use a class.

But I am sure there is a topic about this elsewhere.

This is true. But when it doesn't give you what you were expecting, then you do!

Just because a program contains objects (C++ .net or anything) doesn't mean it is an object orientated program. Non OOP programmers view these objects as "functions" to extract whatever data they need. They (I? ) mainly view them as a container with specialised features not dissimilar to a vi with a case statement that enables selection of a series of sub vis. This view is far less abstract and easier to digest for virgin programmers.

[Gary Rubin]

They also don't have to worry about pointers, memory management and all the other obnoxious stuff...

Including parentheses and semicolons

ShaunR, I think the rest of your post was well put too.

I'm looking forward to the results of the experiment of teaching non-programmers LabVIEW.

[jcarmody]

I'm looking forward to the results of the experiment of teaching non-programmers LabVIEW.

I'm teaching it to my kids (ages 14, 10 & 9). It's going well; we're using "LabVIEW For Everyone". The oldest said he "gets it" better than when we began Logo and Python.

[Gary Rubin]

I'm teaching it to my kids (ages 14, 10 & 9). It's going well; we're using "LabVIEW For Everyone". The oldest said he "gets it" better than when we began Logo and Python.

jcarmody, did you split this conversation to the new topic? Regardless, did you respond to the old (License Frustrations) topic, or this new one?

[hooovahh]

Yeah LabVIEW was my first "real" language, just played around with PLC. I think it helped alot when going to other languages. When I started learning other languages I already knew the concepts of programming, and how to make decent code from a how it should be done. Then the only thing I had to do is learn the syntax.

Learning from LabVIEW is very beneficial, I know that when I was in Java and wanted to get some thing done, I remembered how to do it in LabVIEW visually. This is something missing from other languages, I can visually see how my code should look, and where data should go to accomplish my goals. This is very useful in remembering how to get the task done.

[jcarmody]

jcarmody, did you split this conversation to the new topic? Regardless, did you respond to the old (License Frustrations) topic, or this new one?

I responded to the old one.

[Gary Rubin]

I responded to the old one.

ok, that would explain why my notification of your update pointed to the old one. I thought maybe it was a bug with notifications and split topics.

[crelf]

jcarmody, did you split this conversation to the new topic?

I split it.

Regardless, did you respond to the old (License Frustrations) topic, or this new one?

All posts we moved across to the new thread.

[PaulG.]

That's where your problem lies ... You spend 6 months listening to text programmers whining about how they used to do it.

What is really funny are the real "old timers" who have been programming in C for 30 years who attempt to learn LV. Their expressions are priceless:

[jcarmody]

[...] who have been programming in C for 30 years [...]

I'm working with a long-time text-programming Test Engineer who is being shoehorned into LabVIEW. I expected him to kick and scream through the process, but he's surprisingly open. He expresses an equal amount of "that's neat" and "that's easier in text". There has only been one case where he didn't believe me when I said he was doing something wrong.

[ShaunR]

All posts we moved across to the new thread.

Except poor ol' Hooovahhs

[hooovahh]

Except poor ol' Hooovahhs

Eh it happens, I'm just glad the split went so well as I too was wondering what it would do to RSS. Maybe we should now split this, into a conversation about splitting threads? And splitting threads that have been split.

[ShaunR]

Including parentheses and semicolons

ShaunR, I think the rest of your post was well put too.

Where's my point then?

[crelf]

Except poor ol' Hooovahhs

Yeah - that was a race condition. I just moved it.

Maybe we should now split this, into a conversation about splitting threads? And splitting threads that have been split.

Don't tempt me.

[Gary Rubin]

Yeah - that was a race condition. I just moved it.

Maybe you two need semaphores. Or at least some error wires to force the correct order.

[DougKU]

I think it was dead anyway

Indeed. I believe LV OOP was invented to give C++ programmers a warm fuzzy feeling and entice them to use Labview.

The advantage for beginners that Labview brings is that they are able think in a sequential manner to start with and lay down code in the same order as their thought process when analysing problems. This means that they learn the environment a capabilities of LV quickly whilst still producing tangible results (i.e code that works) without being encumbered by how it works. Once they get used to using LV as a symbolic "scratchpad", they quickly move on to more complex subjects as a natural progression. They also don't have to worry about pointers, memory management and all the other obnoxious stuff that makes other languages so flexible so their time is spent on the problem rather than managing code.

However, if you sit them down and explain that you have to spend 3 weeks writing code with (from their point of view) no discernible benefit apart from being able to make other code work. They quickly get confused, frustrated and bored. If they can sit down and in 10 minutes turn a light on and off, or make the computer beep every time they walk past it.....then you have an audience

This is true. But when it doesn't give you what you were expecting, then you do!

Just because a program contains objects (C++ .net or anything) doesn't mean it is an object orientated program. Non OOP programmers view these objects as "functions" to extract whatever data they need. They (I? ) mainly view them as a container with specialised features not dissimilar to a vi with a case statement that enables selection of a series of sub vis. This view is far less abstract and easier to digest for virgin programmers.

I have been thinking about how I will use LVOOP with beginning programmers that will work with me. I will use LVOOP and not any other OOP because LVOOP is by value, comes as part of LabVIEW and is not an add on. Then I will introduce the LabVIEW class. This leads very naturally to using the LabVIEW project and version control. Anyone that works with me needs to be able to use Subversion and the project so I will introduce them on the first day. I will provide a well structured project that they can check out and we will create a child class. Then I will spend time over the next months teaching the LabVIEW that is necessary to create the members of the child class. This will be the same non LVOOP with the following differences (there are probably more that I am not yet thinking of): instead of type definitions we will use the Class ctl private data, I will use Xcontrols early on, I will avoid functional globals. We will use libraries but the important features of libraries will be learned through the class which is a special library.

I expect that after a year no one will be able to build a program on their own, but they will be able to build a class including the Xcontrol. They will see how the class fits into the class hierarchy that I provide, and they will be able to see and understand many of the decisions behind the higher level design patterns that I am using. They will effectively use the project and version control system, and will have an understanding of using unit testing. I will be creating the test code for their classes, and providing feedback after nightly builds of all software.

My goal is to get programmers to reduce my workload by producing quality, maintainable, tested code that I can use. I expect that their outputs will be child classes and Xcontrols. However, I agree with you about needing to make things beep! To do this I will be providing the project that can already has a great deal of interesting functionality. The beginning programmers will add the specific (or at least parts of the specific) functionality to make the project hum.

Thoughts?

[Gary Rubin]

I expect that after a year no one will be able to build a program on their own

I don't know how important OOP and XControls are to your overall project, but that statement above bothers me a little. I don't see any reason why an intelligent, motivated person couldn't be writing their own stand-alone programs after a year of LabVIEW, even if it is once or twice a week. I will concede, though, that it all depends on the nature of the programs; mine are typically short, small-scope utilities for number crunching and display.

Are we still talking about the non-programmers? And by non-programmers, are we talking about science/engineering students who just haven't had a formal programming class? Or are we talking about humanities majors?

What is the purpose of this? To teach them LabVIEW? To teach them to program with LabVIEW as the chosen language? To do the subject matter work, with the programming just a tool? To have them contributing to your long-term, on-going project?

If it's the 1st two (and maybe the third), then I believe your LVOOP approach is teaching them to run before they've learned to walk.

I would be concerned about students (especially non-programmers) losing interest somewhat if they feel like they are getting lost in the minutiae, or don't see the end product of their work.

[ShaunR]

I'm with Gary on this one.

Another aspect is that not everyone "gets" OOP. There are many coders that use OOP capable languages that never write a bit of OOP in their entire career. Perhaps a better approach might be to start them on normal LV with the advantages of all the existing examples and training resources and filter out those that just don't have the head for it, rather than assume that everyone can and will learn.

[Gary Rubin]

I'm with Gary on this one.

To paraphrase yourself: "Where's the rep point?"