Val Brown

QUOTE (neBulus @ Feb 24 2009, 01:34 PM) Thanks, yes that helps and, at some point, if someone can, a "small" example would be very wonderful. They probably already exist so maybe someone here knows an example they can point to. Again what would really help me would an example that hews as close as possible to these descriptions. And FWIW, this is a really great thread for me!

QUOTE (bsvingen @ Feb 24 2009, 12:57 PM) Thanks for the reply. That helps too. Can you recommend a good book or other written resource for what you're calling "Actor Oriented Design"? I'd like something that you feel comfortable with, that was/is helpful to you, esp in facilitating seeing LV in the way you've described. And, of course, others here may have some good resources to suggest as well.

QUOTE (neBulus @ Feb 24 2009, 09:59 AM) Thanks for the explanation. You've hit on a couple of points that I've wondered about and thought I understood and it seems like I probably do because you've expressed the same understandings. 1. the "by-ref" implementations will, almost inevitably, execute more slowly for "equivalent" code. This is because of the multiple operations needed to "access" the data through the "by-ref" process. 2. This might be helpful from a design perspective -- esp for those used to by-ref object design -- but it will also lead to the likelihood of runtime penalties in performance. 3. There are work-arounds using by-val that can address the "limitations" of that approach re: point 2 above. Do you an example of the "Active Object" code that could be uploaded here? I'd like to see how you've done it and then, if possible, get comments from others about it, esp from those who favor a "by-ref" approach. All of that would really help me understanding this issue more deeply.

There are a number of examples available via the web for interconnecting to an Access mdb file using the DCT. I'm not where I have that list at this time but I would think a search on the NI forums or support link would work using keywords like "Access", "Database Connectivity", etc.

QUOTE (bsvingen @ Feb 24 2009, 07:27 AM) Can you -- or someone else here -- clarify what would be "missing" from such a stance: ie what does "by-ref" add at a functional level that is not available with what you're reporting. Not being "deep" in OOPs I'd really like to hear this laid out as clearly as possible by those who know. Let me say this another way: if the native LVOOP really does "do it all" then I'm much more interested in pursuing OOP within LV. If not (yet?) then I might just wait to jump into the pool until the native implementation does "cover the waterfront". I don't want any "OOPs" or "gotchas" along with way.

QUOTE (bsvingen @ Feb 23 2009, 11:15 AM) Are you saying that LVOOP "...and queues" covers the water front or am I misunderstanding you?

QUOTE (Jim Kring @ Feb 21 2009, 11:11 AM) I haven't had the time to download and test this but I'm wondering if you know the behavior for 5 or 6 such events and deleting one: ie where do the remaining events map now? There may be an underlying logic to the actual behavior which, although it looks pretty clearly "buggy" to me, might allow us all to work with it until it is fixed. FWIW it sounds like a index reversal issue in the underlying code of LV itself and the event registration process.

I've used the DCT for several years and found it very useful. I'm also on Premier support for the Professional Development System so, for me, having access to AEs who know what they're doing (that's the Premier part) I know that I can find out what I need to fairly quickly -- and definitively. I was never that interested in using LabSQL as it was a third party tool, not NI officially supported. Now don't get me wrong. I know Jeffrey and his work is exemplary but I really wanted something that would be eligible for "official" support. Your situation might be very different. If you're no on SSP or Premier status then you probably want to use tools that can be supported in other ways, like via user forums. The you might reasonably ask: "Why pay for something you can get for free?" But even if I weren't on SSP (and Premier status) I'd probably still go with the DCT because my primary RMDBS target was Access not MySQL.

