12 ms·

I feel this is bit of a recurring theme in Python world where nice simple things are dragged into serious (enterprise) production world and then they accumulate

by zokier 3y ago

I feel this is bit of a recurring theme in Python world where nice simple things are dragged into serious (enterprise) production world and then they accumulate gazillion bits of cruft, hiding the originally nice simple thing. It's quite fundamental problem trying to please both the ad-hoc small script and X million line production system users; Python straddling the gap imho ends up pleasing neither. My preference would be to focus on excelling on the small-scale stuff and leave the complex stuff for ecosystems better aligned with that; basically let Java be Java and Python be Python.

game_the0ry 3y ago
> My preference would be to focus on excelling on the small-scale stuff and leave the complex stuff for ecosystems better aligned with that; basically let Java be Java and Python be Python. Agreed 100%. Strongly prefer python for the simple scripting and conceptually simple mental model, and others for more complex stuff. Also, don't use tools that were not designed for the job from the beginning and then complain that it does not fit your use case.
- math_dandy 3y ago
  Don’t you think that ship has sailed? Python powers software of incredible complexity these days including back-ends for large companies and all of AI (yes, I know the “hard parts” are written in C++, but still).
  - game_the0ry 3y ago
    > Don’t you think that ship has sailed? No, those ships are setting sail with anchors down, and complaining why they're moving so slow.
    - itsoktocry 3y ago
      >No, those ships are setting sail with anchors down, and complaining why they're moving so slow. It's 2024 and you still think the choice of language in which you build your product is what makes or breaks a company?
      - The_Colonel 3y ago
        It's quite rare for companies to fail because of one bad decision, but I believe that choosing python for large complex projects will have long term negative consequences, irrespective of whether it will on its own kill the company or not.
      - executesorder66 3y ago
        So do you think for example FAANG-like companies would have done pretty much as well if they wrote all their stuff in Scratch[0] instead, or do you think the choice of programming language matters? [0] https://en.wikipedia.org/wiki/Scratch_(programming_language) https://en.wikipedia.org/wiki/Scratch_(programming_language)
jerf 3y ago
It's one of the stereotypical failure cases of dynamically-typed languages. I cite this not to bury them in general, but because it's something that people programming in dynamic languages need to be aware of. If object oriented languages seem to frequently end up with "God Objects" dynamically-typed languages end up with "God Functions", where Just One More Parameter at a time, a core function grows slowly and steadily until it is a monstrosity of several dozen parameters and there is simply no conceivable way to document how they all interact with each other, test all the combinations, conceptualize all the combinations, etc. It's very dangerous because it happens often just one parameter, or even fractions of a parameter ("let's make this string also able to be an array of strings") at a time, each step seeming sensible at the time but the totality becoming a nightmare. Statically typed can incrementally end up with too many parameters too, but the static typing generally helps reduce the complexity and there is generally more incentives to start binding the parameters up into meaningful other structs. Dynamically typed languages on the other hand have the tendency to start widening what types each parameter can take which makes the problems even worse. Is "targetURL" a string, an array of strings that will automatically turn the return into an array of results, an object that implements ".toURL()", a function that will be automatically called with some magic parameters, a None which will then invoke other magic to get the URL from somewhere else, etc.? (Don't worry, dynamic typing fans, static languages have their own characteristic failures, like the aforementioned God Object.) Dynamically typed code bases are not doomed to end up this way. It can be avoided with discipline, which starts with the awareness that it is a problem at all. And it's a very good idea to learn to avoid them, because they're terribly difficult to tear back apart once constructed. I've worked in a code base that darned near had a "JustDoEverythingWeCanPossibleDo(...)" function, where (...) doesn't represent the true horror because there were rather a lot of global variables getting set that had huge impacts on the process as well. Trying to pull that apart to do any real work was, ah, an experience.
int_19h 3y ago
I would argue that Python itself is a case of this. It peaked early as an ultra-dynamic language, and was very consistent at it - e.g. all declarations are executable code, which is actually fairly straightforward conceptually and easy to explain - but this approach doesn't mesh well with things like class declarations and imports, which turns out you need for more serious development. More recently, this is the case with typed Python. Again, the dynamic-ness of Python - which easily exceeds that of JS - was part of the original design for type annotations. Turns out it doesn't work well with things like forward references or type parameters, so ugly hacks (like stringifying type names) were introduced to deal with that. Now there's yet another revamp to fix the resulting ugliness and inconsistencies (take a look at https://peps.python.org/pep-0649/ https://peps.python.org/pep-0649/ to see what I mean).
- gv83 3y ago
  Modern python is basically a bucket of puke in between the Annotated crap, async/await, decorators everywhere..the elegance is gone for good. Sad.

