5 ms·

I think the general consensus is that that is not true. Python's dynamic nature is a clear advantage it has over statically typed languages. Add the fact that y

I think the general consensus is that that is not true. Python's dynamic nature is a clear advantage it has over statically typed languages. Add the fact that you can elect to tune down the dynamism when it makes sense to with very little impact on your existing stack makes Python the technological superior choice for the majority of applications.

sidlls 9y ago
There's nothing here that tunes down the dynamism. Hints aren't statically checked or enforced. It's still possible to pass in an empty list to an int-hinted var and, e.g. have `if not var` evaluate to True (rather than raise an Exception). Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take advantage of that? Python is a good choice to prototype, write small (less than a few thousand lines of code) projects with non-trivial complexity, and somewhat larger projects with more boilerplate (e.g. Django webapps). Beyond that its utility diminishes until it starts to become a hindrance.
- joshuamorton 9y ago
  >Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take advantage of that? Python's type system is, imo, currently better than Java's, and the syntax is cleaner than java's or C++s. You get all the benefits of static typing without having to put `auto` and `List<>` everywhere. And at the same time, you get all of the advantages that python has over statically typed languages that aren't haskell (like comprehensions). And, when you need to, if you're doing something that's especially tricky or dynamic or whatnot, you can fall back to untypedness. I think the closest parallel I can draw is to something like Rust. You get a huge set of guarantees for free, but can opt to do unsafe things when it's absolutely necessary, and better yet, you can start in unsafe land and then go back later and make sure your code is safe. I'm curious what tooling you feel that say, Java, has over type-annotated python.
  - sidlls 9y ago
    Hints don't provide any guarantees. It's still possible to silently and unknowingly pass the wrong type of value into any given argument, with or without the checker. The "tooling" the other languages have includes a compiler that performs these checks in a way that Hints + Checker-of-choice is unlikely (or unable) to. "What do you think these checkers do?" you might ask. The answer is: not nearly what a compiler does.
    - joshuamorton 9y ago
      > It's still possible to silently and unknowingly pass the wrong type of value into any given argument This is also possible in traditionally statically typed languages. Nothing stops you from doing unsafe casts or using reflection. Much like its exceedingly unlikely that you'll run across this in "normal" java or C++, its exceedingly unlikely for you to run into any issues with this in python. And, in fact, the typechecker has ways to handle unusual things like dynamically created attributes, for when that comes up. And yes I mean this quite honestly. I've seen a lot of typechecked code, some of it quite ridiculously dynamic. Typecheckers perform absolutely fine. >The "tooling" the other languages have includes a compiler that performs these checks in a way that Hints + Checker-of-choice is unlikely (or unable) to. What way is that? Typechecking is static analysis. There's really no difference between how java or cpp does typechecking and how mypy does, other than that the python typechecker isn't installed by default. >The answer is: not nearly what a compiler does. This is not an answer.
      - sidlls 9y ago
        > This is also possible in traditionally statically typed languages. Nothing stops you from doing unsafe casts or using reflection. Neither of those is "silent" or "unknowing". > What way is that? Typechecking is static analysis. There's really no difference between how java or cpp does typechecking and how mypy does, other than that the python typechecker isn't installed by default. The typechecker can't handle un-hinted code (or, rather, it chooses something very permissive, like 'Any' for all hints). It's incomplete at best. > This is not an answer. It is. That you don't like or agree with it doesn't make it not an answer.
- jsjohnst 9y ago
  > Beyond that its utility diminishes until it starts to become a hindrance. Tell that to any serious Numpy/Scipy/Pandas user.
  - sidlls 9y ago
    Being the lead on a data science team I am one of those. They're great for exploratory research and prototyping, and for use in the very tiny fraction of code in a production system that deals with machine learning if I must. For everything else, from the data pipeline to delivering results, I'd prefer and recommend something else, like Haskell, C++, go or Rust.
