There is an on going discussion at the office with a team member who refuses to use dynamic languages. Claiming that most of his errors are typographical errors and they are caught by the compiler. So for him, since these errors are not caught until runtime, he throws and entire group of languages out the window. He also claims that to ensure that same level of checking with a dynamic language you would have to create more unit tests than normal to prevent introducing unhandled runtime exceptions.
So I decided to do a little test over the weekend. I created a very simple Number class in Python and C++. Using the exact same TDD development process, I implemented some very basic operations including division, addition, subtraction, etc… I ended up with 12 tests. The exact same tests for both the C++ and Python implementation resulting in 100% of the executation path being covered. I decided that the compliation (in case of C++) and passing of the tests determined a success.
Then went back and inserted common typographical errors. Mistypes, extra = signs, not enough = signs, miseplled_varaibles, etc… The end result was I was unable to get my unit tests passing while introducing syntax that would induce an unhandled runtime exception in Python. Granted, in C++ the compiler did catch a lot of things for me, but the point here is I didn’t have to create any extra tests to ensure that same level of confidence in my Python code.
Paddy3118 says:
What were the line counts? Python vs C++ ?
Some have stated that errors/line-count is constant.
Is your co-worker convinced?
- Paddy.
20 Apr 2009, 12:40Brandon Craig Rhodes says:
By using PyFlakes, a lint-like program for Python, as his “compile step”, your team member can have all the advantages of a normal compiler: not only will PyFlakes signal any syntax errors without having to run his code, but it will also flag mis-spelled variable names, remind him about missing “import” statements, and even signal when he’s left an “import” in that’s no longer needed.
In fact, you should tell your team member that if he’s waiting for compile-time to detect mistakes and typos, then he’s waiting far too *late* in the process and wasting his time: he needs them flagged as he types them, not a minute later, when he will have to go back to the line and remember what he was trying to say. I have Emacs run PyFlakes every few seconds using its “Flymake” mode and so I find out instantly if I’ve typed something nonsensical, saving a huge amount of time.
So: affirm that your team member is entirely correct that syntax and other errors should get caught immediately; but tell him that he himself is wasting time if he’s waiting until a separate compile step to find out that he’s mismatched braces or named an non-existent variable; and tell him that, whether he’s writing Java or Python or C, standard tools exist that should hook into his editor to flag simple errors as he’s typing so that he corrects them immediately before he goes any further. Whether he’s using Emacs, Vim, or TextMate, a correctly-configured editor will provide exactly what he’s looking for regardless of whether the language is dynamic or not; he needs to figure out that the dynamicness of the language is not even the issue.
20 Apr 2009, 14:18nes says:
You should give him pyflakes, pychecker, or pylint. I had some hard to track bug in Javascript+IE6 years ago because of a typo, but I blame it on the environment. I never had much problem finding out such problems quickly in Python I am not quite sure why. Maybe because there are better tools or it is easier to test things.
20 Apr 2009, 19:40nes says:
Maybe to give you an idea what to experiment with. In may case I had a flag “verified=false” by default that was getting set “verifed=true” when I had checked for certain conditions. My data was obviously never marked as verified, and I spent too much time trying to see if the conditions I choose for the verification itself where somehow wrong.
20 Apr 2009, 19:48Wayne says:
Some history, this debate has been going on since I started with this company a little over a year ago. Each time we rehash this topic I find him conceding more and more of the voodoo myths he holds in his head about dynamically typed languages. This was just the latest one. Mind you my goal isn’t to make him a convert to any language. Mostly I just don’t like seeing people blindly following an idea due to bad information or misconceptions.
I also sent him over to Michael Foord’s recent post about dynamic languages.
http://www.voidspace.org.uk/python/weblog/arch_d7_2009_04_18.shtml#e1081
@Paddy
Minus the tests, the Python version was roughly 80 lines and the C++ version was roughly 110 lines. Not a huge difference in total line count. The testing code in C++ was a little large just due to the CUTE boiler plate stuff. No, he isn’t 100% convinced, but he is slowly coming around.
@Bradon and nes
20 Apr 2009, 20:18Yeah, I agree. We actually had a good talk again today after I told him about my weekend experiments. PyFlakes came up in the discussion and I think he is starting to see that blindly ruling out languages just because they are dynamic is in poor form. He recently picked up learning Scala which seems to have given him a greater appreciation for other languages.
Jon-Pierre Gentil says:
The last time I had one of those debates, it was over “how fast it is.” A very arrogant co-worker had pretty much said that Python and every other dynamic language was flawed because of it’s lack of compiled state. (He used this argument against Java too.) At one point in the project we had to write a small utility to do some maintenance work on a few specialized databases we had created and we took up a challenge: I would write it in Python, and he would write it in C, and we would compare. We were pretty even as far as skill levels in our language of choice, so I felt it was a good challenge. The manager approved, and sent us on our way. Three days later, I had completed it, and turned it in. Seven days after that, said co-worker turned his version in. The manager called us both in and said “Clearly Jon-Pierre’s was faster, though it runs 7.3 seconds slower, on average, over the course of a 30 minute maintenance window. But he saved me 7 man days of work to do it. Try to keep pace, Bryan.”
The co-worker stormed out of the room and never really spoke to me again.
Scala is a cool language, and it gives C/C++ (and of course Java) programmers that cozy feeling of curly braces.
20 Apr 2009, 22:37