A scathing review based on my experience upgrading from labview 7.1 to 8.2.

[billings11]

Mike,

I see what you mean now.  Thanks for your response.  Believe me if I could go back now I wouldn't have used the database toolkit.  But I have a whole library written now using the database toolkit, and you know it just burns me to rewrite stuff that used to work fine.  You are probably right that I should cut the toolkit loose and use ADODB directly when I find some extra time.  The database toolkit did a good job of repackaging that functionality into a really easy to use vi set (even if it was just packaging) - until it completely broke for variants (and by the way also many arrays of clusters.)

Yeah I think it was just a mistake with the cut and paste.  It is just frustrating because you get used to a basic convenience and its just gone by accident.  Same with the comment colors.  I don't think many people at NI are actually using labview anymore for large applications.  They may have some great developers there, but I bet most of them haven't done any major development in labview for quite a while.  So they don't even realize the things that have accidentally been lost or broken.  If all you did for two years was overhead presentations of labview with really simple vi's, you'd probably start to lose touch with large scale development stuff a little bit, no matter how much of an expert you were!  When I tell long-time NI apps guys about the default comment colors, they assume I don't know what I'm doing if I don't know how to go in the options menu.  Then when I show them, they are just suprised that you can't even change to a transparent background anymore.  So basically now through 8.0, 8.2, and 8.2.1 this is the first time these guys have even heard of it.  That means they can't be using labview these days for anything more than seminar presentations.  Out of touch.

On a side note:

I went to an NI seminar a couple weeks ago about labview memory management, and of course as I'm sure you know they say not to use local variables because they create so many copies of the data.  And that's fine and those of us that have been doing this a bit understand that.  But at the end of the presentation I asked, "So say in a big event-driven state machine application, you know with 20 or 30 variables that all need to be modified in multiple states, what's the best alternative?"  And they sort of look at me like a deer in the headlights, like they've never thought about it before.  Meanwhile every developer in the room is sort of nodding and hoping for a good answer, some great new feature in 9.0 or something.  He says, "Well you could wire every variable through a shift register."  So I say, "But that would mean 20 or 30 shift registers wired through every state!"  So he says, "well yeah I guess that is what you would have to do."  And after the presentation all the developers are talking with each other about that exact thing - what to do in state machines, how to get around locals, etc.  One guy's using FGV's everywhere, another bites the bullet on the shift registers.  It is the hot topic among developers, but totally missed by the NI people.  So I guess that sort of illustrates my feelings about this.  Ni seems focused on small vi's, easy ways to talk to a USB DAQ device or something.  That's good and all, but no one at NI is really thinking about what real labview developers are doing, because no one at NI is doing what everyday developers are doing.  None of these new features really seem to help for guys like us. 

I really wanted to go to 8.X because of the Project Manager and the new application builder.  Since I have around 40 PC's to deploy to, I was hoping for a real MSI file output so I could set up network-deployable installations with my IT guys.  But the new stuff still doesn't give us that.  Just a setup.exe with no deployable MSI's.  The project manager its sort of nice I guess once you get used to it, but not enough to warrant the pain of an upgrade.  Now I'm buying a third-party application builder that generates MSI's.

I am fired up about the time I've wasted fixing bugs for no benefit, but at the same time let down by the company I've advocated for many years.  I'm let down enough to start seriously looking at other alternatives, and you know that's saying a lot.

[tst]

I really don't have that much experience with the NI AEs (at least not in these areas), but I would definitely not say that NO ONE at NI knows about this. There are several contributors to the online communities (mostly from LabVIEW R&D) who know what they're talking about and do address these issues.

A common method for the issue you brought up is creating a cluster and passing that cluster through the shift register. Whenever you need a variable (a cluster element) you bundle and unbundle as needed.

As for the diagram color, I'm fairly sure the explanation I gave is the right one, but I can't find the references to it at the moment.

[tst]

What I found was this thread, which is probably where I got the idea, but that does not appear as an official explanation.

[Ben]

Hi Billings,

I have to admit that many of the issues you have raised are near and dear to my heart.

I would like to put a positive spin on one issue, the "free lable text".

The first time I took the CLD exam I lost points because I used non-standard font colors for my comments ( I used to use dark blue).

With the change to way it is now, I would have to go out of my way to loose those points!

Done spinning!

Ben

[billings11]

Wow Ben.  I don't think I'll let NI tell me I'm not a certified developer because I like to use dark blue comments.  They are comments, and different commenting styles are OK.

[Travis_M.]

Hello billings11,

