4 ms·

> Python is great for small scripts or explorations. I've used Python on program with >30000 LOC without any problems.

VectorLock 4y ago
Typically large code bases have problems that are more intrinsic to organization than what language its in. Huge code cases in any language are usually fine if discipline is exercised. And concurrency issues and memory overhead problem are from not knowing the right way to do it. Although I will concede that naive approach to both of those is sub-optimal.
- cwalv 4y ago
  > Although I will concede that naive approach to both of those is sub-optimal. Paradoxically, this can actually lead to a better understanding of how to write performant code. When I first learned some of the be implementation details of python, I couldn't believe it was performant enough to work for anything ... after optimizing enough of it, I understand better what actually matters
  - VectorLock 4y ago
    Also people seem to forget the rule of premature optimization. Worry about performance when performance starts to be a problem. You identify the area with performance is lacking and optimize that. Compute is cheap, manpower is expensive.
LudwigNagasena 4y ago
Do you really have no problems? I find the lack of proper type support and proper variable scoping to be a huge issue.
- ReflectedImage 4y ago
  Lack of typing support is a major advantage. If you don't have types you don't need interfaces, generics, etc. The resulting code is shorter and less bug prone.
  - LudwigNagasena 4y ago
    You still need all of that. You just have to store that information in documentation and do analysis in your head instead of relying on a static analyzer.
    - ReflectedImage 4y ago
      No, you really don't. Static typing is very complex and error prone compared to dynamic typing. There is a lot less stuff that needs remembering.
  - rjh29 4y ago
    Languages like Python and TypeScript support 'any' as a type, so you can always opt out of strong typing if you want. Most of the time generics are preferable to things randomly dying at runtime though.
    - ReflectedImage 4y ago
      Things don't die very often due to typing issues. The unit tests always pick up typing problems. Testing the code's behavior implies testing the code's typing. And if you are not testing the code's behavior then the code isn't really tested at all.
      - rjh29 4y ago
        Does your code check every single variable is not null before using it? That every function argument is of the expected type? That every attribute exists before it is accessed? And do you have unit tests for all of this too? If so - then you're writing a whole lot of manual checking that a strongly typed language would perform for you, at compile time. If not - well then you're doing less testing than a strongly typed language would. I agree that these issues are rare, and there is evidence that strongly typed languages have a similar number of bugs to dynamic ones. But suggesting that because you have unit tests, you don't need strong types, is a bit naive to me.
- cabalamat 4y ago
  Python has types now (though it didn't when I wrote the 36kLOC program I had in mind). What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?
  - LudwigNagasena 4y ago
    > though it didn't when I wrote the 36kLOC program I had in mind). Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript. And even though it is much better after 3.8 and 3.9 updates, the adoption of typing in various useful libraries was relatively low as far as I remember. > What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough? Maybe it is just me, but the scoping rules feel weird: blocks like "with"-statement or for-loops don't create scopes. There is no distinction between declaration and assignment. Sometimes you have to use those weird "nonlocal" and "global".
    - rjh29 4y ago
      The scoping is bad, they should have copied Perl's "every block is a new scope" and added an explicit "let" keyword to define variables instead of overloading assignment. The "nonlocal" and "global" and stuff like "lambda x=x" is a big giveaway that their approach was wrong, but I guess it was too late to change it. The typing has been great in my experience. Most of my deps have types and if they don't I can autogenerate them. The powerful typing of TypeScript is mostly not needed if you're not interacting with JS code.
    - cabalamat 4y ago
      > Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript. I used comments in the code to say what the types were, e.g.: def processNotesForm(d): """ process the notes form @param d::{str:str} = the form data """ Of course in modern Python one would simply say: def processNotesForm(d: Dict[str,str]):

Typically large code bases have problems that are more intrinsic to organization than what language its in. Huge code cases in any language are usually fine if discipline is exercised. And concurrency issues and memory overhead problem are from not knowing the right way to do it. Although I will concede that naive approach to both of those is sub-optimal.

cwalv 4y ago
> Although I will concede that naive approach to both of those is sub-optimal. Paradoxically, this can actually lead to a better understanding of how to write performant code. When I first learned some of the be implementation details of python, I couldn't believe it was performant enough to work for anything ... after optimizing enough of it, I understand better what actually matters
- VectorLock 4y ago
  Also people seem to forget the rule of premature optimization. Worry about performance when performance starts to be a problem. You identify the area with performance is lacking and optimize that. Compute is cheap, manpower is expensive.

LudwigNagasena 4y ago

Do you really have no problems? I find the lack of proper type support and proper variable scoping to be a huge issue.

ReflectedImage 4y ago
Lack of typing support is a major advantage. If you don't have types you don't need interfaces, generics, etc. The resulting code is shorter and less bug prone.
- LudwigNagasena 4y ago
  You still need all of that. You just have to store that information in documentation and do analysis in your head instead of relying on a static analyzer.
  - ReflectedImage 4y ago
    No, you really don't. Static typing is very complex and error prone compared to dynamic typing. There is a lot less stuff that needs remembering.
- rjh29 4y ago
  Languages like Python and TypeScript support 'any' as a type, so you can always opt out of strong typing if you want. Most of the time generics are preferable to things randomly dying at runtime though.
  - ReflectedImage 4y ago
    Things don't die very often due to typing issues. The unit tests always pick up typing problems. Testing the code's behavior implies testing the code's typing. And if you are not testing the code's behavior then the code isn't really tested at all.
    - rjh29 4y ago
      Does your code check every single variable is not null before using it? That every function argument is of the expected type? That every attribute exists before it is accessed? And do you have unit tests for all of this too? If so - then you're writing a whole lot of manual checking that a strongly typed language would perform for you, at compile time. If not - well then you're doing less testing than a strongly typed language would. I agree that these issues are rare, and there is evidence that strongly typed languages have a similar number of bugs to dynamic ones. But suggesting that because you have unit tests, you don't need strong types, is a bit naive to me.
cabalamat 4y ago
Python has types now (though it didn't when I wrote the 36kLOC program I had in mind). What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?
- LudwigNagasena 4y ago
  > though it didn't when I wrote the 36kLOC program I had in mind). Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript. And even though it is much better after 3.8 and 3.9 updates, the adoption of typing in various useful libraries was relatively low as far as I remember. > What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough? Maybe it is just me, but the scoping rules feel weird: blocks like "with"-statement or for-loops don't create scopes. There is no distinction between declaration and assignment. Sometimes you have to use those weird "nonlocal" and "global".
  - rjh29 4y ago
    The scoping is bad, they should have copied Perl's "every block is a new scope" and added an explicit "let" keyword to define variables instead of overloading assignment. The "nonlocal" and "global" and stuff like "lambda x=x" is a big giveaway that their approach was wrong, but I guess it was too late to change it. The typing has been great in my experience. Most of my deps have types and if they don't I can autogenerate them. The powerful typing of TypeScript is mostly not needed if you're not interacting with JS code.
  - cabalamat 4y ago
    > Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript. I used comments in the code to say what the types were, e.g.: def processNotesForm(d): """ process the notes form @param d::{str:str} = the form data """ Of course in modern Python one would simply say: def processNotesForm(d: Dict[str,str]):