7 ms·

everybody always seems to ignore the most advanced and general purpose visual programming language/environment, that being labview. i suppose it is probably bec

everybody always seems to ignore the most advanced and general purpose visual programming language/environment, that being labview. i suppose it is probably because it sits behind an expensive license.

NotPhysicsPhd 7y ago
I would add that not only the license is quite expensive, but it has a confusing "syntax" that most often than not results in unmaintanable software.
- nikofeyn 7y ago
  > it has a confusing "syntax" that most often than not results in unmaintanable software that is more that most people who program it don't put in the time or effort to program it in a professional way. personally, i do and was trained by people who did and do, and so i have seriously complex systems built out of it that are far more maintainable than other people's systems built out of python and c/c++, which are the unfortunately choices for system development where i have worked. the point is, just like with any language, you have to settle on the (or an) idiomatic way of working in the language, and you have to be disciplined to develop modular, decoupled code. once you do so, i find that labview's dataflow paradigm actually makes it easier than most languages to develop dependable, robust, and maintainable code. the reasons that people like functional programming languages with immutability apply to labview. people writing unmaintainable software in labview is a symptom of the people and not the language. every time labview is brought up in meetings as the target language, there is often a gut reaction by people, but to be frank, those people actually know very little of the labview language, have never used its OOP features, are not even aware of its debugging capabilities and tools, and thus, their opinion is moot. just because someone used labview in college in a trivial way but didn't like it doesn't give them a professional voice with regard to labview. all they usually want to do is develop unreliable systems using c/c++ or python because that's the "hardcore" way of doing things. and yet, it's those projects that are often pining for help in the end when things aren't working. so yes, labview is different, but if you treat it differently, it can greatly increase your efficiency and ability to quickly turn around robust systems. i develop systems in time units of months, not years, and my software is well known to just work. what would you say the "confusing syntax" is that leads to unmaintainable software?
  - NotPhysicsPhd 7y ago
    You are absolutely right and I should have been clearer on my first reply. Most of my contact with LabView code was built by people that had no professional training on it. They use it to automate "simple" scientific experiments and create visualization dashboard, since they're mostly self-taught their software needs a re-write every 3 years. Again I believe you are right, that is mostly due to the programmer not being knowledgeable about the language itself. Regarding the syntax, most of the LabView code I've seen was built by people with the aforementioned knowledge of the language, so It is possible that I've never seen good LabView code. But I never liked the looping and conditionals.
