BreakPoint
LabView vs LabWindows/CVI
@smercurio_fc wrote:
...
OK, so what was the original point of this thread?
Still exploring LV vs CVI but now taking a side track to try to C the differences between those that C and those that don't C.
Ali65 wrote;
Ben,
2 Software could be used by not experts? Usually not
...
1 It depends on the area of use. The software what is used to design a nuclear reactor, should only be used by a small group of experts. The same software if used to design a flyer about a missing dog, should be used by large group of experts.
I cannot recognize OR relationship between 1 and 2.
Ali
Yes I understand that was not a formal "OR" condition. My intent was to learn how you look at software to help understand you and understand why the disucusion is going two different directions.
From your reply above and your previous I hear you speaking about what software SHOULD be. Christian's reply spoke of what software COULD be.
If I am reading you correctly (probably not but that is part the fun of interacting with people when you can't see their face or observe their body language 
), C and similar dirivatives are close to what you believe software SHOULD be and LV and other graphical languages are simply abomanations that should be quashed before they take root spread or worse, displace C.
Please don't take offense in my attempt to understand your message, please! I do the same thing to my buddies (at least the ones that can stand it).
Ben
@Ali65 wrote:
Not necessary C, but I believe software SHOULD be defined in some text based language. Boxes, icons and lines and similar type of visualizations based on graphics present an overhead which are tolerable only for trivial tasks. I totally agree that some visual type of thinkers can easier remember the algorithm if they saw it in graphics, especially the trivial examples. I am that kind of person too.
So you think that designing and planning a huge program should be done using only linear text, or would a flowchart be more appropriate?
What some people fail to grasp is the fact that a LabVIEW diagram is actually much closer to the final machine code than any text based language can ever be. The compilation does not go through an intermediary step that involves text based code.
It is a horrible abstraction to require the programmer to formulate his ideas as a single long linear monochrome string of printable characters delimited by linefeeds. This is very limiting, but this is what text based code is! Think about it.
Why would you force yourself through such an uncomfortably confined detour when going from brain to silicon???
Like everything, programming has evolved, and for me, LabVIEW has percolated to the top of the list. Show me another language that can run seamlessly also on FPGA (I am sure you like VHDL much better though! :D) and embedded targets.
Our retina is 2D and the human brain is extremely well optimized to recognize shapes and 2D and 3D relationships. Tapping ito this power to device a programming tool is literally a no-brainer :D. After you read a book, do you remember the words or the visual imagination triggered by reading them?
Knowledge and skills have evolved over the centuries and the tools need to evolve too. It would be very difficult to do linear algebra using roman numerals these days.
Sure, text based code had some advantages and 50 years ago it would have been difficult to do graphical programming because of lack of hardware support (display, input, etc.). Text based code is also easier to transmit by telegram. The times where these advantages matter are over!
@altenbach wrote:
@Ali65 wrote:
Not necessary C, but I believe software SHOULD be defined in some text based language. Boxes, icons and lines and similar type of visualizations based on graphics present an overhead which are tolerable only for trivial tasks. I totally agree that some visual type of thinkers can easier remember the algorithm if they saw it in graphics, especially the trivial examples. I am that kind of person too.
So you think that designing and planning a huge program should be done using only linear text, or would a flowchart be more appropriate?
What some people fail to grasp is the fact that a LabVIEW diagram is actually much closer to the final machine code than any text based language can ever be. The compilation does not go through an intermediary step that involves text based code.
It is a horrible abstraction to require the programmer to formulate his ideas as a single long linear monochrome string of printable characters delimited by linefeeds. This is very limiting, but this is what text based code is! Think about it.
Why would you force yourself through such an uncomfortably confined detour when going from brain to silicon???
Like everything, programming has evolved, and for me, LabVIEW has percolated to the top of the list. Show me another language that can run seamlessly also on FPGA (I am sure you like VHDL much better though! :D) and embedded targets.
Our retina is 2D and the human brain is extremely well optimized to recognize shapes and 2D and 3D relationships. Tapping ito this power to device a programming tool is literally a no-brainer :D. After you read a book, do you remember the words or the visual imagination triggered by reading them?
Knowledge and skills have evolved over the centuries and the tools need to evolve too. It would be very difficult to do linear algebra using roman numerals these days.
Sure, text based code had some advantages and 50 years ago it would have been difficult to do graphical programming because of lack of hardware support (display, input, etc.). Text based code is also easier to transmit by telegram. The times where these advantages matter are over!
There are many examples when visualization is good.
I just feel bad if I have to enter or store data or algorithm in visual format.
For that purpose text works better.
You need to distiguish two different aspects:
- What was used to write some of the compiler tools.
- What happens to your LabVIEW diagram code when it gets compiled.
