A personal question for Aristos Queue

[Yair]

Stephen,

First, I just wanted to thank you for all your support to the community over the years. You don't get too many R&D guys to be this involved.

Second, the real question - Your signature is

QUOTE

"A VI outside a class is a gun without a safety. Data outside a class is a target."

and since you've had quite some time now with both the LVOOP beta and public releases I was wondering how much G coding do you do and how much of that uses LV classes (and is it all because you think that's the best tool or just because you want to work with your baby)?

And lastly, I was just wondering if there was any significance to your user name (other than the queue part, obviously ).

[Grampa_of_Oliva_n_Eden]

QUOTE(yen @ Feb 20 2007, 01:24 PM)

And lastly, I was just wondering if there was any significance to your user name (other than the queue part, obviously ).

Oh, oh please let us guess!

I think Aristos is (greek or latin) for excellence

Queue is a line

So I guess "Excellent line"

Ben

[Michael Aivaliotis]

Doesn't every word originate from the Greeks?

[Yair]

QUOTE(Michael_Aivaliotis @ Feb 20 2007, 11:46 PM)

Doesn't every word originate from the Greeks?

I've done a study about this (translation: I saw something on TV) and apparently there are one or two other languages involved as well.

[crelf]

QUOTE(Michael_Aivaliotis @ Feb 21 2007, 07:46 AM)

Doesn't every word originate from the Greeks?

So said Michael Constantine from My Big Fat Greek Wedding

[Tomi Maila]

QUOTE(Michael_Aivaliotis @ Feb 20 2007, 11:46 PM)

Doesn't every word originate from the Greeks?

I though LabVIEW is mother of all languages

[i2dx]

QUOTE(Tomi Maila @ Feb 20 2007, 11:52 PM)

I though LabVIEW is mother of all languages

completely wrong - if it was so we would not have a mouth and a tounge, but cable reels and wire cutters (instead of hands)

[Tomi Maila]

QUOTE(i2dx @ Feb 21 2007, 04:56 PM)

if it was so we would not have a mouth and a tounge, but cable reels and wire cutters (instead of hands)

What is a mouth and a tounge? I know some older models had cable reels but my generation uses bluetooth wireless connection to communicate with other of our kind. I've heard rumors there may be some other species besides ours. Supernatural skills of some users and discussion of some weid substance called :beer: here at LAVA have made me convinced that not all of you can be LEGO Mindstorm NXT robots like me.

[Aristos Queue]

Yen asked me two questions. I'll answer them in reverse order...

QUOTE(yen @ Feb 20 2007, 12:24 PM)

And lastly, I was just wondering if there was any significance to your user name (other than the queue part, obviously ).

Refactoring the Queue VIs (which used CINs) to be the Queue primitives was my first assignment when I joined LV R&D. Aristos, as others have mentioned, is Greek for "excellence" or "the best". It also is the root for "aristocracy," which in modern parlance has come to mean "ruling class". So "He who brings the best out of the Queues" would be a good translation.

QUOTE(yen @ Feb 20 2007, 12:24 PM)

the real question - Your signature is "A VI outside a class is a gun without a safety. Data outside a class is a target." and since you've had quite some time now with both the LVOOP beta and public releases I was wondering how much G coding do you do and how much of that uses

LV

classes (and is it all because you think that's the best tool or just because you want to work with your baby)?

Checking my credentials, I take it.

I think I've mentioned before that I don't get to do as much G programming as I like. There are many in R&D who program full time in G -- frequent LAVA poster Darren, for example. I am not one of those. On any given day, the majority of the hours are spent spelunking in the 2 million plus lines of C++ code that make LabVIEW and all of its various modules. My work on the LVClasses means that I've had to make many changes across lots of features, so I've wandered through most of those lines at some point in the last few years. When do I get to program in G? Mostly on test days -- when LV rolls into beta, the R&D team spend a good chunk of time developing whatever we choose to develop using G (and filing bug reports...). That's when a lot of example programs get written.

I only have two large-scale projects that I've developed using LabVIEW. One is a game that I built early on in my LV career and have tweaked a bit from time to time, but it is still pretty poor style. The other is a 300 VI hierarchy that scans all the VIs on a computer (or multiple computers), parses their block diagrams and builds a database to discover which nodes are most frequently used and which nodes are used in conjunction with which others and what sort of conjunction (which are wired together, which are in the same struct, and which are in the same VI). I've used this tool to find performance hot spots that need optimization in LV and to change the palette layouts -- when I can show that two nodes are *always* used in conjunction then it strengthens the argument that they should be on the same palette.

I don't program in G to the level of most of you. But I am a very strong programmer in whatever language I pick up, and G is no exception. More important, to this conversation, than how much I write VIs is how much I debug VIs. I get about one CAR every day from various users (more when we're in beta). The bug that the user files may be about some small corner of their code, but I see the entire VI, and frequently I can see corner or edge cases that aren't going to be handled properly. I get called in to debug problems with instrument drivers "that just have to be a bug in the LV compiler" that turn out to be a data value not being set properly. I don't get to write much in G, but I do know all the mistakes that can be made. And I think my LabVOOP team has provided a critical tool for preventing a wide swath of those bugs.