First of all, thank you for giving us such a detailed description of the problems you have encountered during your upgrade.  Feedback like this from you, and other customers, is very useful for us, and I assure you that we do take it seriously.  Your review was obviously very well thought out, and will undoubtedly require a detailed response from us on each issue you bring up (including the point about large-project G-development at NI).  I’m going to be looking into that, but until then please let me know if there any other issues you would like to have us look into.

Thanks a bunch,

[Ben]

"... and be willing to walk into hell for the glorious case..." (Un-reachable Star, Man of LaMancha)

Thank you for stepping forward Travis!

Stars to you!

Ben

[billings11]

tst,

I don't understand why NI is now trying to assert a commenting style in labview 8.  People have been coding in labview a long time.  Like I said, thousands of developers through years of code across dozens of industries.  Trying to force developers into a particular commenting style at this point, to go as far even as to take points off in the developer certification if comments arent yellow and black, is simply stupid.  Smart people have developed sophisticated and documented systems within their own design groups for illustrating and commenting vi's that differ from NI's arbitrary decision of yellow and black.  So all NI is doing is making labview more cumbersome for them.  To me this is yet another example of how out of touch NI really is.  When I have state machines or nested loops I often like to color in the while loops light green or light yellow so they stand out and are easier to understand.  Is the NI mandate light blue instead?  Do they take points off the CLD exam for that too? 

I went to a presentation on memory management at "developer education day", and the example on the projector for 45 minutes is a single while loop with a constant wired to a shift register.  We were playing "Hide the dots".  I get that we are supposed to apply the core ideas to bigger applications, but the lack of realism in the example code makes it basically useless.  I go to those things to share ideas with other real-world developers.  There are some smart labview developers out there I can still learn from!  A big part of the day was sharing labview 8 bugs with each other.  I'm not learning anything from NI at this thing.  They should call it "NI Staff Education Day".  We spent the day trying to tell them about all the problems they haven't addressed, or the lack of usefulness of certain things in certain situations (like local variables in state machines).  I know there are ways around that issue but I don't consider any of them 'convenient'!  I'm giving them code showing how to reparent windows using the windows API and asking why they don't include it in labview instead of messing around with panes and subpanels that are buggy and not that useful anyway.  But I've been showing them that since 6.  I don't get the feeling they are listening very well. 

Travis, I know I deserve a thorough response.  But you are probably the 10th NI representative I've brought all these things up with in the past several weeks and I still don't have any response on any of them.  8.X was a very, very poor release, man.

[altenbach]

---

@billings11 wrote:
I don't understand why NI is now trying to assert a commenting style in labview 8.  People have been coding in labview a long time.  Like I said, thousands of developers through years of code across dozens of industries.  Trying to force developers into a particular commenting style at this point, to go as far even as to take points off in the developer certification if comments arent yellow and black, is simply stupid.  Smart people have developed sophisticated and documented systems within their own design groups for illustrating and commenting vi's that differ from NI's arbitrary decision of yellow and black.  So all NI is doing is making labview more cumbersome for them. 

---

Let me just focus on this point alone, because I have not bumped into the other issues you mentioned. Your description can easily be converted into an argument for a NI asserted commenting style. 🙂

Yes, there are many developers and industries. New companies start up and old companies close show. Developer change jobs. If each company has their own style, developers are " forced into a particular commenting style" (your words) whenever they start a new job.

Having a unified style that is accepted industry wide IS better. It simply should have happened already a long time ago. It is bad if there are competing standards for no good reason (look at paper vs plastic, VHS vs betamax, HD-DVD vs Blue Ray, the bewildering amount of cell phone battery formats and charger connectors, etc.)

There is a limit to the artistic creativity. We had examples posted where the diagram had a "hot purple" background for no reason at all. 😮

[tst]

For what it's worth, I understand what you're saying about the comment color, since I don't use the default either. I just use another method which wouldn't be affected by NI's change, but I still agree (without really thinking about it) that people should have the option of changing the default if they want to, since many people already have their own styles.

As a side point, how do you change the default color for comments? I couldn't find anything in the options menu. Is this an INI key?

As for the reparenting, that's fairly simple - the entire content area of the window is handled by LabVIEW itself and not by the OS to make multiplatform support easier. You can use the Windows API (I have done it myself), but that would be useless on the Mac and in Linux and NI would have to maintain several sets of code, each with its own potential bugs. Having panes as an integral part of the LabVIEW class hierarchy should be much easier for us, but I don't have any real experience with 8.x, so I can't really comment on that.

I also wouldn't mind having a nice way of creating an MDI interface.