9 ms·

Python is not just slow, it also tends to break down for large projects, like all dynamic languages. It is not an absolute, you can do it, but the larger the co

by GuB-42 5y ago

Python is not just slow, it also tends to break down for large projects, like all dynamic languages. It is not an absolute, you can do it, but the larger the code base, the more you need strong guarantees over flexibility, and the less relevant languages like Python tend to become. Prototyping in Python is a viable strategy. Personally I tend to use Perl for that, because I am comfortable with it and I find it better adapted to quick prototyping than Python. I then rewrite in another language, usually C++, with more care about data structures and optimization. The author strategy to do everything in Python than optimize the slow parts can make sense, though I tend to prefer the opposite: white your framework/engine in a static language (like C++) and embed an interpreter (Python, LUA, etc...), as it is common in game dev. But all that are language decisions! Whatever you do, there are going to be consequences. Choosing Python with C/C++/Rust optimizations is not bad, but it is a rather strong opinion, not the obvious default choice the author makes it.

hsn915 5y ago
> it also tends to break down for large projects You also end up spending a lot of time and resources in the later stages of the project trying to work around the problems: hire more people to work on the code base, spend a lot of time investigating optimization strategies, hire a devops team to turn the program into a distributed system with maybe hundreds of instances running on CloudProvider (TM)
- api 5y ago
  > turn the program into a distributed system with maybe hundreds of instances running on CloudProvider (TM) ... and give tens to hundreds of thousands a month to cloud providers when you could spend 1/100th if it were written in Go.
  - hsn915 5y ago
    You could even save the costs by buying your own server. I doubt that you can't buy a very decent server hardware for no more than $10000. Some places pay more than that per month to Amazon.
    - api 5y ago
      But that's not cloud, because cloud!
deltaonefour 5y ago
Modern python (used in production) should be used in conjunction with static type checking apps. Your argument is no longer relevant for modern python. def div(x: Int, y: Int) -> Optional[Int]: return x // y if y != 0 else None The above should be what production level python should look like nowadays. https://www.infoworld.com/article/3575079/4-python-type-checkers-to-keep-your-code-clean.html https://www.infoworld.com/article/3575079/4-python-type-chec... That is not to say the type checking situation for python is perfect, far from it, but the situation is good enough that arguments against python that utilize the dynamic nature of the language are mostly no longer relevant.
- globular-toast 5y ago
  Division by zero should not return None. Is there an aversion to exceptions in "modern" Python?
  - pxc 5y ago
    Why not? If there is no quotient, None seems like a good answer to the question ‘what's the quotient?’
    - deltaonefour 5y ago
      I can see where he's coming from. It's the typical reaction of a beginner programmer. None/Null in many languages isn't type checked even if the language itself has static type checking. It can be passed to other functions mysteriously and remain a hidden error. Javascript and C++ are guilty of this. He's complaining of a safety issue most likely. However note the type signature I specified Optional[Int] encodes the None type into the static type checker. In modern programming this implies Null/None safety at the type level. I'm not up to date with the current state of python type checkers so those type checkers may let some things pass depending on some options you set. See my reply to the other guy for a more detailed expose.
      - globular-toast 5y ago
medo-bear 5y ago
> like all dynamic languages I think you would be surprised by the amount of type-checked bugs that can be eliminated in dynamic languages with standard software engineering practices. have a look at how common lisp, for example, handles type annotations and type warnings: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html instead of blaming dynamic languages, i think project managers need to take on better practices > but the larger the code base, the more you need strong guarantees over flexibility i think i disagree with this. the larger the code base the more flexible the program needs to be towards its input, otherwise your program is too sensitive and it will crash. the output however i think should be strict
- npsimons 5y ago
  > I think you would be surprised by the amount of type-checked bugs that can be eliminated in dynamic languages with standard software engineering practices. have a look at how common lisp To second this, I just read someone's anecdote about how unit tests/TDD is eliminating the need for type checking: https://www.artima.com/weblogs/viewpost.jsp?thread=4639 https://www.artima.com/weblogs/viewpost.jsp?thread=4639 > i think i disagree with this. the larger the code base the more flexible the program needs to be towards its input And again, I'll second this with another anecdotal posting, but with the emphasis that input is not just run-time, but also specifications for programs: http://ivy.io/common-lisp/2015/03/03/guerilla-lisp-opus.html http://ivy.io/common-lisp/2015/03/03/guerilla-lisp-opus.html