Since the release of LV8.2, my G programming has increased substantially. Some of that is the demand for examples for OO, which not many people can write yet. More of it is my own interest in using G is increased. How far can I push the LabVIEW classses? What can I do now that I couldn't do before? Is there some piece of code that was hard or confusing before that a class hierarchy can clarify? I've lately finished refactoring the General Error Handler.vi using LV classes, with positive effects on memory footprint, complexity of diagram and functionality. I don't know if I'll actually ship that or not, but I like seeing the cleansing effect on some otherwise very tangled code.

Do I use LVClasses in my own work? Yes. I worked for five years on that design because I considered it such a fundamental gap in the strengths of LV. In my opinion, LVClasses are the right tool more often than they are the wrong tool. The two tools that I've developed for my own use since August both use LV classes.

I made sure that LVClasses were available in the Base edition of LabVIEW when a lot of others were pushing for them to be in the Pro edition only. Many other developers looked at LVClasses and saw an advanced programming tool that could only be used by those with years of experience. I look at LVClasses and see a tool that a customer should be learning in Basics I. Before they create their first VI they should create their first class. I don't honestly think that we're at that point yet, usability-wise, but I intend that LV classes will get there within the decade. I get a lot of pushback on this that the random scientist or engineer with no programming background has no clue what a class is or how to use it. I point out that they don't know what a front panel or a block diagram is either, and yet they figure it out from our interface.

I don't think that I could've worked for 6 years on that project without a strong amount of belief that my team was bringing something fundamentally *better* to the table. Yes, I said better. You won't hear that from Marketing or from most CLDs, or, indeed, most users in general. The value of the classes to LV programming is something that is becomming apparent to one developer at a time. Darren had his epiphany only a couple of weeks ago when he was working on an XML parser. Within NI, the value of the classes is catching on -- the next version of LabVIEW will see LV classes at the heart of AppBuilder, the MathScript node and the Getting Started Window.

In short, I believe this: LabVIEW classes are an outright replacement for clusters in most situations unless you have to be backward compatible with old code or you're passing across DLL boundaries. LabVIEW classes should replace many uses of the typedef (but not the strict typedef or the custom control). Whereever "type like" data is connected to a case structure -- an enum, or a string ID -- that is a place where classes can improve the readability, the maintainability and the probability of correctness of a VI.

I do believe in classes. A lot.

And now, if you'll excuse me, I have a bug to fix. A coworker has presented me a 1260 VI hierarchy involving 49 LabVIEW classes. And one of those VIs doesn't want to load in the latest development build. "It worked fine last week, but now is broken. I tried to pare it down, but everything seems ok if I take away any of the other 1259...." :ninja:

[Yair]

Wow.

That is quite an answer. Thanks.

QUOTE(Aristos Queue @ Feb 24 2007, 02:44 AM)

Checking my credentials, I take it.

Not so much checking your credential as wondering about this feature. I only got to use 8.2 in the evaluation version, so I naturally had very little time to play with LVOOP, but I have tried following the LVOOP discussions at least at a skimming level, since I don't actually use 8.2 and reading and understanding everything that Tomi writes could be a full-time job. Come to think of it, it almost is your job.

