Talk:LabVIEW

message: Under the "Copyright" section, there is an additional paragraph that discusses criticisms of the language.   First off, I don't think this applies to "copyright" so it should, probably, get it's own section if it's going to stay.  However, I don't think this really belongs in the article anyway.  The only reference I can see there is an article from 2006.  The paragraph itself lists a couple of criticisms and then, immediately, points out that they no longer apply to the language as of the 8.x versions (long since released by now).  Should there even be a criticisms section if the only criticisms listed were made irrelevant years ago?  I'm hesitant to just remove the paragraph since I know that criticisms about programming languages can be heated discussions and it'd be better if there was some consensus first. Colecoman1982 (talk) 20:57, 6 August 2012 (UTC)
thread_title:  Copyright/Criticisms Section 

message: This article starts out stating "Laboratory Instrumentation Engineering Workbench" but the book "Learning with LabVIEW 8" says it means "Laboratory Instrument Engineering Workbench". Small difference, but a difference nonetheless.
Well, you left out the "V."  Corporate documentation seems to use both definitions at times..  If memory serves, however, LabVIEW 1 actually said "Instrumentation" when the program started.  Not 100% sure though.  In any case, as NI attempts to redefine LabVIEW as a general-purpose programming environment, I suspect we'll see the actual definition used less and less.  -Seyon
The acronym originally stood for Laboratory Virtual Instrumentation Engineering Workbench since LabVIEW is used to create virtual instruments (VIs). -shogg  —Preceding unsigned comment added by 99.54.127.246 (talk) 15:22, 13 August 2010 (UTC)
thread_title:  What does the LabVIEW acronym really mean? 

message: I've created this userbox for Wikipedians who programme using LabVIEW:
Just put  on your user page! - Gobeirne 08:12, 26 January 2006 (UTC)
thread_title:  Userbox 

message: The owner of the company that produces this software created and edits this article.  See http://www.webpronews.com/topnews/topnews/wpn-60-20060301SEMNYCommunitiesWikipediaTagging.html . Superm401 - Talk 02:34, 2 March 2006 (UTC)
replies: text: The article says that Jeff Watts, someone involved in LabVIEW, started the article, but has since let it be.  It was certainly created with "marketing intent", and would have been deleted if the product did not have a userbase of a notable size, but at least National Instruments has let it grow organically since.  Our spamming problem would be a lot less if all companies could act the same -- start a profile or product article with facts (not marketing-speak), let the community edit, step in on the talk page if they see any errors creeping in, provide documentation of information they'd like to see included....hopefully the corporate public will start to "get it" in the next few years.  — Catherine\talk 17:05, 17 March 2006 (UTC)
thread_title:  Autobiographical Editing/Using Wikipedia for Marketing 

message: The person who added this text does NOT work for National Instruments so the statement: "The owner of the company that produces this software created and edits this article." is pure fiction. If you visit the mentioned link it is plain to see that it is a clear marketing tactic akin to spamming Wikipedia.—Preceding unsigned comment added by Michael Aivaliotis (talk • contribs) 
:The article says that Jeff Watts, someone involved in LabVIEW, started the article, but has since let it be.  It was certainly created with "marketing intent", and would have been deleted if the product did not have a userbase of a notable size, but at least National Instruments has let it grow organically since.  Our spamming problem would be a lot less if all companies could act the same -- start a profile or product article with facts (not marketing-speak), let the community edit, step in on the talk page if they see any errors creeping in, provide documentation of information they'd like to see included....hopefully the corporate public will start to "get it" in the next few years.  — Catherine\talk 17:05, 17 March 2006 (UTC)
thread_title:  I disagree with the above entry 

message: Doesn't it seem incorrect to claim that "data-flow...completely defines the execution sequence"?  Perhaps it can be completely defined, but usually it isn't. Justin212k 21:26, 28 February 2007 (UTC)
thread_title:  Dataflow programming 

