4 ms·

The availability of libraries is because of the language. It's a (good) flexible general purpose dynamically typed language which makes writing libraries and go

The availability of libraries is because of the language. It's a (good) flexible general purpose dynamically typed language which makes writing libraries and good code in general easy. Why it's deemed unsuitable for large, complex, multi-person projects is that enterprise types know only the byzantine OOP mess. And when all you have is OOP, everything is a FactoryFactoryFactory and everything else is "unmanageable".

HarHarVeryFunny 3y ago
The reason it's not well suited for larger/etc projects has nothing to do with OOP - it's about things like dynamic typing and indent-based structure that make it good for interactive REPL use, scripting and rapid prototyping, but less suited for more complex cases where you'd prefer more compile-time vs run-time checking, and where ease of lifetime maintenance trumps up-front coding time. I disagree that the availability of good libraries for Python is because of the language - especially if we're talking about scientific and ML libraries. In many of these cases the Python libraries are just pass-thrus to the underlying libraries written in C, which was chosen because of it's performance and suitability to the task.
- manuel_w 3y ago
  > indent-based structure [...] less suited for more complex cases How so?
  - HarHarVeryFunny 3y ago
    Because in the real world there are crappy programmers writing 1000 line functions and code nested 10 levels deep. Having explicitly delimited code blocks makes code, especially bad code, easier to read. I'd rather see 3 or 4 "}", maybe with comments, rather than just seeing a large reduction in indent and having to scroll up 3 pages to figure out the code structure. I guess if you're doing team-based Python development then everyone is going to be forced to be sensitive to indent, and maybe use a Python-aware editor, but often in a large non-Python project there are many different editors and indent configurations being used and the code structure is unreadable - but at least you can use a language aware formatter or indent tool to recover it. In Python any sort of loss of proper indenting would obviously change the functionality of the code. Maybe this never happens ?
sapiogram 3y ago
> Why it's deemed unsuitable for large, complex, multi-person projects is that enterprise types know only the byzantine OOP mess. And when all you have is OOP, everything is a FactoryFactoryFactory and everything else is "unmanageable". Have you ever worked in a large, dynamically typed codebase written by other people?
- TomSwirly 3y ago
  Python has had useful type-checking for a decade now.
  - oskarkk 3y ago
    "Useful" is very relative. I work with python daily and I try typing everything I can, but it can be such a pain in the ass compared to TypeScript that I want to throw my computer at the wall sometimes. And I can't imagine using Python's typing even 3 years ago, as many essential features that I constantly use are very new (typed kwargs for example). Many people that like typed languages just don't bother and don't use typing in Python because of how cumbersome it is.
- dbrueck 3y ago
  Yes! Python has worked tremendously well in those scenarios - the things that make it good for small projects can scale up very, very well. Similarly, I've worked on very large, multi-team projects where the language was statically typed, compiled, etc. and they've been total disasters, and others that have been a huge success. I've yet to see any language that can fully negate the power of sloppy, undisciplined programmers. Those programmers are like water and always find a way.
  - HarHarVeryFunny 3y ago
    > the things that make it good for small projects can scale up very, very well Sorry, but that makes zero sense. Dynamic typing is a language design choice where one is trading off automated error detection for faster development. The larger and more complex a project becomes, the more moving parts and interfaces (APIs) it has, and the more potential there is for API errors. Choosing NOT to prioritize automated (compile time) error detection is NOT something that scales up "very, very well". It's not just about size of project, but also about expected project lifetime. For a one-time use script, or experiment, or thesis project, then maybe development time is the prime concern. You're going to hack it to get it working ASAP, and don't care what happens later (there is no later). However, for a corporate project that will be in production use for years, then initial coding effort is only a small part of the lifetime project costs, and optimizing this at the expense of ease of maintenance is a poor decision. Years down the road the project will have had staff turnover, developers will have forgotten the details of all the code, the original design has probably been compromised due to feature creep, too many hands, etc, etc. At this stage you want all the help you can get so that people can still maintain the code, and the larger and more complex the project, the more so this will be. Again, the small/throwaway project language choice trade off of optimize development time at the cost of ease of bug detection will NOT scale up "very, very well". If you anticipate sloppy undisciplined programmers working on a project, then all the more reason to give them less weapons with which to shoot themselves in the foot.