- ubernostrum 9y ago
  Ah yes, this old chestnut: "(language I don't like) is only suitable for teeny-tiny puny baby child's toy programs, and once you're not writing those anymore you must use a big strong grown-up language like all the other Real Programmers™ do!" The empirical evidence of reality is against you: there are successful large (in terms both of codebase and contributors/development team) projects in these awful terrible children's languages, and there are unmaintainable failed piles of crap in even the most grown-up of languages you'd care to name. The choice of language, and choice of type system, seem not to correlate with the success or failure in a meaningful way.
  - blub 9y ago
    It doesn't correlate with success, but the choice of language does correlate with development speed, number of faults, maintainability, etc. The interesting thing to note is that a language that's perfectly acceptable at the above at small or medium scale might turn into a hindrance at large-scale. An otherwise fast to develop in language like Python won't be so fast if every change has to be painstakingly reviewed and tested due to the complexity of interactions in the code base. Using a type system to verify assumptions/requirements is not a recipe for success, but it can improve reliability.
    - ubernostrum 9y ago
      won't be so fast if every change has to be painstakingly reviewed and tested due to the complexity of interactions in the code base You can write spaghetti code in any language, it turns out. Blaming the language for that is not really an indicator of understanding the problem.
      - blub 9y ago
        Yes one can do a poor job in pretty much any situation, I'm afraid that's not an argument for anything though. Here we're talking about average or best-effort: large code bases are complex in spite of the best intentions of their maintainers, so using tools that can manage that conplexity in an easier way through e.g their type systems could lead to better results.
tigershark 9y ago
Absolutely not. Python is not the technological superior choice for the majority of the applications. If you think so then your experience in different domains and application types must be very limited. The preconcept that dynamic languages are more productive is just an illusion because you can easily take shortcuts that will hamper your progress in the future. A proper typed language with HM type inference has the ability to mostly avoid writing the types with the guarantee that the compiler will catch most of the pitfalls. And if you don't do any logic error pretty much every time your code just works. Saying that in a million line application Python is a better choice than F# or Haskell it's frankly ridiculous in my opinion.
- joshuamorton 9y ago
  Empirically, there are a lot more million line python codebases than F# or haskell codebases, in fact I can name multiple million line python codebases, and 0 F# or haskell codebases. Given that, logic would indicate some sort of failure on the part of haskell and F#, or they would see wider adoption among the large codebases where they are so useful. Do you disagree?
  - tigershark 9y ago
    Given how much smaller is the F# community and how much more you can crank in less lines of codes in F# I can believe it. Between C# and F# there is about an order of magnitude of difference in the LOCs for big projects and C# and Python are comparable from this metric.
    - joshuamorton 9y ago
      It appears you missed my point. I can't think of a 100kloc f# or Haskell codebase, so even if they were 10x as terse as python, which they aren't, python comes out ahead. If they're so much better, why don't people use them?
      - kod 9y ago
        I can think of 100kloc Scala codebases, e.g. Kafka. People do use ML family languages, and they are better. There are plenty of non-technical reasons they aren't as widespread as dynamic languages or shitty static languages.

sidlls 9y ago

There's nothing here that tunes down the dynamism. Hints aren't statically checked or enforced. It's still possible to pass in an empty list to an int-hinted var and, e.g. have `if not var` evaluate to True (rather than raise an Exception). Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take advantage of that? Python is a good choice to prototype, write small (less than a few thousand lines of code) projects with non-trivial complexity, and somewhat larger projects with more boilerplate (e.g. Django webapps). Beyond that its utility diminishes until it starts to become a hindrance.

joshuamorton 9y ago
>Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take advantage of that? Python's type system is, imo, currently better than Java's, and the syntax is cleaner than java's or C++s. You get all the benefits of static typing without having to put `auto` and `List<>` everywhere. And at the same time, you get all of the advantages that python has over statically typed languages that aren't haskell (like comprehensions). And, when you need to, if you're doing something that's especially tricky or dynamic or whatnot, you can fall back to untypedness. I think the closest parallel I can draw is to something like Rust. You get a huge set of guarantees for free, but can opt to do unsafe things when it's absolutely necessary, and better yet, you can start in unsafe land and then go back later and make sure your code is safe. I'm curious what tooling you feel that say, Java, has over type-annotated python.
- sidlls 9y ago
  Hints don't provide any guarantees. It's still possible to silently and unknowingly pass the wrong type of value into any given argument, with or without the checker. The "tooling" the other languages have includes a compiler that performs these checks in a way that Hints + Checker-of-choice is unlikely (or unable) to. "What do you think these checkers do?" you might ask. The answer is: not nearly what a compiler does.
  - joshuamorton 9y ago
    > It's still possible to silently and unknowingly pass the wrong type of value into any given argument This is also possible in traditionally statically typed languages. Nothing stops you from doing unsafe casts or using reflection. Much like its exceedingly unlikely that you'll run across this in "normal" java or C++, its exceedingly unlikely for you to run into any issues with this in python. And, in fact, the typechecker has ways to handle unusual things like dynamically created attributes, for when that comes up. And yes I mean this quite honestly. I've seen a lot of typechecked code, some of it quite ridiculously dynamic. Typecheckers perform absolutely fine. >The "tooling" the other languages have includes a compiler that performs these checks in a way that Hints + Checker-of-choice is unlikely (or unable) to. What way is that? Typechecking is static analysis. There's really no difference between how java or cpp does typechecking and how mypy does, other than that the python typechecker isn't installed by default. >The answer is: not nearly what a compiler does. This is not an answer.
    - sidlls 9y ago
      > This is also possible in traditionally statically typed languages. Nothing stops you from doing unsafe casts or using reflection. Neither of those is "silent" or "unknowing". > What way is that? Typechecking is static analysis. There's really no difference between how java or cpp does typechecking and how mypy does, other than that the python typechecker isn't installed by default. The typechecker can't handle un-hinted code (or, rather, it chooses something very permissive, like 'Any' for all hints). It's incomplete at best. > This is not an answer. It is. That you don't like or agree with it doesn't make it not an answer.
