that sounds like the software design itself was at fault. labview is a programming language. if one writes poor code, then labview can't magically fix that. si

that sounds like the software design itself was at fault. labview is a programming language. if one writes poor code, then labview can't magically fix that. since labview is dataflow and has static typing, it shares a lot in common with functional languages. this means you can trace your data and execution in a very deterministic manner. i often write code that just works. there are almost always no bugs in the final software. that's almost impossible in python. labview also has OOP, which any respectable labview developer uses heavily on any project. for larger projects and systems with concurrent processing needs, it's multithreaded features and actor framework are necessary. labview makes it easy to code simple projects, and so people don't treat it with respect. labview code is often written by non-software engineers, who will write poor code in ANY language. people seem to forget that. if one treats labview as any other language and with respect from the perspective of a software engineer, then it has a lot of functionality that is very difficult to replicate in other languages. for example, async is all the rage these days, including in python. labview has had that functionality for many years now. and the dataflow paradigm pays off big time. labview is different and people don't respect it. that's okay, because i do which makes me pretty valuable and quite efficient. and i do think labview could be improved. it's just i wouldn't put any effort into python, especially for real embedded systems. many, many languages out perform it in many vectors.