Quote:
|
E/ Just noticed your signature. Of course you cant diss LV when you're getting paid to write it!
|
Oh, I diss it plenty, but then we go about trying to improve it.
The story about the professional C++ programmer trying to do image processing was simply a counter example. She was fast at typing code. She could add print statements super fast. But they weren't the correct tool. By the way, the probe in LV is where you right-click on a wire, choose probe, and a window opens to show you the live image at that point in the processing chain. The program keeps running, you can move the target, focus the camera, tweak the panel values, add an additional probe, etc. It isn't a language feature, but an IDE feature because NI and LV sell tools to do this sort of thing. We also used to sell a C/Basic IDE and compiler, but that is now simply a library that plugs into MSVC.
Quote:
|
but my main point is that if you're promoting the usage of LV as a language "used in industry," it seems misleading to someone who has no idea of the difference between languages. If you're planning on going into the industry with skills in programming, there are more diverse work options when you're working with a more well-known language.
|
The "used in industry" or "most popular" judgements don't carry much weight with me either. I think it is better to identify a strategy for evaluating the tools on a realistic task. Evaluate, choose, use and become proficient.
New task? Rinse and repeat. There is overhead in learning a new tool, and overhead in using the wrong tool for the job. Find the balance.
The evaluation period can involve asking for popularity or opinions, but that only gets you so far. If we substitute music for robots, which instrument would you learn? Is it a waste of time to learn how to play an instrument that isn't popular? Learning musical notation, theory, and lingo are valuable whether you learn the violin or piano, but neither will work well in a marching band.
Quote:
|
and wouldn't even dare writing in LV
|
I think the topic here is productivity, not typing speed. The ability to progress from a problem statement to a reliable solution is common to much of engineering, industry, and life. LV's initial adoption was actually in instrument control. Composing and parsing packed arbitrary streams from oscilloscopes, DMMs, signal generators, scales, power supplies, etc. Programs would then be written to setup, evaluate, and sequence the instruments to automate repetitive testing. It is not that different from what you posted. So others have dared, succeeded, and their code has been running for decades.
As for the performance of the vision code:
By design, NIVision is divided into an inner library of kernel functions and outer rings of language wrappers. 98% of the processing time will be spent in the same code regardless of which language you choose. There will be some differences in allocation overhead and your own logic as to which operations to perform.
Back to the original topic. My goal is to get teams to learn a bit more about programming, computers, measurements, and control. And that means everyone on the team, not just the programmers. I kinda hope that all the robots don't look the same. I kinda wish they were more automated and more autonomous. I don't work in marketing or sales, so this popularity contest isn't really that exciting to me. I see amazing robots programmed in all three languages. And all the time I get to see kids gain confidence as circumstances require that they become the team programmer at the event and make the robot do stuff they didn't think they knew how to do.
Greg McKaskle