Basically, since your signature was so "absolute" I was wondering where you think the line should be drawn to start using LVOOP (which you've now explained), since it does seem to have some overhead. I'm sure that when I do start using 8.2 (or 9.0 or 9.1) I'll come back to this thread and to some of the other related reading material.

QUOTE

And now, if you'll excuse me, I have a bug to fix. A coworker has presented me a 1260 VI hierarchy involving 49 LabVIEW classes. And one of those VIs doesn't want to load in the latest development build. "It worked fine last week, but now is broken. I tried to pare it down, but everything seems ok if I take away any of the other 1259...." :ninja:

Oooooh, sounds fun.

[Tomi Maila]

QUOTE(yen @ Feb 24 2007, 11:39 PM)

... reading and understanding everything that Tomi writes could be a full-time job. Come to think of it, it almost is your job.

It's just my limited English skills that make my writings hard to understand, not the technical issues. There is nothing complicated in LVOOP itself (except perhaps under the hood). ArQueue [aɹkjuː] is very right in his argument when he says that LVOOP is a proper tool for even the most basic programming tasks. It may not yet be a proper tool for all the most advanced programming tasks however.

Tomi

[Jim Kring]

QUOTE(Tomi Maila @ Feb 24 2007, 03:09 PM)

It may not yet be a proper tool for all the most advanced programming tasks however.

In my opinion we desperately need native, by reference, active objects with support for events and arbitrary and dynamic secure distribution across multiple execution targets. Think we'll see this anytime soon?

If NI thinks that we (I) don't need these things, then they don't understand our (my) needs.

The current LVOOP is great, though -- its a right step in the right direction at the right time. It just doesn't solve my day to day OOP needs.

[i2dx]

QUOTE(Jim Kring @ Feb 25 2007, 12:34 AM)

In my opinion we desperately need native, by reference, active objects with support for events and arbitrary and dynamic secure distribution across multiple execution targets.

ACK

and I'd like to have "automatic Member storage" - like in LV2 Globals ... and, and and ... or - to cut a long story short - I'd like to have C++/C# like LV-Objects, with a "NEW" operator (which implies by reference objects ...)

[Yair]

QUOTE(Tomi Maila @ Feb 25 2007, 01:09 AM)

It's just my limited English skills that make my writings hard to understand, not the technical issues. There is nothing complicated in LVOOP itself (except perhaps under the hood).

The problem is not with your English, which seems to be (as far as I remember) at the level of a native speaker (is Finland like Sweden, where a very strong emphasis is put on English?).

My problem is mainly that you're throwing around OOP and computer science concepts I'm not familiar with (mixin classes, to take a recent example) and which I don't have time to properly study and with the fact that since I haven't really had a chance to play with it, I still don't really understand by-value OOP. I even downloaded your paper about this a while back (it's still on my HD), but I haven't had a chance to read it, since it was 30-something pages.

Add that to the fact that I don't have 8.2, so I can't actually see the implementation for myself, and you will see why I'm having problems.

[Aristos Queue]

QUOTE(yen @ Feb 25 2007, 12:50 PM)

Add that to the fact that I don't have 8.2, so I can't actually see the implementation for myself, and you will see why I'm having problems.

Will you be at NI Week in August?

[Yair]

QUOTE(Aristos Queue @ Feb 28 2007, 05:38 PM)

Will you be at NI Week in August?

Why? Do you want to give me a free copy of 9.0? :thumbup:

I was planning on being at the last one, but that didn't work out. If I'll be at the next one I'll be sure to seek you out, but I don't think I need a private lesson, just to do some actual work to get the concept. :laugh:

[Aristos Queue]

QUOTE(yen @ Feb 28 2007, 01:49 PM)

Why? Do you want to give me a free copy of 9.0? :thumbup:

I suspect that come August you'll be asking for a piece of NI software, but it won't be LV9.0.

(that's my provocative comment for the month... make of it what you will...)

QUOTE(yen @ Feb 28 2007, 01:49 PM)

I was planning on being at the last one, but that didn't work out. If I'll be at the next one I'll be sure to seek you out, but I don't think I need a private lesson, just to do some actual work to get the concept. :laugh:

I ask only because I think (schedule not yet finalized) there'll be presentations teaching LabVOOP at NI Week.

[Ton Plomp]

QUOTE(yen @ Feb 28 2007, 08:49 PM)

Why? Do you want to give me a free copy of 9.0? :thumbup:

I was planning on being at the last one, but that didn't work out. If I'll be at the next one I'll be sure to seek you out, but I don't think I need a private lesson, just to do some actual work to get the concept. :laugh:

Please not a new version, first get 8.2.1 patch!!

The only reason to deploy a new version shoud be extra functions (XNodes?) or improve current features dramatically (XControl in array, LabVOOP by ref)

Ton

[Yair]

QUOTE(Aristos Queue @ Mar 1 2007, 07:54 AM)

I suspect that come August you'll be asking for a piece of NI software, but it won't be LV9.0.

Ooh, ooh! Do you mean that NI will finally start selling the cheap G-based IDE which will be directed at wide audiences? :laugh:

Well, I have to admit you have my curiosity piqued.

[Yair]

QUOTE(Aristos Queue @ Mar 1 2007, 07:54 AM)

I suspect that come August you'll be asking for a piece of NI software, but it won't be LV9.0.

After some reflection, I don't think I'm that curious anymore.