jsjohnst 9y ago
> Beyond that its utility diminishes until it starts to become a hindrance. Tell that to any serious Numpy/Scipy/Pandas user.
- sidlls 9y ago
  Being the lead on a data science team I am one of those. They're great for exploratory research and prototyping, and for use in the very tiny fraction of code in a production system that deals with machine learning if I must. For everything else, from the data pipeline to delivering results, I'd prefer and recommend something else, like Haskell, C++, go or Rust.
ubernostrum 9y ago
Ah yes, this old chestnut: "(language I don't like) is only suitable for teeny-tiny puny baby child's toy programs, and once you're not writing those anymore you must use a big strong grown-up language like all the other Real Programmers™ do!" The empirical evidence of reality is against you: there are successful large (in terms both of codebase and contributors/development team) projects in these awful terrible children's languages, and there are unmaintainable failed piles of crap in even the most grown-up of languages you'd care to name. The choice of language, and choice of type system, seem not to correlate with the success or failure in a meaningful way.
- blub 9y ago
  It doesn't correlate with success, but the choice of language does correlate with development speed, number of faults, maintainability, etc. The interesting thing to note is that a language that's perfectly acceptable at the above at small or medium scale might turn into a hindrance at large-scale. An otherwise fast to develop in language like Python won't be so fast if every change has to be painstakingly reviewed and tested due to the complexity of interactions in the code base. Using a type system to verify assumptions/requirements is not a recipe for success, but it can improve reliability.
  - ubernostrum 9y ago
    won't be so fast if every change has to be painstakingly reviewed and tested due to the complexity of interactions in the code base You can write spaghetti code in any language, it turns out. Blaming the language for that is not really an indicator of understanding the problem.
    - blub 9y ago
      Yes one can do a poor job in pretty much any situation, I'm afraid that's not an argument for anything though. Here we're talking about average or best-effort: large code bases are complex in spite of the best intentions of their maintainers, so using tools that can manage that conplexity in an easier way through e.g their type systems could lead to better results.

tigershark 9y ago

Absolutely not. Python is not the technological superior choice for the majority of the applications. If you think so then your experience in different domains and application types must be very limited. The preconcept that dynamic languages are more productive is just an illusion because you can easily take shortcuts that will hamper your progress in the future. A proper typed language with HM type inference has the ability to mostly avoid writing the types with the guarantee that the compiler will catch most of the pitfalls. And if you don't do any logic error pretty much every time your code just works. Saying that in a million line application Python is a better choice than F# or Haskell it's frankly ridiculous in my opinion.

joshuamorton 9y ago
Empirically, there are a lot more million line python codebases than F# or haskell codebases, in fact I can name multiple million line python codebases, and 0 F# or haskell codebases. Given that, logic would indicate some sort of failure on the part of haskell and F#, or they would see wider adoption among the large codebases where they are so useful. Do you disagree?
- tigershark 9y ago
  Given how much smaller is the F# community and how much more you can crank in less lines of codes in F# I can believe it. Between C# and F# there is about an order of magnitude of difference in the LOCs for big projects and C# and Python are comparable from this metric.
  - joshuamorton 9y ago
    It appears you missed my point. I can't think of a 100kloc f# or Haskell codebase, so even if they were 10x as terse as python, which they aren't, python comes out ahead. If they're so much better, why don't people use them?
    - kod 9y ago
      I can think of 100kloc Scala codebases, e.g. Kafka. People do use ML family languages, and they are better. There are plenty of non-technical reasons they aren't as widespread as dynamic languages or shitty static languages.