3 ms·

> Then, what generaly happened was a programmer would think for a really long time, and then write just a little bit of code, and in practical terms, programmin

> Then, what generaly happened was a programmer would think for a really long time, and then write just a little bit of code, and in practical terms, programming involved assembling many very small pieces Oh how I bloody want to do jut this today. I want my program to be split into as small parts as possible, every part (i.e. every function) being defined in a separate file. But Python encourages the direct opposite - writing long files of code to avoid introducing too many "modules" and this is a debilitating headache. > At some point along the way (he may have referred to the 1990’s specifically), the systems that were being built and the libraries and components that one had available to build systems were so large, that it was impossible for any one programmer to be aware of all of the individual pieces, never mind understand them. Thanks to my ADHD it is very hard to me to fit anything that doesn't fit in half a screen into my mind. The longer a module growth the lower my productivity falls.

jasonpeacock 8y ago
> But Python encourages the direct opposite - writing long files of code to avoid introducing too many "modules" and this is a debilitating headache. How does Python encourage mega-files? AFAIK there's nothing that prevents nor discourages proper organization of code into files. I frequently use multiple files to organize my library implementations.
- qwerty456127 8y ago
  Just some clues: A class definition can not be split in many files (e.g. in C# you can do this easily with "partial class" declaration and that's amazing, needless to say you can and almost always do split one module (a namespace) into many flies there). Whatever you put in a separate file you will have to import manually everywhere you use it and you have to care about circular imports. You have to invent names all the time, a package, a module and a function having the same name smells a headache. The C# namespaces definition system could be made even better than it is already (i.e. by allowing class-free functions directly inside namespaces) but it already feels just so much better than Python "module = file" model.
  - joshuamorton 8y ago
    >A class definition can not be split in many files (e.g. in C# you can do this easily with "partial class" declaration and that's amazing, needless to say you can and almost always do split one module (a namespace) into many flies there). I think most would consider this a good thing. WYSIWYG. If a class is so gargantuan as to require multiple files, it should probably be multiple classes that communicate via a well defined, public API, not implicitly. >You have to invent names all the time, a package, a module and a function having the same name smells a headache. This is only an issue if you are importing *. If you import in a namespace (`from foo import module`, `from bar import other_module`), you can have `module.module`, `other_module.module` and anything else all living in harmony. If you work in python as python intends and not C/C++ (namespaced imports, not text-prepended ones), it's much, much cleaner. It's also possible to, generally speaking, have private submodules within one larger module. You can do this with `__init__.py` by importing the various submodules, explicitly re-exporting the things you wish to be top-level public, and setting `__all__` to include them. This is why I can do something like `import numpy as np; np.ndarray` even though ndarray is defined in an extension module referenced by `numpy.core.multiarray`. See multiarray (https://github.com/numpy/numpy/blob/master/numpy/core/multiarray.py https://github.com/numpy/numpy/blob/master/numpy/core/multia...), which pulls things from `numpy.core._multiarray_umath`, then exported by core via `numeric` (https://github.com/numpy/numpy/blob/master/numpy/core/__init__.py#L60 https://github.com/numpy/numpy/blob/master/numpy/core/__init...), then again by the top level __init__ (https://github.com/numpy/numpy/blob/master/numpy/__init__.py#L143 https://github.com/numpy/numpy/blob/master/numpy/__init__.py...).
    - qwerty456127 8y ago
      > If a class is so gargantuan as to require multiple files IMHO anything that doesn't fit in one screen is "gargantuan" > If you import in a namespace (`from foo import module`, `from bar import other_module`), you can have `module.module`, `other_module.module` Which looks ugly and feels a nasty headache if you want to maintain intuitive vision of your code and dependencies structure. > It's also possible to, generally speaking, have private submodules within one larger module. You can do this with `__init__.py` by importing the various submodules, explicitly re-exporting I know but even reading this paragraph hurts. Too much mess to manage manually.

jasonpeacock 8y ago

> But Python encourages the direct opposite - writing long files of code to avoid introducing too many "modules" and this is a debilitating headache. How does Python encourage mega-files? AFAIK there's nothing that prevents nor discourages proper organization of code into files. I frequently use multiple files to organize my library implementations.

qwerty456127 8y ago
Just some clues: A class definition can not be split in many files (e.g. in C# you can do this easily with "partial class" declaration and that's amazing, needless to say you can and almost always do split one module (a namespace) into many flies there). Whatever you put in a separate file you will have to import manually everywhere you use it and you have to care about circular imports. You have to invent names all the time, a package, a module and a function having the same name smells a headache. The C# namespaces definition system could be made even better than it is already (i.e. by allowing class-free functions directly inside namespaces) but it already feels just so much better than Python "module = file" model.
- joshuamorton 8y ago
  >A class definition can not be split in many files (e.g. in C# you can do this easily with "partial class" declaration and that's amazing, needless to say you can and almost always do split one module (a namespace) into many flies there). I think most would consider this a good thing. WYSIWYG. If a class is so gargantuan as to require multiple files, it should probably be multiple classes that communicate via a well defined, public API, not implicitly. >You have to invent names all the time, a package, a module and a function having the same name smells a headache. This is only an issue if you are importing *. If you import in a namespace (`from foo import module`, `from bar import other_module`), you can have `module.module`, `other_module.module` and anything else all living in harmony. If you work in python as python intends and not C/C++ (namespaced imports, not text-prepended ones), it's much, much cleaner. It's also possible to, generally speaking, have private submodules within one larger module. You can do this with `__init__.py` by importing the various submodules, explicitly re-exporting the things you wish to be top-level public, and setting `__all__` to include them. This is why I can do something like `import numpy as np; np.ndarray` even though ndarray is defined in an extension module referenced by `numpy.core.multiarray`. See multiarray (https://github.com/numpy/numpy/blob/master/numpy/core/multiarray.py https://github.com/numpy/numpy/blob/master/numpy/core/multia...), which pulls things from `numpy.core._multiarray_umath`, then exported by core via `numeric` (https://github.com/numpy/numpy/blob/master/numpy/core/__init__.py#L60 https://github.com/numpy/numpy/blob/master/numpy/core/__init...), then again by the top level __init__ (https://github.com/numpy/numpy/blob/master/numpy/__init__.py#L143 https://github.com/numpy/numpy/blob/master/numpy/__init__.py...).
  - qwerty456127 8y ago
    > If a class is so gargantuan as to require multiple files IMHO anything that doesn't fit in one screen is "gargantuan" > If you import in a namespace (`from foo import module`, `from bar import other_module`), you can have `module.module`, `other_module.module` Which looks ugly and feels a nasty headache if you want to maintain intuitive vision of your code and dependencies structure. > It's also possible to, generally speaking, have private submodules within one larger module. You can do this with `__init__.py` by importing the various submodules, explicitly re-exporting I know but even reading this paragraph hurts. Too much mess to manage manually.