New blog category: LabVIEW

I’m throwing my hat into the ring.  There are many smart people out there blogging about LabVIEW, and for a couple of years now I’ve wondered if I had anything to add to the LabVIEW community by creating my own LabVIEW blog.  I think the answer is a definite maybe.  🙂   The tipping point for me was the introduction of the blog venue on our own website.  Now I don’t have to think in terms of “do I have enough LabVIEW topics I want to write about in order to justify creating a blog”, I can just write what I’m thinking as one part of a wider purpose blog and if somebody finds it interesting, great.  So here we go:

Call me a nerd, but I love LabVIEW.  LabVIEW is a graphical programming language.  No, I don’t mean you create graphics with it.  It’s a programming language, but instead of typing cryptic words that hardly resemble english, the source code is graphical.  It’s a series of icons linked together by wires, kind of like a circuit board, but the wires carry information instead of electrons.  LabVIEW is very powerful in that with relatively little coding you can achieve a lot of functionality very quickly.  It’s easy because the Integrated Development Environment (IDE) has an event-driven, non-intrusive compiler, so you always get immediate feedback when a compile error exists instead of waiting till later and crossing your fingers.  And it’s fun because you have the building blocks at your finger tips and all you have to do is assemble them in the right configuration to solve problems.  It feels a lot like solving puzzles rather than work.

I’ve been very fortunate to be able to make a good living doing work that I really enjoy, and most of that job satisfaction is directly attributed to LabVIEW.  I have a hard time not being a work-aholic in part because I enjoy my job so much.  Why stop what I enjoy doing?  If I had more free time at home I would spend even more time on LabVIEW forums learning about what other users are doing with LabVIEW, both as a way to further develop my own skills and as a way to network with other LabVIEW enthusiests.  But alas, there are only 24 hours in a day and there are so many things I want to do.  I regret that I don’t get to spend more time contributing to the LabVIEW user community, but I think it’s the right decision for me at this time in my life.

Some people may call me crazy, but let me share my heart with you.  I actually think that God has a calling on LabVIEW, and that I am playing some part in it by advocating LabVIEW to staunch Software Engineers who refuse to take graphical programming seriously, too much of a paradigm shift for some to overcome; and by promoting it to future Software Engineers who are not yet ingrained in their ways.  National Instruments already has many published Case Studies about how LabVIEW has been and is being used by industry, government, and academia to do wonderful things to improve our world.  I think God will continue to use LabVIEW, or something that can trace its roots back to LabVIEW, to really solve some of the big problems of our world and be the foundation for software development of the distant future.

Think about it.  We all want to get to a point where we can talk to computers naturally and have them understand us, think about the ship computer in Star Trek.  No, think bigger than that, we want computers to be able to read our minds.  We usually know what we want to accomplish, but it takes time and effort to organize those thoughts into a series of actions, learn how to convey those actions to the computer, and then execute those actions, whether that be through a microphone, a mouse, or a keyboard.  Think about the expression “a picture is worth a thousand words”.  Most engineers naturally think in terms of diagrams, they communicate to ourselves and others how things interact, or that things must be performed in a particular sequence with certain decision points along the way.  In fact, the Unified Modeling Language (UML) is a graphical “language”, an agreed upon convention for documenting ideas in the form of various types of diagrams.  UML has come to be a foundational component of software design.  If the design has already been captured graphically, why should it be implemented as text?

In the distant future I think people will be writing software simply by imagining it.  They know what needs to be accomplished, and as they conceptualize how to accomplish it, the IDE will in real-time throw together diagrams that reflect what they are conceptualizing.  Similiar to a mirror that reflects our physical image, I think software development environments will someday show us our mental image, allowing us to provide clarity to those images at astonishing speed.  When we are satisified with the images, the compiler may ask us a series of questions to get futher clarification on some details, and then you’re done, the software works.  Test it, ship it, on to the next project.

I think graphical programming in LabVIEW is light-years ahead of any other programming language in reaching this Big Harry Audacious Goal (BHAG).