LabVIEW
Zoom in on Block Diagram
Far too often inexperienced developers hate LabVIEW. I assume they are trolls because they don't listen to reason, or the more experienced developers. This is the case with you which is why I assume troll. If you want a well reasoned explaination fine lets go.
Bad code can be done in every programming language, the typical thing in text based languages is the GOTO. It makes code hard to follow and hard to maintain. LabVIEW is a programming langauge and has all kinds of similar things to avoid. Bad programmers can use a GOTO and good programmers can say "that is bad code and it should be done like this instead". Well I can look at the crazy crappy code you posted before and say the same thing. Adding a zoom feature doesn't make bad code good, and a GOTO is no way to develop large scale applications.
Large companies are using LabVIEW in large applciations controling very complicated systems. And I'm going to guess that no code at SpaceX looks like the image you posted. Just because you have a hard time making LabVIEW use large models and complicated parameters doesn't mean everyone does. This is not a fix, and LabVIEW is not broken.
My point about me not wanting zoom wasn't so much about me, it was about the CLAs I referenced who have decades of LabVIEW, and test automation experience. If 100 out of 100 experts in any field agree on something, it is probably right. I'm not saying we should blindly believe experts, but lets take their opinion into consideration.
LabVIEW is not a "bad" product. I have made a career out of the LabVIEW platform and what NI has made and many others have been successful in it too. And if you think NI is overpriced you should checkout some of their competitors. Orders of magnitude more expensive I promise you.
What is with all the name calling seriously, again with an indication that you are trolling.
Kochise wrote:
I'm an embedded coder, assembler, C/C++, you know, something that really needs some prior organization/structuration. So I'm not talking for me, I'm talking in general. This is a general issue.
And properly done LabVIEW code is the same way; you need proper organization. And a zoom is not going to fix that.
@Kochise wrote:
I never said Labview is a bad product per se
This confusing sentence made me believe that is what you were saying "It's not because you don't like it it is trolling, or because I don't like Labview it is a bad product"
@Kochise wrote:
just like a text based language would have avoided by not implementing the GOTO operand.
Right and how pissed off would a text language community be if a language that had GOTOs all of the sudden removed them and broke all your code?
@Kochise wrote:
Hence, now that Labview has implemented traps( 28 connectors) it should implement a tool to avoid them instead to ask people to refactor the code permited by Labview.
If you are using 28 connectors you are doing it wrong. Use a cluser that is type defed. It sounds like you are lacking training and experience. If I tell a certified electrician he is doing wrong, and I have no electrical experience or training, I expect him to laugh at me or ignore me. At least here I'm suggesting you take some of the free training available online.
@Kochise wrote:
This is an insane amount of work
I disagree. And actually think it helps spot bad code much faster. Oh you didn't lay out your code in a style indicitive of well thought out code? Then I'm going to guess there are inadvertent bugs in this code. I believe it is much easier to spot bad code in LabVIEW because of its visual nature than text.
@Kochise wrote:
CLAs are using Labview in a certain way, and I won't push the enveloppe to pretend they inherently hold the truth. Sure they have capitalized experience over the years, but again, that's not Labview's audience, it is for people that used not to code, or people coding with text based programming languages.
I disagree, LabVIEW is for everyone. C is for everyone. Java is for everyone. Being for everyone doesn't automatically mean you should cater to everyone, or even beginners. Cater to the collective, and take experts opinion higher than the developer who started using it today. I assume this is partially why NI made the Champions program.
@Kochise wrote:
Not all programming languages are for everyone, otherwise we would all code in forth or lisp.
But you don't understand...LabVIEW IS for Everyone. All joking aside yeah graphical programming is difficult for some people to pick up, but then again so is any programming language. If I've never done any programming before, no language will I be able to pick up and be an expert at without training and experience.
EDIT: Oh and if you do want some of that free training here are a few links.
6 Hour LabVIEW Introduction
Self Paced training for students
Self Paced training beginner to advanced, SSP Required
LabVIEW Wiki on Training
@Kochise wrote:
I never said Labview is a bad product per se, but it have traps that could have been avoided by not implementing them, just like a text based language would have avoided by not implementing the GOTO operand. Hence, now that Labview has implemented traps( 28 connectors) it should implement a tool to avoid them instead
Did you not read my earlier post? I specifically mentioned a native to the language method for just such circumstances that does not require "Zoom" While you are spending all this energy why not re-invest it in learning the language you need to work with. Try Right-clicking here and there and find out what you actually CAN do. My $0.02
to ask people to refactor the code permited by Labview. It's like leaving the candy jar open and blaming the children for stealing some and fatten. Sure they are inexperienced, but it makes the learning curve stepper and requires refactoring. And like I told you, graphical refactoring not only involves algorithm logic, but also VI placement and wire routing. This is an insane amount of work, especially when you replace a gone coder. You can always blame people, things are Labview permitted lazyness in the first place.
Now we are in agreement!
Just to prove that last point:
- Hire NI Certified LabVIEW Consultants to avoid the cost of making every mistake thats been made before.
- Encourage participation in the Online Training that your company has paid for with the license. Guess why NI SELLS it that way? -- TO HELP YOU!
- DON"T BE a lazy programmer! They abound in every language and their product is often difficult to read maintain or interface with
This was written BY ME earlier today where I saw a grotesque text coding weenies enum type def
CLAs are using Labview in a certain way, and I won't push the enveloppe to pretend they inherently hold the truth. Sure they have capitalized experience over the years, but again, that's not Labview's audience, it is for people that used not to code, or people coding with text based programming languages. Don't ask people to come into a new way to code stuff with limited tools and avoid the holes on the ground.
I think I've covered that! The tools are available- Help file, Example finder, Online training, Certifications that are relavant, and the forums. WOW thats a lot of $ invested by NI. Have you seen a Certified C++ Developer? tried MSDN Help? How do they compare to NI offerings?
Stop whining and use the tools you have.
@Kochise wrote:
This issue, again...
Let me clear some misconceptions here :
1- Having everything in one screen.
Coding in C/C++, you're also asked to write everything down in one screen and use subroutines, each fitting one screen to avoid having to scroll up/down. Hey buddies, we've got graphic screens, scrolling windows area and a scroll wheel on mouse for years now, that shouldn't be considered an issue. If you cannot read and mentally interpret a code larger than the screen, I just wonder how you managed to imagine your algorithm without paperboard in the first place. Really, if you cannot do that, you shouldn't develop anything, you should quit that.
Like it have been pointed out, the different screen factors doesn't help much, we're not working on 640x480 resolution anymore, and you wouldn't have fitted many things on such low screen estate anyway. If someone use this "should fit the screen" argument then he's a very very lazy person with little imagination and adaptation to real-life problem/challenge. Sometimes you need to have a more global vision of a graphical algorithm to get the idea, and cutting it into pieces is NOT a good option :
http://www.ni.com/cms/images/devzone/pub/nrjsxmfm912163998723206173.jpg
That's the graphical programming fate, just live with it instead to say it's a bad coding practice. If LabView has to be limited to thumbnail-sized coding for newbies, this programming toy is rather expensive.
Note, even smartphones and tablets have FullHD resoltion on 5" screen, imaging doing LabView coding on these devices without zooming in. Even if it's highly hypothetical, that limits LabView's use.
I don't know if I can go with the one-screen deal. It's kind of like the old, outdated advice about making UI no larger than 800 x 600 in order for it to be able to be displayed at standard SVGA. On the other hand, good programming practices lead to a BD that will display completely on almost any size screen. I know I've said this many times before, but if you have to use more than a paragraph or two to describe a VI, it's probably too big. This goes for the main VI, too!
2- Using sub-VIs (sub-routines).
Yeah, good idea, let's scater the algorithm into a trizillion sub-VIs with many of them having only a little difference in their input/output parameter. You'll finish with a huge sub-VI library you'll spend most of you time to navigate through in order to find the suitable sub-VI. I'm running against this very issue, having printed the company's sub-VIs list in 9px on... 25 pages. Good Lords! Sure, once you know them it's quicker, but modify one for your specific use, you have to make another copy of it not to break legacy code. Bam, you get a trizillion + 1 sub-VIs. And if you quit the company, imagine the code maintenance mess you leave behind.
If you need to modify a subVI for specific use, you haven't really planned ahead for scalability. Granted, you can't think of everything, but with a little anticipation about what it could be used for, you won't run into this problem very often. It often takes more time to make the SubVI more scalable, but it will save time in orders of magnitude down the road.
I won't go into the hassle of searching for a string into the bunch of sub-VIs or anything else, doing refactoring using a simple regexp based search/replace and stuff. I prefer having everything into on VI that I could take under the arm without having to take the whole library with me to make sure I not forgot one or two sub-VIs in the process, going to the client's site only to find that some pieces of the puzzle are missing for the customization/compilation.
That's what the Project Explorer is for. Use folders (I prefer virtual because it's a lot easier to reorganize if you need to). That way things stay nice and tidy. Libraries are good ways to organize reusable code. If you only expose the top level VIs, developers won't have to sift through all the subVIs. One thing I will say, it makes it difficult to document if you have to document every subVI and explain what it does (but then it's just tedious cut n paste if you've been properly documenting your subVIs).
3- Zooming in/out will break 30 years of code.
Really guy, what have to do the software architecture to see with the display ? I mean, have you guys ever heard of MVC ? How do vectorial editing program works in the first place ? Take for instance a PCB editing program and say that zooming in and out would break the routing algorithm, and is of little use to edit the actual schema/routing. I beg to differ, zooming in and out IS as useful in these programs as in would in LabView, both are GRAPHICAL editing programs. The simple fact that you have a navigation window with a zoomed out view prooves that you can do it.
I don't believe LabVIEW uses vector graphics, so it would indeed be a major overhaul. CAD programs use vector graphics - drawn lines - that are easily scaled. I hope that maybe someone can actually shed more light on that topic.
All a zoomed-out navigation window proves is that you can build a picture from the code and use it to scale mouse coordinates to move to another part of the code.
And if in 30 years you cannot implement such highly expected feature is you are either very incompetent (I bet there are capable coders available for hire) or you just don't give it a damn about your customers, you just limit yourself to selling yearly license renewal with a pinch of bug fix and one or two new functions to justify the cost. It reminds me just how InstallShield works...
Sour grapes? Why not ask NI for the source code to LabVIEW and let you take a crack at it? Or are you afraid of being incompetent?
So, I'd like the people to stop asking NI to implement this feature in LabView, it's really boresome. If they really cared they would have for ages instead to use crappy excuses and fallacy. They have the hand on the source code, it haven't quite changed for years not because it is hard to maintain (if it really is they should fire the software architect in the first place) but because it would change the user's experience (for the best, but that's not what they are really looking for, don't they ?)
My solution, just SWITCH of programming language, quit moaning or ask NI to offer you a 84" screen with every LabView seat.
Now you're just being silly.
David KOCH, a little bit upset (but you've figured it out)
