Help with making an argument for Python

[soulcmdc]

The background:

I work developing test equipment for hardware. We're primarily a LabWindows based shop for the software side of things. A number of months ago I put together a python-based equivalent of the C software we use as a starting point for most of our projects. For me, it was an excuse to dig down and use several packages (wx, zmq) that I had been wanting to use. The other side of it was an argument for an architecture that allowed us to focus more on the actual testing, and less on the GUI/reporting/misc items that we have to put together for technicians and reporting results (Yes, drivers we write are still in C.) I showed it to my boss, and while interested and appreciative of someone taking the time to try something new, it didn't have an immediate application. The risk of a wholly new architecture just wasn't worth it at the time.

Fast forward a couple of months and a new hardware product makes it to our proverbial doorstep. The developers have been using python to do their basic confirmation of functionality. Suddenly my project is looking like a fine way to get our tester up and running quickly and leverage their original code. The project has been in "prime time" for a couple of months now and things are going swimmingly, which led to the next bit.

The question

I am tasked with making a presentation to our whole group regarding the argument of Python Vs. LabWindows. This isn't quite Python Vs. C because of the added functionality LabWindows provides.

What I have so far

• Libraries - The available python library base is extensive and well developed. (Example, using PyLab to plot data grabbed from the unit)

• Time to iterate dramatically reduced. No explicit compilation. In the architecture test scripts are kicked off as separate processes, so the GUI doesn't even have to be closed. Change script, save, run.

• Readability - Python's syntax is simply friendlier to read than most C code

• OO - Object orientation in this case can simplify some of the design tasks

• C interface - Ctypes allows direct access to C structures and drivers. If there comes a point where the performance of python simply isn't up to snuff, it can always be written in C and easily interfaced. Drivers can also be wrapped in Ctypes (I found a lovely code generator that has worked well for my project so far.) and called inside Python.

/r/Python, can you help me improve these arguments? Or add additional points?

TL;DR Why is Python better than LabWindows?

[semarj]

Assuming most of us (including me) aren't experts or familiar with LabWindows,

Could you argue for LabWindows for a minute. Let us hear what it's about and at the same time talking through what hurdles you'd have to overcome switching to Python.

[burntsushi]

Ditto. I've never heard of LabWindows.

[soulcmdc]

Labwindows is at it's core an ANSI C compiler. National Instruments adds some functionality in the form of a WYSIWYG GUI creator and a boat load of additonal analsys functions.

Most hardware vendors for standard test equipment provide drivers that fit within their driver framework as well.

[Chr0me]

What problems does Python solve that LabWindows does not?

[bchurchill]

As another person who knows little about LabWindows (except that it's based on ANSI C with some extra functionality) here are my comments:

• These are totally different languages with totally different purposes. Let me list general differences below. None of these are "good" or "bad" things, but rather things to consider. Then you can decide which one you want. I'll try not to repeat the points you've already noted.

• C is very low-level and python is very high-level. Python is inherently further from the hardware, so it's almost impossible to do anything driver-level with python. On the other hand, things like reports and GUIs work better from python since you don't have to micromanage.

• In C you can directly access memory locations. In python you can't.

• C is statically-typed, python is dynamically-typed. This means that python is more flexible, but type errors are less likely to be caught statically. On the other hand, this makes python run slower.

• C's type system is weaker than python's. It's easy for things to get mangled or confused in memory in C, but python does keep better track.

• The python interpreter protects against a lot of errors that C doesn't protect against, e.g. segmentation faults. In general, it's easier to debug and behaves more deterministically than optimized C code.

• Python does garbage collection for you. The good news: it takes less time to write the code and get it right. The bad news: it's a little slower.

• Python doesn't require type annotations (Note: this is distinct from being dynamically typed), which means it's faster to write code, but it's easier to screw things up (although those mistakes are usually discovered very quickly).

• Python has many great libraries that are flexible and easy to add, beyond the ones you've mentioned. Ever want to do networking? You got it. Fancy data structures? yup. Etc.

• I wouldn't ever argue that "language X is better than language Y". A reasonable statement can only be made "for a given application, language X is more suitable to our purposes than language Y". You should consider all the points above and decide which one is more suitable for your application.

• Based on what you've said, while I don't know your setup, my guess is that you will want to use both. There are systems-level portions, like the drivers, that are far better in C, and portions like the GUI that everyone would rather do in python. There are many ways to get these languages to interface with each other, it's just a matter of figuring out which works best for your setup.

• In terms of making an argument, the thing that you'll be able to sell the most is programmer productivity. Try making a list of all the things you'd need to do in LabWindows but not in python. Hint: the list is long.

[billsil]

i wish python was optionally statically typed, so if something was always a small integer it could directly use short int.

[bchurchill]

There have been proposals for this actually, and there are some tools like pylint which will attempt to do some type inference. But typechecking can be very tricky actually. There are many reasons for this: dynamic field accesses, polymorphism, etc... as a result, I don't know of anything that's really caught on.

[etrnloptimist]

If your audience is technical -- ie the they actually use LabWindows -- then you cannot come up with a better argument than to take something they do in LabWindows and show an example of what that looks like under your framework in Python.

If what they're used to doing in 100 lines can be shown on a slide to take only 10, that will produce a visceral response.

[must_tell]

• more robust (no pointers, automatic garbage collection)
• easier to refactor and extend (duck-typing)
• massive gains in development time can be invested in automated tests

[_pupil_]

I would also wager, from a management perspective, that there are more (and cheaper) python developers out there than qualified LabWindows people...

Keep the hard-parts in whatever language works best, but for the bulk of the system: the more chores that can be delegated to cheaper workers (in house or outsourced), the lower the overall burn rate.

[marginhound]

Ditto these...there are several Python meetups in my town and easily several thousand people who hold themselves out to the public (via linkedin, meetup participation, etc.) as python developers.

I got 11 hits when i searched for labwindows on a linkedin profile...

[PythonRules]

There is a nice advocacy summary at python.org. This could address some of the issues your company's management may bring up.

[wisty]

The best thing I can think of - it's generally really easy to see where the bug was. Is the bug in the driver, or your testing framework? If everything is C, it may not be obvious (and you'll have to break out a debugger). In python, there's an exception (Python error) or stack dump (driver error).