4 ms·

On most projects I have seen where python was seen as problematic, I think that having types ala C++/Java would not have improved much. The real problem is that

by cdavid 15y ago

On most projects I have seen where python was seen as problematic, I think that having types ala C++/Java would not have improved much. The real problem is that the function is not documented, nor is the function expectations. Typing in C++/java does not replace that (more advanced typing systems do much better, though). Package management and generally deployment is certainly a pain in python. I think it is one of the main issue in typical "corporate environments"

nostrademons 15y ago
In most C++/Java code, the function is not documented either. The nice thing about manifest types is that the source code becomes the documentation (shitty documentation, yes, but usually good enough that you can figure out how to use it by looking at the source). Type inference with a doc generator would work too, as long as you run the doc generator regularly and everybody knows where to find the docs. History has shown that programmers are too lazy/busy to write good documentation, and when they do, they don't keep it in sync with what the code does. If it's not checked by the compiler or automated tests, it's probably wrong.
- deleted 15y ago
  [deleted]
- cdavid 15y ago
  It is not my experience that you can figure out how to call functions correctly just from the function signature. Certainly, that's not true from C++ when you need to figure out lifetime issues, etc… It may be possible to figure out from the source code, if the code is written well enough, but that's true independently of the language IMO. Developer not writing decent doc is an institutional problem, and if this cannot be enforced, then the institution is most likely not capable of producing very good code either. I think it is more interesting to talk from the POV of how to write code that is actually readable: type may help, but that's only a not that important part of the equation in my experience.
  - nostrademons 15y ago
    C++ with good coding conventions can encode pretty much all the information you need in the type. If a parameter is read-only, pass by const reference. If it's writable but ownership is not transferred, pass by pointer. If ownership is transferred, pass by unique_ptr. If it's owned within an object or function lifetime, use a scoped_ptr. If it can't be copied, inherit from boost::noncopyable.
gtaylor 15y ago
This, this, and this. We document our stuff using ReST and Sphinx. You can optionally specify data types in the docstrings, which does a ton to help with this. It isn't time-consuming, and it makes your team not hate reading your stuff.

by cdavid 15y ago

nostrademons 15y ago

In most C++/Java code, the function is not documented either. The nice thing about manifest types is that the source code becomes the documentation (shitty documentation, yes, but usually good enough that you can figure out how to use it by looking at the source). Type inference with a doc generator would work too, as long as you run the doc generator regularly and everybody knows where to find the docs. History has shown that programmers are too lazy/busy to write good documentation, and when they do, they don't keep it in sync with what the code does. If it's not checked by the compiler or automated tests, it's probably wrong.

deleted 15y ago
[deleted]
cdavid 15y ago
It is not my experience that you can figure out how to call functions correctly just from the function signature. Certainly, that's not true from C++ when you need to figure out lifetime issues, etc… It may be possible to figure out from the source code, if the code is written well enough, but that's true independently of the language IMO. Developer not writing decent doc is an institutional problem, and if this cannot be enforced, then the institution is most likely not capable of producing very good code either. I think it is more interesting to talk from the POV of how to write code that is actually readable: type may help, but that's only a not that important part of the equation in my experience.
- nostrademons 15y ago
  C++ with good coding conventions can encode pretty much all the information you need in the type. If a parameter is read-only, pass by const reference. If it's writable but ownership is not transferred, pass by pointer. If ownership is transferred, pass by unique_ptr. If it's owned within an object or function lifetime, use a scoped_ptr. If it can't be copied, inherit from boost::noncopyable.

gtaylor 15y ago

This, this, and this. We document our stuff using ReST and Sphinx. You can optionally specify data types in the docstrings, which does a ton to help with this. It isn't time-consuming, and it makes your team not hate reading your stuff.