QUOTE (Phillip Brooks @ Feb 5 2009, 04:26 AM) Perhaps, BUT -- and it's an incredibly large but (which anyone can laugh at) -- how long would it take a non-programmer to laugh at each one? Now before this reverts to "noobs" vs "real programmers", it again makes my point. Everyone who says the top comic is "easier" to understand is simply well taught in text-based languaging of operational code. And actually we don't DRAW pictures, we USE pictures (graphic images) to accomplish real-world tasks. Hey keypunch still works, as do TTYs... QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM) Since bsvingen brought up Matlab and LabVIEW, I thought I'd add my two cents. Lately, I've found that I've been quicker to open Matlab than LabVIEW for a lot of my tasks. I still prefer LabVIEW for anything that has to interface with hardware (whether NI or third-party). For other things I find Matlab much easier to deal with. This thread has caused me to try to take a step back and think about what has led me to that preference. 1) Data presentation: I find that Matlab's plotting capabilities are much stronger and easier to use than LabVIEW's. I find exactly the opposite, esp with the picture control toolkit. QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM) 2) Expandability/feature creep: Lately, I've been primarily writing code to assist me in performing data analysis. In those cases, my product is not the code or the GUI, but the analysis and conclusions I can generate using the code as a tool. For this reason, it can be very difficult to define a priori exactly what the code has to accomplish. My processing/code-development effort might sound something like this: "Show me A vs. Time, B vs. Time, and A vs. B. Hmm.... That's interesting - now what if I perform operation X on A, then plot A vs. C", etc. A text-based language like Matlab makes it very quick and easy to throw an extra operation in between two existing steps. Attempting to do the same thing quickly in LabVIEW tends to cause spaghetti. I find exactly the opposite here as well and a lot of my work involves "ad hoc" variations of my current code to add-in features, troubleshoot and prototype alternatives, etc. to my already novel visualization and analytic routines. It's difficult for me to imagine how that would go using Matlab, C/C++, etc. QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM) 3) Toolboxes, etc.: I occasionally do georeferencing of data to match it up with terrain or overhead pictures. Matlab has a Mapping Toolbox, LabVIEW does not. Matlab also has a large community of people who share their code. I have not yet found a Matlab forum or community that is as strong as LAVA in terms of answering questions or having the type of discussion we're having now, but there do seem to be a lot more people sharing their work (~9000 files in Matlab Central's file exchange vs. 74 in the CR here). A lot of that is probably cultural and is quite understandable - if LabVIEW is more heavily used in industry or by consultants/contractors, then of course people aren't going to be quite so willing to give away their work for free. It seems to me that LAVA does a fair amount of code sharing but, more importantly to me, it does an enormous amount of expertise sharing (your second point about LAVA) and that is a far, far more important resource to me personally and I suspect to most LAVA members. I don't need mapping capabilities but, if I did, I would look for some form of ActiveX component that could do the same. Something like what I've done to encapsulate WMP for my use and, hopefully, at some point in the future NI will do the more complete encapsulation that I've requested (esp maintaining the size of the visual image regardless of source when Pause and Play operations are toggled repeatedly). QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM) 3)4) Backward compatibility: This is related to my previous item, and to the "openness" that others have discussed. Because I'm still using LabVIEW 7.1.1, I can't even open a lot of the files that people have posted here. At least with Matlab and other text-based languages, I can still look at the code. I understand about not being able to "forward" visualize from an earlier version. I guess that's kind of like trying expect C++ classes to function exactly the same in an early release of SmallC or something like that. Yes, it would be nice if LV could forward visualize and leave a :question: as a marker when it didn't recognize a construct from a version of LV later than the one running; however, I expect that's a very difficult feature to implement. I don't have this issue because I'm on SSP and keep up with the most current versions pretty well and I find THAT process far, far smoother and easier than having to update an almost infinite variety of C/C++ libraries, COM objects, NET controls, Matlab scripts, etc, etc. One source (NI), one product containing its own dependencies that are completely versioned internally (LV and its toolkits) -- all of that greatly simplifies my life and adds most of the complexity and capability that I need but I also have a rather specialized situation in that I'm a single programmer, with essentially a single family of products.

QUOTE (Jim Kring @ Feb 4 2009, 04:11 PM) Yes, of course, but isn't that also part of the problem? I mean you could even use card punch to implement text-based languages but aren't we sort of like a couple of decades past all of that? Or are we saying that we should reduce what we do to the lowest common denominator, ie a notepad compatible text editor?

QUOTE (neBulus @ Feb 4 2009, 12:48 PM) ...esp if the keyboard has a trackpad because it's on a laptop!

QUOTE (bsvingen @ Feb 4 2009, 12:30 PM) I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

QUOTE (bsvingen @ Feb 4 2009, 12:30 PM) I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

QUOTE (jzoller @ Feb 3 2009, 08:42 PM) I don't think so. LV is setting a standard -- a true visual interface. And, if I'm not mistaken, some matured form of LVOOP will eventually consolidate and remove THAT perceived barrier. One other innovation that I think could really help with general acceptance would be completely transparent C/C++ text-based interface in the mode of the Math Expression node. I KNOW it's not at all easy but, if it were done, it would really make it a no-brainer for the "text-uber-alles" crowd to really "get it" about LV's capabilities. That might even make some other code more "readable"... QUOTE (jzoller @ Feb 3 2009, 08:42 PM) However, I agree with jdunham that the "threat of conversion" is very real. Last place I worked, we were told (by executive fiat) to retool everything in C# and C++. Pointing out the multimillion dollar investment loss and 2 year downtime seemed to cool the executive enthusiasm, and this made them mumble something vague about carrying on with LV and go back to counting their bonuses. In the end dollars DO count and I believe that IF companies (and individual programmers) actually counted the REAL costs of using C/C++, JAVA, etc they would come to see just how cost-effective LV really is. QUOTE (jzoller @ Feb 3 2009, 08:42 PM) Watching LV restrict itself to its market niche is like watching Tiger Woods decide to only play mini-golf, but if mini-golf is where the money is... To say it that way does sort of imply that LV is a bit of a toy or game.

QUOTE (jdunham @ Feb 3 2009, 07:04 PM) The naive part is, IMO, the idea that it will open source, low (initial) cost a la C/C++ compilers. The idea that LV will ultimately become a dominant IDE is pretty obvious.

QUOTE (Michael Aivaliotis @ Feb 3 2009, 05:03 PM) I believe it's just the new standard and, if that's the case, the "fix" would be to revert to XP or rework everything based on the new font.

QUOTE (bsvingen @ Feb 3 2009, 03:18 PM) I think it's highly unlikely and incredibly naive to believe that NI should "market" LabVIEW as if it were JAVA. Not only is there no real need for NI to do so -- unlike the situation facing Sun when they sourced Java -- what would really be the advantage? One posted cited cost as a factor making LV not be a general purpose language. I think the real issue was that it does cost, so it is a low-cost general purpose language. Other options APPEAR to be low-cost because for the "pure" base language and IDE the cost IS lower, initially. But, as I pointed out above, the learning curve for other languages as well as the cost and need for additional "add on" libraries, etc makes the overall cost far, far HIGHER than using LV. I've never had a problem distributing my built apps, at least NOT with the LV portions. Where I have had problems over the years was with all of the OTHER components and "pieces" that were written in C/C++ and VB. A big part of my efforts over several years involved completely removing ALL of those other portions, so as to simplify my distribution and maintenance issues. To say this another way, you couldn't pay be enough to NOT use LV and move to another environment with what I'm doing. And bear in mind I started out as a unix and C hack back in the day (as the saying goes). I am SO thankful to be out from under ALL of that nonsense and that is all because of LV. I only wish the rest of the initial team had headed my advice and ONLY used LV. It would have saved me thousands of hours of re-programming, re-factoring time.

QUOTE (Dirk J. @ Feb 2 2009, 12:31 AM) Again I think several of you guys are making several of my point(s). It SEEMS difficult to build with LV because you're benchmarking what/how LV works and does its builds against text-based programming IDEs which have ENORMOUS amounts of "hacks" in them to make it all "seem easy". What you're "used to using" seems easy almost regardless of how easy the alternative is. Case in point within the LV environment. I don't yet use the wonderful option that Darren demonstrated so well at NI Week. Having to move to the keyboard while in LV is SO FOREIGN to me that it seems slower to me than just using my trackpad and dropping down the pallets. Now which way is really "easier"? If you're on a desktop system and need a mouse (or a laptop and USE a mouse) then moving to the keyboard to type a bit doesn't seem like a big deal but, if you're NOT using a mouse at all then it really can become a far digger deal. The feature is great and I'll get into using it "at some point" but it's not high on my list while I have development and tech support demands on me like I do currently. Yes, NI could do some things differently but I'm not so sure that it's just "noobs" who like the current orientation of the company.

QUOTE (bsvingen @ Jan 31 2009, 01:31 AM) You make my point. "Readable" means text-based and that ain't LV although, as you well know, LV can make use of text-based language constructs.

QUOTE (bsvingen @ Jan 31 2009, 12:35 AM) In other words, you're essentially a C++ guy, committed to open source, who just wants a graphical interface. FWIW, I think you're missing the point of what LV is and does but then again everyone is entitled to their own opinions.

QUOTE (Aristos Queue @ Jan 30 2009, 04:45 PM) Perhaps yes, perhaps no. I think the biggest two hurdles for LV gaining such "general" acceptance as REAL programming environment are its "high" cost and its undercutting of how much traditional programmers need to do in architecting large, complex apps. No, I'm not saying that LV costs too much, I'm saying the perception is that the cost is high. I've heard so called "real" programmers complain that they can buy x,y, or compiler of IDE for much, much less. Of course in those analyses leave out the costs of the additional libraries, reference materials, courses to attend and overall development time (and cost). Those other aspect simply are seen as "the costs of doing business" and so seem to not "count". The second issue is IMO the more profound one as it goes to the whole issue of identity and that issue drives a lot of what most humans do. The idea that one doesn't have to be a "guru" to do high-level work does seem to be offensive to a number of the more traditional text-based programmers I've known over the years. I think a side note to some of that second issue is the way some live out their commitment to open source initiative. Whether or not people know about OpenG and its wonderful efforts, there is a perception that LV is a "closed shop" and some more traditional text-based folks that I know, really don't like that at all. I have always found that interesting in terms of the commitment that some of those same people have to MS products but I guess "that's different" as Emily Latella would have said.

QUOTE (Aristos Queue @ Jan 30 2009, 01:34 PM) How do you see that being a problem? FWIW it seems to me that keeping both "groups" of LV users active and happy is what counts and is pretty "doable". At a certain level other programmers likely won't get it for quite awhile -- too much investment in "BetaMax and 8 tracks", but perhaps that's just my opinion.

QUOTE (shoneill @ Jan 30 2009, 12:44 PM) Shane, I beg to differ. LV is easy to use and no background in CS is needed -- to at least get SOMETHING running and sometimes even quite serviceable code. Try to do THAT with C++... What part of those phrases disturbs you? Is it the implication that one CAN potentially do more with less CS background or is it something else?

QUOTE (dblk22vball @ Jan 30 2009, 11:28 AM) I chimed in as well. The problem is that LV does make it "too easy" to do REAL programming and not have a CS background. That generates jealousy and anger esp from those who've invested years in learning the arcana of overloading functions from some obscure lib somewhere. The buggy whip manufacturers got really upset by automobiles...

QUOTE (jcarmody @ Jan 29 2009, 03:27 AM) That depends on whether you want to trigger the event structure (Value (Signalling)) or just set the value and let the logic of that subs dataflow determine the action to take. Both are available and there can be reasons to use each, in different instances. For instance going into Pause=True one might want to make Run=False or something equivalent and that might mean Pause is Signalling whereas Run is just Value.