by zokier 3y ago

game_the0ry 3y ago

> My preference would be to focus on excelling on the small-scale stuff and leave the complex stuff for ecosystems better aligned with that; basically let Java be Java and Python be Python. Agreed 100%. Strongly prefer python for the simple scripting and conceptually simple mental model, and others for more complex stuff. Also, don't use tools that were not designed for the job from the beginning and then complain that it does not fit your use case.

math_dandy 3y ago
Don’t you think that ship has sailed? Python powers software of incredible complexity these days including back-ends for large companies and all of AI (yes, I know the “hard parts” are written in C++, but still).
- game_the0ry 3y ago
  > Don’t you think that ship has sailed? No, those ships are setting sail with anchors down, and complaining why they're moving so slow.
  - itsoktocry 3y ago
    >No, those ships are setting sail with anchors down, and complaining why they're moving so slow. It's 2024 and you still think the choice of language in which you build your product is what makes or breaks a company?
    - The_Colonel 3y ago
      It's quite rare for companies to fail because of one bad decision, but I believe that choosing python for large complex projects will have long term negative consequences, irrespective of whether it will on its own kill the company or not.
    - executesorder66 3y ago
      So do you think for example FAANG-like companies would have done pretty much as well if they wrote all their stuff in Scratch[0] instead, or do you think the choice of programming language matters? [0] https://en.wikipedia.org/wiki/Scratch_(programming_language) https://en.wikipedia.org/wiki/Scratch_(programming_language)

jerf 3y ago

It's one of the stereotypical failure cases of dynamically-typed languages. I cite this not to bury them in general, but because it's something that people programming in dynamic languages need to be aware of. If object oriented languages seem to frequently end up with "God Objects" dynamically-typed languages end up with "God Functions", where Just One More Parameter at a time, a core function grows slowly and steadily until it is a monstrosity of several dozen parameters and there is simply no conceivable way to document how they all interact with each other, test all the combinations, conceptualize all the combinations, etc. It's very dangerous because it happens often just one parameter, or even fractions of a parameter ("let's make this string also able to be an array of strings") at a time, each step seeming sensible at the time but the totality becoming a nightmare. Statically typed can incrementally end up with too many parameters too, but the static typing generally helps reduce the complexity and there is generally more incentives to start binding the parameters up into meaningful other structs. Dynamically typed languages on the other hand have the tendency to start widening what types each parameter can take which makes the problems even worse. Is "targetURL" a string, an array of strings that will automatically turn the return into an array of results, an object that implements ".toURL()", a function that will be automatically called with some magic parameters, a None which will then invoke other magic to get the URL from somewhere else, etc.? (Don't worry, dynamic typing fans, static languages have their own characteristic failures, like the aforementioned God Object.) Dynamically typed code bases are not doomed to end up this way. It can be avoided with discipline, which starts with the awareness that it is a problem at all. And it's a very good idea to learn to avoid them, because they're terribly difficult to tear back apart once constructed. I've worked in a code base that darned near had a "JustDoEverythingWeCanPossibleDo(...)" function, where (...) doesn't represent the true horror because there were rather a lot of global variables getting set that had huge impacts on the process as well. Trying to pull that apart to do any real work was, ah, an experience.

int_19h 3y ago

I would argue that Python itself is a case of this. It peaked early as an ultra-dynamic language, and was very consistent at it - e.g. all declarations are executable code, which is actually fairly straightforward conceptually and easy to explain - but this approach doesn't mesh well with things like class declarations and imports, which turns out you need for more serious development. More recently, this is the case with typed Python. Again, the dynamic-ness of Python - which easily exceeds that of JS - was part of the original design for type annotations. Turns out it doesn't work well with things like forward references or type parameters, so ugly hacks (like stringifying type names) were introduced to deal with that. Now there's yet another revamp to fix the resulting ugliness and inconsistencies (take a look at https://peps.python.org/pep-0649/ https://peps.python.org/pep-0649/ to see what I mean).

gv83 3y ago
Modern python is basically a bucket of puke in between the Annotated crap, async/await, decorators everywhere..the elegance is gone for good. Sad.