message: Labview is a great product but several of the recent edits of the criticism have seriously obscured some of the legitimate problems. For example, there are concerns regarding the portability and longevity of code. The text that described in detail some of the new implications of software activation requirements was replaced with “could lead to future problems” and “it is not completely clear what would happen to the LabVIEW development environment if National Instruments were to go out of business.”
The earlier text (around Feb 26, 2006) pointed out precisely what the concerns were given the facts as they stand today. Namely, that without a company to activate the product there would be no way to install the software on new hardware and no way to access old code or certain types of archived data. This is an informative point and an important consideration for Medical and Scientific researchers that might be using Wikipedia to look into LabVIEW as a potential platform. The implications are NOT speculation; they are a direct consequence of the new activation policy. The activation policy can be determined by examining National Instruments own FAQ which clearly outlines that National Instruments must to be contacted to install the software (now referenced). Of course, National Instruments might claim to have contingency plans but whether these exist or could be implemented in practice is speculation. To simply hide these archiving concerns behind the fuzzy “could lead to future problems” is not helpful or specific enough.
BTW, this archiving and access issue and is not just a future problem and is probably more serious than described. Look through Labview news groups and forums and you’ll find plenty of folks who are trying to access code and/or datalog files (which are often the choice format) but can’t because their version is incompatible (either too old or too new for conversion).
=== National Instruments does have a "contingency plan" ===
I happen to know that National Instruments does have such a "contingency plan" already implemented and ready to deploy if it were ever needed. It would enable one to activate their license file locally without contacting National Instruments. Because of this, and the fact that it's not specific to LabVIEW but rather all products with product activation (as already discussed), I think this part of the Criticism section should be removed or rewritten. — kentyman 18:25, 4 August 2006 (UTC)
replies: text: *I am on the licensing team at National Instruments, and I personally worked on the aforementioned tools. — kentyman 20:15, 16 August 2006 (UTC)
replies: text: *I'm not doubting that you're correct, I'm just asking if this has been published in any reliable source, so that adding this point would meet the verifiability requirements. eaolson 21:52, 17 August 2006 (UTC)
replies: text: *As far as I know, it has not been published in such a source. I will look into it. — kentyman 20:53, 21 August 2006 (UTC)
replies: text: *This is irrelevant, because National Instruments must provide access to the software by law. To protect licensees of licenses of intellectual property, Congress enacted the Intellectual Property Bankruptcy Protection Act of 1988 to add Section 365(n) to the U.S. Bankruptcy Code.  Section 365(n) protects licensees rights "as such rights existed immediately before the case commenced."  Therefore, the filing of a bankruptcy by National Instruments would not affect the rights of licensees to use the software. --Marni1s 17:29, 15 November 2006 (UTC)
replies: text: * Sorry, this legalalistic analysis is off, see below...
==== Corporate contingencies and legalistic augments miss the point about problems w/ Labview activation ====
Both the legalalistic commentary and purported contiginies miss the point and real concerns with Labview activation schemes. National instruments may seem and actually be reliable but larger companies have disappeared ((E.g. Enron had over 20,000 employees and claimed revenues of 111 billion, which dwarfs National Instruments). Who exactly is the user going to contact for activation or sue if National Instruments ceases to exist? Would the bankruptcy trustees or US government run a Labview activation support line? None of this even begins to consider the problems for users outside the US. Would they have legal protection and ongoing technical support? What if their government restricts outside contact? Also, what if the lines are down? International and national emergencies can easily result in communication problems. 
The point is that advanced users upgrade hardware regularly and in secure scientific or medical programming you need to be assured that you can install all software, access all data and all code anytime, anywhere without relying on corporate promises, outside entities, bankruptcy trustees or going to court. The operational default has to be ACCESS not potential legal recourse. November 16, 2006.
—Preceding unsigned comment added by 74.12.163.45 (talk • contribs) 
I think that it's obvious that even if kentyman's solution is not verifiable in a published form, the purported problem itself is not verifiable in a published form.
=== Some of the shortcomings aren't specific to LabVIEW ===
The concerns raised in the post apply to all activated software, including office productivity tools, used by researchers and engineers. To make sure researches are correctly evaluating all their software would it be more appropriate to update the definition of activation to outline the pro's and con's and refernece that from all activated software entires? The other comment regarding "access code/datalog files": at present there is a migration path for LabVIEW code from it's first version, 2.0, to the latest version, 8.0: http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/429e45271cfd683786256d87006b1eef?OpenDocument
Would it be possible for you to reference some of these posts to better determine the specifics?
==== Specific problems with LabVIEW activation, migration and file formats ==== 
1) REGARDING ACTIVATION, sure product activation is a major problem that applies to other products as well (unfortunately the wikipedia entry on "product activation" is fairly weak) BUT the issue with Labview is MUCH more serious than most other products. Unlike Labview, most office productivity packages and commercial programming tools have many Free Software and Open Source alternatives, so there is always an alternate way to get at your code or data. This is not true of Labview. If a few years from now you need to get to old code and data that requires reinstalling the software you'll have to hope that National instrument exists and that it's still handing out activation codes for old products. Scientific and medical settings often require absolute confidentiality and data integrity, these are seriously and unacceptably compromised by an activation scheme. The fact that national instruments now requires all users to contact them and provide personal data in order to use the software is clearly specified in the already referenced national instruments documentation: "To complete the activation process, the user must provide the end user name, organization, and serial number"
(http://digital.ni.com/public.nsf/websearch/3F93009F5EEE114B86256D6C0051777F?OpenDocument).
2) As for the MIGRATION PROCESS, it is dubious at best. First of all, the process is mostly unidirectional. For example, version 8.0 will load version 7.0 and 6.0 code, but cannot save back to these formats (you can only go back one minor version at a time). The only way to save back to older versions is to find multiple installs (8.0, 7.1,7.0, etc) and progressively save in older versions (see http://digital.ni.com/public.nsf/websearch/C18E6D5FFA8F0D85862568CC0067274F?OpenDocument) As someone who has been dealing with these migrations since Labview 3, I can tell you it gets nasty, especially if you're working in a mixed environment with colleagues working on various versions or mission critical systems that can't be immediately upgraded. 
Very few other programming languages or office productivity packages still have such clumsy file compatibility limitations so common in the 90s. But if code compatibility was bad enough the data formats issue is even worse! If you update datalog data in a new version you often can no longer access it in your old code NOR can you save it back to the old format. Again, these limitations are spelled out in the sugar-coded national instruments documentation; check the links on the page you list. Also see the upgrade notes for version 8, 7.1 and 7.0 (e.g. http://www.ni.com/pdf/manuals/371780a.pdf). 
3) In general, the DATALOG STORAGE integrity is poorly thought out. Although datalog files are often the only practical solution for saving complex data compactly, if you don't know the structure of your saved data you can't load it! I.e. if you lose your program or even make a minor change to a data cluster structure you have no way to open old files without successfully guessing the record structure. Labview engineers have somewhat ridiculously tried to claim that not being able to determine record structure is a security feature and that "Having a way of knowing what the datalog type is directly from the file would defeat the purpose." See "Retrieving datalog files" thread in comp.lang.labview. (http://groups.google.ca/group/comp.lang.labview/browse_thread/thread/c49b974496137855/399c38d3b58bfb4e?lnk=st&q=Retrieving+datalog+files&rnum=1&hl=en#399c38d3b58bfb4e).
On the whole, I think the article's criticism section is fairly forgiving and doesn't get across just how serious these problems can be. Labview is an amazing language, but all these proprietary format and activation shenanigans really raise doubts about it being appropriate for secure scientific and data archiving purposes.
----
Datalog formats are very easy to use but have never been the recommended way to save your sensitive data. Yes the LabVIEW programming manual explains how to create and use them and I would expect it to do so since it's a possibility of it, but at the same time it states the version dependency. If you have critical data that needs to be accessible over 20 years then datalog is not for you (and effectively any other binary format neither).
The problem is that here someone requires a compact (or binary format) and at the same time openly accessible from any environment. If that is your concern do your own format header description and then stream the data in binary format to a binary stream file. This is similar to a datalog file in terms of compactness but avoids the version specific datalog header. The binary data itself is streamed in that way directly to disk in the format as outlined in the Application Note about Data Types. It is not as trivial as datalog files since you need to maintain your own header (recommended to do) and if you want to stream many data you also will need to do some record keeping somehow to easily be able to index data in the file. But the format is fully defined by you and can then also be read in other applications such as C programs in binary stream format.
While I agree that Activation might have certain long term risks I find it very easy to criticize certain aspects of a feature of a software because you want to use it for something it was never created for. And there exist fairly easy solutions for the problem you say you want to solve.
And since you talk here about future security mostly, the migration in these terms is much more important towards newer versions than the opposite. If you create a program now in a certain LabVIEW version and want to be able to recreate it over 10 years then it is not likely that you will then use an older version of LabVIEW than what you used today. So for that the limited ability to safe to older versions is never a problem. It is sometimes inconvenient during development if you work in different versions at the same time but not for the ability to guarantee access to your code in the nearer of longer future.
RolfK (talk) 20:40, 30 March 2008 (UTC)
thread_title:  We need to be direct and truthful about LabVIEW shortcomings 

message: The concerns raised in the post apply to all activated software, including office productivity tools, used by researchers and engineers. To make sure researches are correctly evaluating all their software would it be more appropriate to update the definition of activation to outline the pro's and con's and refernece that from all activated software entires? The other comment regarding "access code/datalog files": at present there is a migration path for LabVIEW code from it's first version, 2.0, to the latest version, 8.0: http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/429e45271cfd683786256d87006b1eef?OpenDocument
Would it be possible for you to reference some of these posts to better determine the specifics?
==== Specific problems with LabVIEW activation, migration and file formats ==== 
1) REGARDING ACTIVATION, sure product activation is a major problem that applies to other products as well (unfortunately the wikipedia entry on "product activation" is fairly weak) BUT the issue with Labview is MUCH more serious than most other products. Unlike Labview, most office productivity packages and commercial programming tools have many Free Software and Open Source alternatives, so there is always an alternate way to get at your code or data. This is not true of Labview. If a few years from now you need to get to old code and data that requires reinstalling the software you'll have to hope that National instrument exists and that it's still handing out activation codes for old products. Scientific and medical settings often require absolute confidentiality and data integrity, these are seriously and unacceptably compromised by an activation scheme. The fact that national instruments now requires all users to contact them and provide personal data in order to use the software is clearly specified in the already referenced national instruments documentation: "To complete the activation process, the user must provide the end user name, organization, and serial number"
(http://digital.ni.com/public.nsf/websearch/3F93009F5EEE114B86256D6C0051777F?OpenDocument).
2) As for the MIGRATION PROCESS, it is dubious at best. First of all, the process is mostly unidirectional. For example, version 8.0 will load version 7.0 and 6.0 code, but cannot save back to these formats (you can only go back one minor version at a time). The only way to save back to older versions is to find multiple installs (8.0, 7.1,7.0, etc) and progressively save in older versions (see http://digital.ni.com/public.nsf/websearch/C18E6D5FFA8F0D85862568CC0067274F?OpenDocument) As someone who has been dealing with these migrations since Labview 3, I can tell you it gets nasty, especially if you're working in a mixed environment with colleagues working on various versions or mission critical systems that can't be immediately upgraded. 
Very few other programming languages or office productivity packages still have such clumsy file compatibility limitations so common in the 90s. But if code compatibility was bad enough the data formats issue is even worse! If you update datalog data in a new version you often can no longer access it in your old code NOR can you save it back to the old format. Again, these limitations are spelled out in the sugar-coded national instruments documentation; check the links on the page you list. Also see the upgrade notes for version 8, 7.1 and 7.0 (e.g. http://www.ni.com/pdf/manuals/371780a.pdf). 
3) In general, the DATALOG STORAGE integrity is poorly thought out. Although datalog files are often the only practical solution for saving complex data compactly, if you don't know the structure of your saved data you can't load it! I.e. if you lose your program or even make a minor change to a data cluster structure you have no way to open old files without successfully guessing the record structure. Labview engineers have somewhat ridiculously tried to claim that not being able to determine record structure is a security feature and that "Having a way of knowing what the datalog type is directly from the file would defeat the purpose." See "Retrieving datalog files" thread in comp.lang.labview. (http://groups.google.ca/group/comp.lang.labview/browse_thread/thread/c49b974496137855/399c38d3b58bfb4e?lnk=st&q=Retrieving+datalog+files&rnum=1&hl=en#399c38d3b58bfb4e).
On the whole, I think the article's criticism section is fairly forgiving and doesn't get across just how serious these problems can be. Labview is an amazing language, but all these proprietary format and activation shenanigans really raise doubts about it being appropriate for secure scientific and data archiving purposes.
----
Datalog formats are very easy to use but have never been the recommended way to save your sensitive data. Yes the LabVIEW programming manual explains how to create and use them and I would expect it to do so since it's a possibility of it, but at the same time it states the version dependency. If you have critical data that needs to be accessible over 20 years then datalog is not for you (and effectively any other binary format neither).
The problem is that here someone requires a compact (or binary format) and at the same time openly accessible from any environment. If that is your concern do your own format header description and then stream the data in binary format to a binary stream file. This is similar to a datalog file in terms of compactness but avoids the version specific datalog header. The binary data itself is streamed in that way directly to disk in the format as outlined in the Application Note about Data Types. It is not as trivial as datalog files since you need to maintain your own header (recommended to do) and if you want to stream many data you also will need to do some record keeping somehow to easily be able to index data in the file. But the format is fully defined by you and can then also be read in other applications such as C programs in binary stream format.
While I agree that Activation might have certain long term risks I find it very easy to criticize certain aspects of a feature of a software because you want to use it for something it was never created for. And there exist fairly easy solutions for the problem you say you want to solve.
And since you talk here about future security mostly, the migration in these terms is much more important towards newer versions than the opposite. If you create a program now in a certain LabVIEW version and want to be able to recreate it over 10 years then it is not likely that you will then use an older version of LabVIEW than what you used today. So for that the limited ability to safe to older versions is never a problem. It is sometimes inconvenient during development if you work in different versions at the same time but not for the ability to guarantee access to your code in the nearer of longer future.
RolfK (talk) 20:40, 30 March 2008 (UTC)
thread_title:  Some of the shortcomings aren't specific to LabVIEW 

message: 1) REGARDING ACTIVATION, sure product activation is a major problem that applies to other products as well (unfortunately the wikipedia entry on "product activation" is fairly weak) BUT the issue with Labview is MUCH more serious than most other products. Unlike Labview, most office productivity packages and commercial programming tools have many Free Software and Open Source alternatives, so there is always an alternate way to get at your code or data. This is not true of Labview. If a few years from now you need to get to old code and data that requires reinstalling the software you'll have to hope that National instrument exists and that it's still handing out activation codes for old products. Scientific and medical settings often require absolute confidentiality and data integrity, these are seriously and unacceptably compromised by an activation scheme. The fact that national instruments now requires all users to contact them and provide personal data in order to use the software is clearly specified in the already referenced national instruments documentation: "To complete the activation process, the user must provide the end user name, organization, and serial number"
(http://digital.ni.com/public.nsf/websearch/3F93009F5EEE114B86256D6C0051777F?OpenDocument).
2) As for the MIGRATION PROCESS, it is dubious at best. First of all, the process is mostly unidirectional. For example, version 8.0 will load version 7.0 and 6.0 code, but cannot save back to these formats (you can only go back one minor version at a time). The only way to save back to older versions is to find multiple installs (8.0, 7.1,7.0, etc) and progressively save in older versions (see http://digital.ni.com/public.nsf/websearch/C18E6D5FFA8F0D85862568CC0067274F?OpenDocument) As someone who has been dealing with these migrations since Labview 3, I can tell you it gets nasty, especially if you're working in a mixed environment with colleagues working on various versions or mission critical systems that can't be immediately upgraded. 
Very few other programming languages or office productivity packages still have such clumsy file compatibility limitations so common in the 90s. But if code compatibility was bad enough the data formats issue is even worse! If you update datalog data in a new version you often can no longer access it in your old code NOR can you save it back to the old format. Again, these limitations are spelled out in the sugar-coded national instruments documentation; check the links on the page you list. Also see the upgrade notes for version 8, 7.1 and 7.0 (e.g. http://www.ni.com/pdf/manuals/371780a.pdf). 
3) In general, the DATALOG STORAGE integrity is poorly thought out. Although datalog files are often the only practical solution for saving complex data compactly, if you don't know the structure of your saved data you can't load it! I.e. if you lose your program or even make a minor change to a data cluster structure you have no way to open old files without successfully guessing the record structure. Labview engineers have somewhat ridiculously tried to claim that not being able to determine record structure is a security feature and that "Having a way of knowing what the datalog type is directly from the file would defeat the purpose." See "Retrieving datalog files" thread in comp.lang.labview. (http://groups.google.ca/group/comp.lang.labview/browse_thread/thread/c49b974496137855/399c38d3b58bfb4e?lnk=st&q=Retrieving+datalog+files&rnum=1&hl=en#399c38d3b58bfb4e).
On the whole, I think the article's criticism section is fairly forgiving and doesn't get across just how serious these problems can be. Labview is an amazing language, but all these proprietary format and activation shenanigans really raise doubts about it being appropriate for secure scientific and data archiving purposes.
----
Datalog formats are very easy to use but have never been the recommended way to save your sensitive data. Yes the LabVIEW programming manual explains how to create and use them and I would expect it to do so since it's a possibility of it, but at the same time it states the version dependency. If you have critical data that needs to be accessible over 20 years then datalog is not for you (and effectively any other binary format neither).
The problem is that here someone requires a compact (or binary format) and at the same time openly accessible from any environment. If that is your concern do your own format header description and then stream the data in binary format to a binary stream file. This is similar to a datalog file in terms of compactness but avoids the version specific datalog header. The binary data itself is streamed in that way directly to disk in the format as outlined in the Application Note about Data Types. It is not as trivial as datalog files since you need to maintain your own header (recommended to do) and if you want to stream many data you also will need to do some record keeping somehow to easily be able to index data in the file. But the format is fully defined by you and can then also be read in other applications such as C programs in binary stream format.
While I agree that Activation might have certain long term risks I find it very easy to criticize certain aspects of a feature of a software because you want to use it for something it was never created for. And there exist fairly easy solutions for the problem you say you want to solve.
And since you talk here about future security mostly, the migration in these terms is much more important towards newer versions than the opposite. If you create a program now in a certain LabVIEW version and want to be able to recreate it over 10 years then it is not likely that you will then use an older version of LabVIEW than what you used today. So for that the limited ability to safe to older versions is never a problem. It is sometimes inconvenient during development if you work in different versions at the same time but not for the ability to guarantee access to your code in the nearer of longer future.
RolfK (talk) 20:40, 30 March 2008 (UTC)
thread_title:  Specific problems with LabVIEW activation, migration and file formats 

message: :Image:LabVIEW 8dot20 Splash Screen.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.
Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.
If there is  other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page.  Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.
BetacommandBot 02:25, 6 September 2007 (UTC)
thread_title: Fair use rationale for Image:LabVIEW 8dot20 Splash Screen.jpg

message: LabVIEW is also relatively expensive compared to other development suites. LabVIEW starts at $1199 (2007 pricing) for the base version and runs up to $4299 for the NI Developer Suite. The professional edition, which is the cheapest package that bundles the application builder, costs $4099. This compares to Visual Studio which starts at $299 (2007 pricing) for the standard edition.
The validity of this criticism is questionable. Comparing LabVIEW to Visual Studio seem like comparing apples to oranges. A more accurate comparaison would be to Vee, which runs for about 1500$.
Cochonfou 09:24, 8 October 2007 (UTC)
replies: text: A fairer comparison might be Visual Studio + Measurement Studio ($499 for standard edition) which is still cheaper than LabVIEW. Either way, LabVIEW is expensive and that creates a barrier for entry which keeps LabVIEW a niche product. Wjousts 15:19, 8 October 2007 (UTC)
replies: text: LabVIEW is far from a niche product. In the electronics testing and development and industrial automation businesses it's one of the de facto tools. It was never meant to be an application development tool and comparing it to visual studio is, as stated before, pointless.  Jhuuskon (talk) 15:22, 7 October 2008 (UTC)
thread_title:  Price 

message: It appears that NI no longer calls the programming language “G”, but calls it “LabVIEW programming language”. A quick check of the NI website confirms that, e.g., see this FAQ item. The change probably reflects the fact that virtually nobody in the research community has been using the “G” name but always referred to the language as "LabVIEW" in research papers. Vadim Makarov 05:24, 18 October 2007 (UTC)
thread_title:  Name of “G” language 

message: With help from the article I do not understand a basic feature of Labview. What is the outcome of Labviews Compiler? Does it produce C-code and thus runable on Microcontrollers? -- 84.132.87.172 14:40, 3 November 2007 (UTC)
replies: text: Labview code compiles down to machine language I believe. 128.95.141.35 (talk) 02:26, 16 May 2008 (UTC)
thread_title:  Outcome of LabVIEW's compiler 

message: The word "benefit" by itself smells like a sales brochure, and the first sentence of the section confirms this: "One benefit of LabVIEW over other development environments ..." Other development environments? Development of what? Food? Software? Hardware? I believe that this article should get a "rewrite because of objectivity" tag until this section has been turned into a comparison section. --Pmg 06:25, 9 November 2007 (UTC)
replies: text: I kind of agree. Especially since in this article it seems like the comparisons are cherry-picked and never defined. They want to state the benefit over other development environments (without naming which ones), but complain if you make an unfavorable comparison with other development environment(see price). The article really needs to state clearly what LabVIEW is and what it isn't. It isn't a general purpose programming environment. You could try and write something like a word processor with it, but you'd be mad to try it. Wjousts 13:51, 9 November 2007 (UTC)
thread_title:  Does a "Benefit" section belong in WikiPedia? 

message: :Image:LabVIEW 8dot20 Splash Screen.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.
Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to ensure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.
If there is  other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page.  Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.
BetacommandBot (talk) 23:08, 13 February 2008 (UTC)
thread_title: Fair use rationale for Image:LabVIEW 8dot20 Splash Screen.jpg

message: I removed this from the article:
:On the other hand, there exist (or have existed) programming languages lacking recursion capability or object-oriented features. Standard FORTRAN, for example, did not support recursion in versions up to and including FORTRAN 77Recursion Not Supported by FORTRAN, and even through FORTRAN 90, does not fully support object-oriented programming.Object-oriented programming using the Fortran 90 programming language
Because the article already qualifies it's comment about what features LabVIEW lacks with "most" programming languages. I don't think adding FORTRAN, an old and mostly out-of-date language, as a counter example adds anything to the article.  —Preceding unsigned comment added by Wjousts (talk • contribs) 16:51, 22 May 2008 (UTC)
thread_title: FORTRAN

message: do you know any alternative open source project/product to Labview? Are there such attempts?--Infestor (talk) 10:30, 29 October 2008 (UTC)
replies: text:  Try Python GPIB etc. support with PyVISA on sourceforge  — Preceding unsigned comment added by 134.95.66.160 (talk) 14:06, 8 November 2011 (UTC)
replies: text: This is not really appropriate for an article talk page, but while there's not really any close analog to LV, pretty much anything you could do in LabWINDOWS/CVI can be done just as easily in c++ using Qt or similar.  a13ean (talk) 20:25, 15 November 2014 (UTC)
thread_title:  Alternative Open Source Existis? 

message: While the information in this section is correct to a certain degree, the purpose of this page is not to show application-specific 'how-to' for the LabVIEW programming language. I believe this section should be deleted. Timothynolan (talk) 15:00, 13 November 2008 (UTC)
thread_title:  Need for section on using LabVIEW with Excel?

message: LabVIEW seems to combine instrument control, data acquisition, data display and analysis.  Anyone who wants to conduct experiments needs this combination.
What alternatives are there?
The list at the end of the article:
* Numerical software - Open source 	
:ADMB · FreeMat · GNU Octave · gretl · R · Scilab
does not seem very on-point.  Do any of those offer control and acquisition functions?  Does any other software combine these?
-96.233.27.159 (talk) 18:24, 10 June 2009 (UTC)
thread_title:  Alternatives 

message: Some other software-related articles contain a section on the programming that created that software - number of lines of code, languages used, etc.  I believe LabVIEW is written in C++, but I imagine that with its humongous growth other languages might be used as well.  Any resources available for what LabVIEW is made of and how big it is? Rob Hingle (talk) 20:23, 28 October 2010 (UTC)
thread_title:  LabVIEW internals 

message: :For an environment targeted for repetitive application, especially in process automation, LabVIEW includes no built-in functions for formally testing limits, reading a limits file, and conveniently tracking the passing or failing results.
:
:Due to such constraints in effect with formal and dynamic testing, the recommended usage potentially will not cover the required scope for production or therapy processes, especially when these are subject of risk and security auditing, e.g. according to FDA 21 C.F.R. §820 et seq.[5]
:
:Companies tend to build their own proprietary functions for this basic feature if they choose not to use National Instruments' product line TestStand.
This section is very unclear.  it sounds like a very specific application and has some passive-agressive sounding language in it (ex. ..."this basic feature").  If this is a well documented shortcoming, it needs to have more explanation and also links to better references.--70.187.190.211 (talk) 03:56, 10 March 2013 (UTC)
thread_title:  Formal testing section 

message: Would it be beneficial to add links to pages like State Machine, Producer consumer, or master slave LabVIEW programming techniques? I was planning on adding a page about the State machine (LabVIEW programming) would this be a good idea to expand on? (Sorry, I am very new to Wikipedia editing but know a lot about LabVIEW and want to help)  — Preceding unsigned comment added by Smith Pohl (talk • contribs) 22:27, 14 April 2014 (UTC)
thread_title:  Adding Programming Techniques? 

message: 1a. The "Graphical programming" section uses "Functions palette."
Does it have to be capitalized? I don't think so.
1b. The last paragraph in the "Graphical programming" section points out the necessity for a programmer to know and do right. I would suggest to separate this and make a subsection and maybe list good programming approaches like state-machine and master-slave.
2a. The "Criticism" section sounds quite biased. Some statements are debatable. Others are even false.
2b. "Due to its thorough adoption of a data-flow programming model as opposed to the sequential ordering of arbitrary commands like most other (usually text-based) languages there is a very real barrier to many people who attempt to apply already-learned principles from other programming approaches to LabVIEW. The inherent parallel nature of the execution of LabVIEW code is a perennial source of confusion among those who are accustomed to other approaches. Due to this, most opinions tend to be highly polarised with people either being extremely fond of it or being extremely hostile to it."
This is a completely biased opinion. Personally, with a background in C++, Java and some C programming as well as assembly language, when I embraced LabVIEW I thought it was the best thing since sliced bread. In fact, I'm not a fan of high-level languages and I find the dataflow programming model smart and less painful when it comes to debugging.
2c. "Compiled executables produced by version 6.0 and later of the Application Builder are not truly standalone in that they also require the LabVIEW run-time engine be installed on any target computer which runs the application."
This is a completely false and outdated information (the sournce points to a note from LabVIEW 8.2 dated August 2006). I used the application builder and deployed truly standalone executable applications that did not need anything else with LabVIEW 2011 and 2013. Things changed since 2006.
2d. "However, the run-time required for LabVIEW is not supplied with any operating system and has to be specifically installed by the administrator or user."
I don't see any problem with this. Java requires the same thing.
3. The article should really have an image of the front panel and the block diagram.
4. It would be nice to mention the duality of the front panel and the block diagram as well as add the modularity of the environment that allows you to have a VI inside a VI somewhat like a box inside a box. Also, I think the article should at least include a few applications and mention the cDAQ, the modules and instrumentation control through GPIB. 
ICE77 (talk) 04:11, 5 August 2015 (UTC)
thread_title:  Question and comments 

message: An article about program that exists for 30 years+ could for sure use some paragraphs about its history.--95.91.181.199 (talk) 14:40, 10 August 2016 (UTC)
thread_title:  History section 

message: The source documents that are listed in this section are all from National Instruments. That they are being used will further aggravate the warning at the beginning of the LabVIEW article. That is, that the article relies on sources too closely associated with the subject. Also, no source is listed for the claim that "Applications in LabVIEW are usually designed using well-known architectures ..." Rgwagner888 (talk) 21:28, 2 October 2017 (UTC)
thread_title:  Widely accepted design patterns 

message: Hello fellow Wikipedians,
I have just modified 3 external links on LabVIEW. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive http://arquivo.pt/wayback/20091228082756/http%3A//zone.ni.com/devzone/cda/tut/p/id/5053 to http://www.ni.com/labviewzone
*Added archive https://web.archive.org/web/20100324105833/http://www.labviewportal.eu/ to http://www.labviewportal.eu/
*Added archive https://web.archive.org/web/20120419000754/http://lab-view.com/ to http://www.lab-view.com/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 03:15, 15 December 2017 (UTC)
thread_title:  External links modified