03-09-2012 06:10 PM
Thanks for the lively discussion. I do think it's good to bring this up every 6 months or so, and I'll probably be back again with something in yet another 6!
One last thought from me... it seems that in any language, programmers should spend more time performing actions relevant to functionality and less 'overhead' time related to the environment. It is hard to deny that a fair amount of time is spent readjusting block diagrams, drawing VI icons, wiring up VIs, and drilling down in to lower-level VIs to access functionality (and dealing with the corresponding window overload). These actions represent a significant mental 'hiccup' that can be a distraction and reduces the fluidity of the programming experience. Most of the solutions to this problem have come from adding efficiency tools on top of the language, which to me has tended to bloat the environment rather than increase its elegance (quick drop, however, is definitely my favorite efficiency tool... would love to see more work in that direction). Extending back at least as far as LV6 (what I started with), the fundamental graphical constructs have remained as they are. If you could imagine a kind of ratio, something like "time per functional implementation", LabVIEW is relatively weak here. This to me really lies at the heart of my frustration with the environment. What I am most interested in is any efforts from NI to attempt a change in fundamentals... is there a way to completely rid the environment of the icon editor? Make it so you never have to resize a block diagram or perform significant time with 'wire management'? Why is it that in a state machine, one state may be crammed full of VIs and wires, and the next is filled with empty space? You pack less information in to a single eye-shot this way, and your screen is filled with superfluous information. With text, rearranging or duplicating code is a simple cut-and-paste and a bit of tabbing. Everthing you look at has true functional significance and none of the fat. Comments can be verbose and are inherently linked to functionality, rather than autonomous graphical blocks that clutter the functional space. Jumping from one bit of functionality to the next is a simple matter of scrolling, not opening up and hunting through a multitude of windows or hunting through drop-down menus and cases in a case structure. A graphical language should be able to pack 'more' information in to a single view in a way that is sensible, but this is not the case with LV.
03-09-2012 09:33 PM - edited 03-09-2012 09:38 PM
It should be no purprise I've been following the discourse.
@Norbet- Well defended
@Steve- Well stated
@Ben- you did not go far enough, I'll chime in
@Sny~ you did not make a case or express your views clearly (not uncommon on the forums)
~~~~shaking the "magic 8-Ball~~~
(you may safely stop reading here- but if you have the fortitude to stick with it I may take you someplace productive)
<<FLASH it is the year 1912>>
The most powerful computational apparatus is the abacus and slide rule. The felt tipped marker was invented 2 years ago. Thomas A. Edison designed and built the Chicago "EL" terminus switching computer with mechanical relays and cams for the levers (GUI) in this era.
<<BOOM>>
1962- JFK is POTUS. The "Space Race": is underway- we need better computers (Until now, "Computer" was a JOB title for a "Mathematician")
<<Zip>>
1987- some people have been hearing about a new Laboratory tool that "virtualized an engineering instrumentation workbench"
!!Back that up a bit!!
What really happened in that last 75 years? It took several types of a genius (T.A.E) to develop that computerized control system for the Chi-town rails. Alhough it still WORKS, when I left the CNW, nobody dared to attempt to refactor the software. The "Language" is unique and highly coupled to the hardware.
FAST forward to myself today. I was following this thread on my 4Glte Phone and thinking to myself two things:
Now! some of you are guessing the thrust of my response- Why do I need a keyboard? Because TODAY, I must type text to transmit my thoughts. In 1962 I needed carbon paper and a ball-point pen. In 1987 I needed a 600 baud modem and a tractor feed printer. In 1912 I needed relays, cams and rail-road tracks or a felt tipped pen. In 1812 I needed a Quill.
In 2037.... Well, I don't believe I'll need a keyboard or mouse Just like I no longer need a terminal or daisy wheel printer (both af which I've used, at 77 WPM).... G and LabVIEW are much farther down that path than VB, C#, JAVA.... Will LabVIEW be eclipsed or will it continue? Let's find out together- without looking back.
@Mark- Last evening I had a conversation at the LUG that went-
R:[We] write in a "Real programming language- even the compiler is written in ...
Jeff Bohrer: A lot of LabVIEW IS written in LabVIEW.
R:But still the compiler....
Jeff Bohrer: Well- "Real Languages" (Meaning powerful ones) use the dataflow paradigm.
R: That paradigm is powerful- how can it......
I Hope you all stopped reading.
03-09-2012 09:57 PM
I don't really have anything new to say, so here are some of my earlier thoughts on the subject: 😄
Given all imaginable ways to compose ideas into a form that the compiler can understand, text is very low on my list. 😉
03-10-2012 05:05 PM
03-12-2012 10:29 AM
@Synaesthete wrote:
Thanks for the lively discussion. I do think it's good to bring this up every 6 months or so, and I'll probably be back again with something in yet another 6!
... What I am most interested in is any efforts from NI to attempt a change in fundamentals... is there a way to completely rid the environment of the icon editor? Make it so you never have to resize a block diagram or perform significant time with 'wire management'? Why is it that in a state machine, one state may be crammed full of VIs and wires, and the next is filled with empty space? ...
Somehow the diagrams I am looking must dffer greatly from the ones you are looking at.
Here are two screen shots from a recent project where the icons are very useful, no wire management issues and no over-loaded states.
So plese post some images to help us understand where you are coming from.
Ben
03-15-2012 12:56 PM
Ben-- I'll get back to you on that.
To hone my little attack on LV, a related critique comes to mind...
Is LabVIEW designed for non-programmers who want to get started quickly, or is it meant as a graphical alternative to professional programming?
In its current state, I feel that the answer is "both", yet I don't think these two types of users are being fully addressed. The original intent of the language was to be a language for non-programmers, yet has expanded in its scope and feature-set to address professional programmers. From my experience teaching the course, it has reached a state where it is as difficult to learn as a text-based alternative, so at this point we can forget about its use as a language for non-programmers.
Yet the graphical elements in LabVIEW have been designed for non-programmers. There is a correspondence between the graphics and the underlying programming structures (loops, etc.) that are meant as graphical aids for the non-programmer. For the professional programmer, you should be less interested in visual aids and more interested in programming efficiency. I like the idea of graphical programming, but there's a difference between effective graphical semantics and graphical aids; the LabVIEW language is more about the latter.
The state-of-affairs with the LabVIEW platform is that it is a messy mash-up between these two philosophies. It is too complex for the non-programmer and too inefficient and inexpressive for the professional programmer (this last bit being the focus of the previous discussion).
What I believe should happen is that professional programmers should return to text-based alternatives, and perhaps a more efficient graphical language could develop out of that, something not necessarily based on LabVIEW. Alternatively, LabVIEW should return to its roots as a language for the non-programmer... most of the advanced 'computer science' features should be removed, and the idea of the "Express VI" should be expanded and improved to the point that it is actually a practical, effective solution for the non-programmer (currently, it just plain sucks).
The "professional LabVIEW programmer" is a rare bird, yet on these forums and in the idea exchange they have a very loud voice, and have profoundly impacted the development of the LabVIEW language. I believe this is damaging to the concept of graphical programming and damaging to the possibility of a 'simple' graphical language. If it continues down this path, I believe it will see less adoptability and become increasingly esoteric, loved by a select few.
03-15-2012 01:15 PM
@Synaesthete wrote:
Ben-- I'll get back to you on that.
To hone my little attack on LV, a related critique comes to mind...
...
The "professional LabVIEW programmer" is a rare bird, yet on these forums and in the idea exchange they have a very loud voice, and have profoundly impacted the development of the LabVIEW language. I believe this is damaging to the concept of graphical programming and damaging to the possibility of a 'simple' graphical language. If it continues down this path, I believe it will see less adoptability and become increasingly esoteric, loved by a select few.
Since my previous post I have been asked to port a .NET based dll to LV.
I was provided with an example in C.
It reminded me just how criptic C can really be when the developers fail to document their work. The big feature C has going for it is "job security" since only a "professional developer" would/could touch it in a cost effective manner.
Speaking only about my own viewpoint... I have ridden enough technologies to their death that I have no desire for a fleating idea like job security but am more interested in looking for that next wave to take me to the beach called retirement.
LabVIEW is the surf baord I stand on now. Will it get me to beach?
Ben
03-15-2012 01:21 PM
Honestly, I have no idea where you're going with your statements, or whether to even take them seriously.
Is LabVIEW designed for non-programmers who want to get started quickly, or is it meant as a graphical alternative to professional programming?
In its current state, I feel that the answer is "both", yet I don't think these two types of users are being fully addressed. .
You're confusing how LabVIEW is designed, vs how it's marketed. Those of us who have used LabVIEW for a long time know that it is a programming language first. Even with the incorporation of Express VIs, it doesn't make it "designed" for non-programmers, and it never will. However, don't tell that to marketers, who are just trying to sell a product. A salesman will always tell you the product they sell will solve all your problems. If they don't, they're soon out of a job.
From my experience teaching the course, it has reached a state where it is as difficult to learn as a text-based alternative, so at this point we can forget about its use as a language for non-programmers.
So you've extending your own personal experience to make a general statement about the state of the universe? I'm not sure if this is naivete or pure ego. I have actually found the exact opposite. Does that mean I'm a better teacher?
Yet the graphical elements in LabVIEW have been designed for non-programmers. There is a correspondence between the graphics and the underlying programming structures (loops, etc.) that are meant as graphical aids for the non-programmer.
And your proof for this statement? Does the Type Cast function look like it was designed for a "non-programmer"? And if there is a correspondence, so what? What exactly does that prove?
The state-of-affairs with the LabVIEW platform is that it is a messy mash-up between these two philosophies. It is too complex for the non-programmer and too inefficient and inexpressive for the professional programmer (this last bit being the focus of the previous discussion).
Once again, a statement with no data to back up the claim. What do you mean by "too complex for the non-programmer"? Who claimed that LabVIEW wasn't a programming language in the first place? Is C# "too complex" for non-programmers? Is Perl "too complex" for non-programmers? How about Java? Or maybe we should all be using Visual Basic, since that's clearly a language that's "simple" for the non-progammer. But then, perhaps that's why it's ridiculed so much.
And as far as the "too inefficient and inexpressive for the professional programmer", this is simply ludicrous. Time and again benchmarks have shown that LabVIEW is on par with C as far as code efficiency. This data exists. Yet you make the opposite claim and offer no evidence. And I have no idea what you mean by "inefficient".
What I believe should happen is that professional programmers should return to text-based alternatives,
Then go right ahead. Have fun.
03-15-2012 01:29 PM
@smercurio_fc wrote:
The state-of-affairs with the LabVIEW platform is that it is a messy mash-up between these two philosophies. It is too complex for the non-programmer and too inefficient and inexpressive for the professional programmer (this last bit being the focus of the previous discussion).Once again, a statement with no data to back up the claim. What do you mean by "too complex for the non-programmer"? Who claimed that LabVIEW wasn't a programming language in the first place? Is C# "too complex" for non-programmers? Is Perl "too complex" for non-programmers? How about Java? Or maybe we should all be using Visual Basic, since that's clearly a language that's "simple" for the non-progammer. But then, perhaps that's why it's ridiculed so much.
And as far as the "too inefficient and inexpressive for the professional programmer", this is simply ludicrous. Time and again benchmarks have shown that LabVIEW is on par with C as far as code efficiency. This data exists. Yet you make the opposite claim and offer no evidence. And I have no idea what you mean by "inefficient".
It should also be noted that there are several studies that have shown that developing in LabVIEW is more productive than writing text based programs. Naturally the assumption is that both sets of programmers are comparable in their level of expertise within the given language.
From personal experience I hav e time and again seen how I am more productive in developing code in LabVIEW than in a text based language. Granted, this is my personal experience but as stated above there is data to back up that statement.
03-15-2012 01:46 PM
@Synaesthete wrote:
What I believe should happen is that professional programmers should return to text-based alternatives, and perhaps a more efficient graphical language could develop out of that, something not necessarily based on LabVIEW.
Plenty of graphical programming languages exists and in the mid nineties there was a big shakeout between e.g. LabVIEW and HPVEE and others and LabVIEW won hands down. (When I started with LabVIEW, HP constantly pestered me with demo software, trying to convince me to switch. I really tried, but LabVIEW was so much more versatile. ;)) Recently Google has adapted scratch as their appinventor for programming simple android code. While it has some interesting properties, it is basically line based code where the lines and structures are pre-formed puzzle pieces to be fit together hierarchically.
LabVIEW has received very wide adoption among professional programmers in all technical areas. As an example have a look at the mission control room at SpaceX, so I am not sure why you think professional LabVIEW programmers are only a fringe group.
I agree that personal preferences vary and fortunately people like you have a choice and go text only. Van Gogh would never have written "War and Peace" and Tolstoy would have never painted "Starry night". Some people are linear thinkers while others think in graphical terms, and, like in the gay vs. straight debate, these dispositions cannot be changed in general.
That said, LabVIEW fits me like a glove and would would not want it any other way. I think administrative actions, such as intentionally cripple LabVIEW so programmers will flee to text based code is NOT a sane suggestion (exagerrating what I understood you said above). You would mess with evolution!
LabVIEW has 25+ years of refinements and is in its current state a fantastic and full featured programming environment and will continue to evolve. Show me any other prgramming envoroment where you can seamlessly program from desktop to embedded to FPGA without need to re-learn much.
Hundreds of very bright minds at NI have refined LabVIEW to its current state and it would be hard to come up with an entirely new graphical programming concept that would be better. Many have tried! If you start now with lots of effort and resources, you might have something similarly useful in 25 years. It probably won't be "more efficient" as you would have liked. But by that time LabVIEW will be fully 3D with a pure gesture interface. Just kidding....maybe. 😄