exyi 5y ago
Not just dynamic types, but all the breaking changes they make in minor versions. Since the program is "compiled" on user's machine, not yours, you don't even control which version is it going to use. I mean, migrating from Scala 2.12 to 2.13 to is bit annoying, but I can do it whenever I have time. Python 3.9 to 3.10 - ASAP, it's a bug suddenly when they decide to release.

by GuB-42 5y ago

hsn915 5y ago

> it also tends to break down for large projects You also end up spending a lot of time and resources in the later stages of the project trying to work around the problems: hire more people to work on the code base, spend a lot of time investigating optimization strategies, hire a devops team to turn the program into a distributed system with maybe hundreds of instances running on CloudProvider (TM)

api 5y ago
> turn the program into a distributed system with maybe hundreds of instances running on CloudProvider (TM) ... and give tens to hundreds of thousands a month to cloud providers when you could spend 1/100th if it were written in Go.
- hsn915 5y ago
  You could even save the costs by buying your own server. I doubt that you can't buy a very decent server hardware for no more than $10000. Some places pay more than that per month to Amazon.
  - api 5y ago
    But that's not cloud, because cloud!

deltaonefour 5y ago

Modern python (used in production) should be used in conjunction with static type checking apps. Your argument is no longer relevant for modern python. def div(x: Int, y: Int) -> Optional[Int]: return x // y if y != 0 else None The above should be what production level python should look like nowadays. https://www.infoworld.com/article/3575079/4-python-type-checkers-to-keep-your-code-clean.html https://www.infoworld.com/article/3575079/4-python-type-chec... That is not to say the type checking situation for python is perfect, far from it, but the situation is good enough that arguments against python that utilize the dynamic nature of the language are mostly no longer relevant.

globular-toast 5y ago
Division by zero should not return None. Is there an aversion to exceptions in "modern" Python?
- pxc 5y ago
  Why not? If there is no quotient, None seems like a good answer to the question ‘what's the quotient?’
  - deltaonefour 5y ago
    I can see where he's coming from. It's the typical reaction of a beginner programmer. None/Null in many languages isn't type checked even if the language itself has static type checking. It can be passed to other functions mysteriously and remain a hidden error. Javascript and C++ are guilty of this. He's complaining of a safety issue most likely. However note the type signature I specified Optional[Int] encodes the None type into the static type checker. In modern programming this implies Null/None safety at the type level. I'm not up to date with the current state of python type checkers so those type checkers may let some things pass depending on some options you set. See my reply to the other guy for a more detailed expose.
    - globular-toast 5y ago

medo-bear 5y ago

> like all dynamic languages I think you would be surprised by the amount of type-checked bugs that can be eliminated in dynamic languages with standard software engineering practices. have a look at how common lisp, for example, handles type annotations and type warnings: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html instead of blaming dynamic languages, i think project managers need to take on better practices > but the larger the code base, the more you need strong guarantees over flexibility i think i disagree with this. the larger the code base the more flexible the program needs to be towards its input, otherwise your program is too sensitive and it will crash. the output however i think should be strict

npsimons 5y ago
> I think you would be surprised by the amount of type-checked bugs that can be eliminated in dynamic languages with standard software engineering practices. have a look at how common lisp To second this, I just read someone's anecdote about how unit tests/TDD is eliminating the need for type checking: https://www.artima.com/weblogs/viewpost.jsp?thread=4639 https://www.artima.com/weblogs/viewpost.jsp?thread=4639 > i think i disagree with this. the larger the code base the more flexible the program needs to be towards its input And again, I'll second this with another anecdotal posting, but with the emphasis that input is not just run-time, but also specifications for programs: http://ivy.io/common-lisp/2015/03/03/guerilla-lisp-opus.html http://ivy.io/common-lisp/2015/03/03/guerilla-lisp-opus.html

exyi 5y ago

Not just dynamic types, but all the breaking changes they make in minor versions. Since the program is "compiled" on user's machine, not yours, you don't even control which version is it going to use. I mean, migrating from Scala 2.12 to 2.13 to is bit annoying, but I can do it whenever I have time. Python 3.9 to 3.10 - ASAP, it's a bug suddenly when they decide to release.