DonaldFisk 7y ago
While doing research for my own dataflow language, I've had a look at LabVIEW. There's plenty of online documentation available, but I didn't like some of its design choices, e.g. how iteration and conditional statements are done is overly complex. There are natural ways of doing these in dataflow which LabVIEW doesn't use. Also, type inference is actually simpler to implement in visual dataflow than it is in text-based languages, yet LabVIEW lacks it (unlike Luna, and the dataflow language I'm still developing). Finally, every dataflow program is a directed graph, which is the most general data structure there is, so it really ought to be a fundamental data type - like Lisp's S-expressions are. However, LabVIEW is one of the oldest visual dataflow languages (AFAIK only Prograph is older), and it's certainly worth learning about if you're interested in visual and dataflow programming.
- nikofeyn 7y ago
  > I didn't like some of its design choices, e.g. how iteration and conditional statements are done is overly complex. There are natural ways of doing these in dataflow which LabVIEW doesn't use. would you mind elaborating? i would be interested to see what you mean. if you are thinking of more functional ways like maps, filters, folds, and the like, i have done that in labview. there is limited support though since labview doesn't have lambdas, but you can pass around functions. however, that being said, i don't really see a problem with the for and while loops in labview, and i can't see how they are overly complex. they are about as simple as it gets. condition structures could be improved, but i also don't quite see a vastly different way to do it but rather tweaks that could be made. > Also, type inference is actually simpler to implement in visual dataflow than it is in text-based languages, yet LabVIEW lacks it i am not for sure what you mean here by saying labview doesn't have type inference. labview is constantly running a type propagation algorithm that checks whether all the types are hooked up correctly. additionally, labview has malleable VIs, which is even more advanced. you can develop functions that are polymorphic across types. you could do this before malleable VIs using polymorphic VIs, but you had to manually create them. now, when wiring a type to a malleable VI, labview will dynamically (at edit time) adapt the malleable VI's types, primitives, and subVIs to adopt the new type. if it can't, it will warn you. you can also wrap code with a type structure such that different code is tried depending upon the type. again, it will check if a wired up type has a given structure case that fits. it is similar to pattern matching on types. > Finally, every dataflow program is a directed graph, which is the most general data structure there is, so it really ought to be a fundamental data type - like Lisp's S-expressions are. i agree that there should be a more fundamental type. i am not aware of any language that does so, and even in the text-based world, lisp and scheme stand alone in this feature (not surprising i like those languages as well).
JPKab 7y ago
Alteryx is another one, and it's super popular in the business world. LabVIEW is limited to the research and academic realms AFAIK.

NotPhysicsPhd 7y ago

I would add that not only the license is quite expensive, but it has a confusing "syntax" that most often than not results in unmaintanable software.

nikofeyn 7y ago
> it has a confusing "syntax" that most often than not results in unmaintanable software that is more that most people who program it don't put in the time or effort to program it in a professional way. personally, i do and was trained by people who did and do, and so i have seriously complex systems built out of it that are far more maintainable than other people's systems built out of python and c/c++, which are the unfortunately choices for system development where i have worked. the point is, just like with any language, you have to settle on the (or an) idiomatic way of working in the language, and you have to be disciplined to develop modular, decoupled code. once you do so, i find that labview's dataflow paradigm actually makes it easier than most languages to develop dependable, robust, and maintainable code. the reasons that people like functional programming languages with immutability apply to labview. people writing unmaintainable software in labview is a symptom of the people and not the language. every time labview is brought up in meetings as the target language, there is often a gut reaction by people, but to be frank, those people actually know very little of the labview language, have never used its OOP features, are not even aware of its debugging capabilities and tools, and thus, their opinion is moot. just because someone used labview in college in a trivial way but didn't like it doesn't give them a professional voice with regard to labview. all they usually want to do is develop unreliable systems using c/c++ or python because that's the "hardcore" way of doing things. and yet, it's those projects that are often pining for help in the end when things aren't working. so yes, labview is different, but if you treat it differently, it can greatly increase your efficiency and ability to quickly turn around robust systems. i develop systems in time units of months, not years, and my software is well known to just work. what would you say the "confusing syntax" is that leads to unmaintainable software?
- NotPhysicsPhd 7y ago
  You are absolutely right and I should have been clearer on my first reply. Most of my contact with LabView code was built by people that had no professional training on it. They use it to automate "simple" scientific experiments and create visualization dashboard, since they're mostly self-taught their software needs a re-write every 3 years. Again I believe you are right, that is mostly due to the programmer not being knowledgeable about the language itself. Regarding the syntax, most of the LabView code I've seen was built by people with the aforementioned knowledge of the language, so It is possible that I've never seen good LabView code. But I never liked the looping and conditionals.

DonaldFisk 7y ago

While doing research for my own dataflow language, I've had a look at LabVIEW. There's plenty of online documentation available, but I didn't like some of its design choices, e.g. how iteration and conditional statements are done is overly complex. There are natural ways of doing these in dataflow which LabVIEW doesn't use. Also, type inference is actually simpler to implement in visual dataflow than it is in text-based languages, yet LabVIEW lacks it (unlike Luna, and the dataflow language I'm still developing). Finally, every dataflow program is a directed graph, which is the most general data structure there is, so it really ought to be a fundamental data type - like Lisp's S-expressions are. However, LabVIEW is one of the oldest visual dataflow languages (AFAIK only Prograph is older), and it's certainly worth learning about if you're interested in visual and dataflow programming.

nikofeyn 7y ago
> I didn't like some of its design choices, e.g. how iteration and conditional statements are done is overly complex. There are natural ways of doing these in dataflow which LabVIEW doesn't use. would you mind elaborating? i would be interested to see what you mean. if you are thinking of more functional ways like maps, filters, folds, and the like, i have done that in labview. there is limited support though since labview doesn't have lambdas, but you can pass around functions. however, that being said, i don't really see a problem with the for and while loops in labview, and i can't see how they are overly complex. they are about as simple as it gets. condition structures could be improved, but i also don't quite see a vastly different way to do it but rather tweaks that could be made. > Also, type inference is actually simpler to implement in visual dataflow than it is in text-based languages, yet LabVIEW lacks it i am not for sure what you mean here by saying labview doesn't have type inference. labview is constantly running a type propagation algorithm that checks whether all the types are hooked up correctly. additionally, labview has malleable VIs, which is even more advanced. you can develop functions that are polymorphic across types. you could do this before malleable VIs using polymorphic VIs, but you had to manually create them. now, when wiring a type to a malleable VI, labview will dynamically (at edit time) adapt the malleable VI's types, primitives, and subVIs to adopt the new type. if it can't, it will warn you. you can also wrap code with a type structure such that different code is tried depending upon the type. again, it will check if a wired up type has a given structure case that fits. it is similar to pattern matching on types. > Finally, every dataflow program is a directed graph, which is the most general data structure there is, so it really ought to be a fundamental data type - like Lisp's S-expressions are. i agree that there should be a more fundamental type. i am not aware of any language that does so, and even in the text-based world, lisp and scheme stand alone in this feature (not surprising i like those languages as well).

JPKab 7y ago

Alteryx is another one, and it's super popular in the business world. LabVIEW is limited to the research and academic realms AFAIK.