HarHarVeryFunny 3y ago

The reason it's not well suited for larger/etc projects has nothing to do with OOP - it's about things like dynamic typing and indent-based structure that make it good for interactive REPL use, scripting and rapid prototyping, but less suited for more complex cases where you'd prefer more compile-time vs run-time checking, and where ease of lifetime maintenance trumps up-front coding time. I disagree that the availability of good libraries for Python is because of the language - especially if we're talking about scientific and ML libraries. In many of these cases the Python libraries are just pass-thrus to the underlying libraries written in C, which was chosen because of it's performance and suitability to the task.

manuel_w 3y ago
> indent-based structure [...] less suited for more complex cases How so?
- HarHarVeryFunny 3y ago
  Because in the real world there are crappy programmers writing 1000 line functions and code nested 10 levels deep. Having explicitly delimited code blocks makes code, especially bad code, easier to read. I'd rather see 3 or 4 "}", maybe with comments, rather than just seeing a large reduction in indent and having to scroll up 3 pages to figure out the code structure. I guess if you're doing team-based Python development then everyone is going to be forced to be sensitive to indent, and maybe use a Python-aware editor, but often in a large non-Python project there are many different editors and indent configurations being used and the code structure is unreadable - but at least you can use a language aware formatter or indent tool to recover it. In Python any sort of loss of proper indenting would obviously change the functionality of the code. Maybe this never happens ?

sapiogram 3y ago

> Why it's deemed unsuitable for large, complex, multi-person projects is that enterprise types know only the byzantine OOP mess. And when all you have is OOP, everything is a FactoryFactoryFactory and everything else is "unmanageable". Have you ever worked in a large, dynamically typed codebase written by other people?

TomSwirly 3y ago
Python has had useful type-checking for a decade now.
- oskarkk 3y ago
  "Useful" is very relative. I work with python daily and I try typing everything I can, but it can be such a pain in the ass compared to TypeScript that I want to throw my computer at the wall sometimes. And I can't imagine using Python's typing even 3 years ago, as many essential features that I constantly use are very new (typed kwargs for example). Many people that like typed languages just don't bother and don't use typing in Python because of how cumbersome it is.
dbrueck 3y ago
Yes! Python has worked tremendously well in those scenarios - the things that make it good for small projects can scale up very, very well. Similarly, I've worked on very large, multi-team projects where the language was statically typed, compiled, etc. and they've been total disasters, and others that have been a huge success. I've yet to see any language that can fully negate the power of sloppy, undisciplined programmers. Those programmers are like water and always find a way.
- HarHarVeryFunny 3y ago
  > the things that make it good for small projects can scale up very, very well Sorry, but that makes zero sense. Dynamic typing is a language design choice where one is trading off automated error detection for faster development. The larger and more complex a project becomes, the more moving parts and interfaces (APIs) it has, and the more potential there is for API errors. Choosing NOT to prioritize automated (compile time) error detection is NOT something that scales up "very, very well". It's not just about size of project, but also about expected project lifetime. For a one-time use script, or experiment, or thesis project, then maybe development time is the prime concern. You're going to hack it to get it working ASAP, and don't care what happens later (there is no later). However, for a corporate project that will be in production use for years, then initial coding effort is only a small part of the lifetime project costs, and optimizing this at the expense of ease of maintenance is a poor decision. Years down the road the project will have had staff turnover, developers will have forgotten the details of all the code, the original design has probably been compromised due to feature creep, too many hands, etc, etc. At this stage you want all the help you can get so that people can still maintain the code, and the larger and more complex the project, the more so this will be. Again, the small/throwaway project language choice trade off of optimize development time at the cost of ease of bug detection will NOT scale up "very, very well". If you anticipate sloppy undisciplined programmers working on a project, then all the more reason to give them less weapons with which to shoot themselves in the foot.