Why might a C++ programmer say “I could never write Python”?(jvns.ca)
jvns.ca
Why might a C++ programmer say “I could never write Python”?
http://jvns.ca/blog/2015/01/24/why-a-c-plus-plus-programmer-might-say-i-could-never-write-python/
14 comments
More powerful type systems are great (I'm a happy Haskell programmer much of the time), but there is a surprising amount of safety you can get out of fairly minimal type systems if you figure out how to use them well. For instance, on a recent C project I was able to enforce invariants about what threads could touch what data. C++ has significantly more machinery to leverage.
What was it like having C++ be your first language? I've heard so many say that is A Bad Idea™.
What was your experience? What tools would you recommend, if someone were to start there today?
It seems like no matter where you choose to start, learning C or C++ is going to be an inevitable necessity. So I wonder, why not just start there?
I would definitely like to talk to you further about it, if you're willing.
What was your experience? What tools would you recommend, if someone were to start there today?
It seems like no matter where you choose to start, learning C or C++ is going to be an inevitable necessity. So I wonder, why not just start there?
I would definitely like to talk to you further about it, if you're willing.
I know I will get some backlash for saying this, but there is a lot to be said for a good IDE. - PyCharm (a Python IDE) would detect the example given. The word "elephant" would be grey (parameter not used) and the live Python interpreter would underline "elephnt" (Unknown reference) upon pressing return.
He does state "by default" this would not be detected, which is true. Yes, the compiler isn't always on your back, but Jenkins is ;)
What the title should say is "Why might a C++ programmer find Python tedious"- Answer, because he/she has to write tests.
He does state "by default" this would not be detected, which is true. Yes, the compiler isn't always on your back, but Jenkins is ;)
What the title should say is "Why might a C++ programmer find Python tedious"- Answer, because he/she has to write tests.
I understand the code from the article is contrived, but I feel it serves as a bad example. Presumably you would write unit tests for such code in any language, regardless of type safety. Such tests would catch errors like this.
> Tests that wouldn’t tell you very much at all in Scala (that just run the code and don’t check the result) suddenly become incredibly useful!
I don't really know what that means. A Python programmer doesn't (shouldn't?) go out of their way to write insane tests like this because they are scared of the "uncertainty" of dynamic typing. Just write unit tests, and make sure your code is sufficiently covered. Use flakes/frosted to find low hanging fruit like this.
> Tests that wouldn’t tell you very much at all in Scala (that just run the code and don’t check the result) suddenly become incredibly useful!
I don't really know what that means. A Python programmer doesn't (shouldn't?) go out of their way to write insane tests like this because they are scared of the "uncertainty" of dynamic typing. Just write unit tests, and make sure your code is sufficiently covered. Use flakes/frosted to find low hanging fruit like this.
On the other hand, I see a lot of Java code where the unit tests are woefully inadequate but the fact that Eclipse/IntelliJ/Whatever had no warnings and javac liked the code meant the programmer thought he'd done a good job.
Hell, most of the world's C code was written basically that way. Often with a lot less testing and most of the testing that was actually done included no edge cases.
Hell, most of the world's C code was written basically that way. Often with a lot less testing and most of the testing that was actually done included no edge cases.
In Haskell I wouldn't write a test to verify a type that is already guaranteed.
In Haskell I wouldn't write a test to verify that it's already guaranteed.
you can also create a c++ example where a 'bool' gets unintentionally promoted to an 'int' causing the compiler to pick the wrong template without a the compiler emitting a warning.
Or in C++ you forget to add "=0" to a method in a virtual class and you get a weird link error. Or in the not so distant past, forgetting to add a semi colon to a class definition... Or a simple mistake that makes the compiler emit 40+ errors on non-fitting candidate templates.
mumble mutter "pot" mutter mumble "kettle"
Or in C++ you forget to add "=0" to a method in a virtual class and you get a weird link error. Or in the not so distant past, forgetting to add a semi colon to a class definition... Or a simple mistake that makes the compiler emit 40+ errors on non-fitting candidate templates.
mumble mutter "pot" mutter mumble "kettle"
This is why there's been a rush of languages targeting the space of "typesafe AND memory-safe AND accessible AND performant".
My emacs catches this without any compiling:
http://i.imgur.com/TVkU8KS.png
I'm sure most editors would complain about this. There are also IDEs like PyCharm that give you tab completion for Python.
If a C++ person says they could never write Python it is because they don't understand there is plenty of tooling that will verify your code.
http://i.imgur.com/TVkU8KS.png
I'm sure most editors would complain about this. There are also IDEs like PyCharm that give you tab completion for Python.
If a C++ person says they could never write Python it is because they don't understand there is plenty of tooling that will verify your code.
This seems to be almost the exact reason I was taught to start all my perl code with `use strict; use warnings;` 15 years ago...
Typos being run time errors is because of implicit declarations; it's not because of type systems. Implicit declarations are messy for others reasons too. See Python's 'nonlocal' keyword for an example.
This is just an argument for using IDEs or modern text editors vs joe bloggs scripting pad. Any decent Python IDE (e.g. Pycharm, Sublime + pyflakes) would catch syntax errors.
Still I would not necessarily recommend against it.
Dynamic vs static typing, I have programmed in dynamic languages and for small projects there is a benefit to not having to worry about strict typing.
For large projects, you end up having to worry about strict typing anyways except manually (of course, there is a degree of this that is always true no matter what, and C++ is not the best example of "strong" typing, but it's a continuum). For that reason, I can definitely see the virtue of static typing for a large project, it does not solve all type related checks, but it at least reduces them, which can save some time.