5 ms·

I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job. Admittedly I've never done s

by scudd 6y ago

I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job. Admittedly I've never done serious work with mypy (or typescript), so I'm approaching the value proposition of dynamic typing at face value rather than experience. However, it seems like the primary benefit of these languages was ease and flexibility, ableit at the cost of structure. Or said differently, adding mypy feels like trying to get out of a trade-off decision. This situation reminds me of a talk Bryan Cantrill gave on platform core values, and as examples he gave his interpretation of the platform core values of languages like C, Awk, and Scala: https://youtu.be/2wZ1pCpJUIM?t=349 https://youtu.be/2wZ1pCpJUIM?t=349 For me, platform core values that stick out for python would be Approachability, Simplicity, and Velocity. I understand the posited value mypy brings to the table, but it feels in contention with the original core values that made python appealing to begin with.

seanmclo 6y ago
At this point, another big benefit of Python is its huge number of libraries. This is really attractive to lots of people who also want static type checking. Oftentimes, the benefits of using Python in a code base that would benefit from static typing outweigh the costs. Especially when tools like MyPy exist, which aren't perfect but help tremendously.
- nonameiguess 6y ago
  This can't be emphasized enough. I'm presently pushing mypy and type hints hard in a Python project (passing static analysis and type checks is required to get through the CI pipeline) and it's just a compromise. Honestly, I don't want a dynamic duck-typed language at all, but it is what it is. Right now, the single most important factor determining whether we have any future at all is speed to market, not the increased reliability you get from type safety. And Python just has libraries for basically everything. It's enabled us to spin up brand new services that do exactly what we need to do from scratch in a matter of hours sometimes. With competing priorities like that, this is the best we can do right now. The other factor is the rest of the team is already familiar with Python. They're mostly infrastructure developers. They're more likely to do everything in Bash if given the choice. I'm not going to teach them Scala or Haskell or Rust in the next three weeks before we need to deliver something. But I can at least teach them Python's optional type hints and mypy.
- nradov 6y ago
  Java also has a huge number of libraries, plus static type checking.
  - fiedzia 6y ago
    It has many. But I know several companies that move from Java to Python because that's what developers, data engineers and ML/AI experts use.
mixmastamyk 6y ago
Projects tend to change over their lifetime. What might have been yesterday's freewheeling experimental prototype is tomorrow's boring mission-critical geriatric legacy. Sometimes this is (or should be) known in advance, but often not.
- konschubert 6y ago
  Sometimes you know in advance, but you still want to optimize for starting and not for maintaining.
- lmm 6y ago
  Which is why recent language design has converged on sound typing augmented by powerful type inference, so that you can use the same language at any scale. I've worked on ten-line database migration scripts and million-line applications in the same Scala.
  - mixmastamyk 6y ago
    As I have in Python. It has issues at the high end, but with tooling they can mostly be overcome. It could be better, but I'm not complaining. On the other had we have: https://news.ycombinator.com/item?id=26539508 https://news.ycombinator.com/item?id=26539508 Sounds like not everything in Scalaland is sunshine and roses.
freeone3000 6y ago
What's the equivalent for numpy? Tensorflow? Pytorch? The python library support is simply unmatched: regardless of what the base language has as features, the proper choice for many projects is python.
- scudd 6y ago
  I think that consideration of libraries is a good point, I didn't initially consider, and especially relevant for Python. I think the one connection I'd make back to my original point is that perhaps python becoming the defacto interface for certain libraries is still a reflection of its core values. This is especially evident with libraries like Tensorflow, which have interfaces for a breadth of languages, and which the core is implemented in C++. The reason people tend to reach for python to call into Tensorflow is still the core platform values of ease of use, rapid prototyping (imo).
SatvikBeri 6y ago
Python is one of my least favorite languages, but it is a language I absolutely have to use for data work – it would be impractical to rewrite everything in Julia. Type annotations help a lot. They're not perfect, but for long-running jobs it's a huge help to catch something when PyCharm highlights it instead of 30 minutes into the job.
- dreamer7 6y ago
  I'm curious to know what makes it one of your least favourite languages. Could you elaborate? The reason I'm interested is because I love python and would like to hear differing opinions
  - SatvikBeri 6y ago
    Sure! Broadly speaking, I think Python emphasizes a combination of features that lead to code that isn't very composable or decoupled, but without the error-checking benefits you might get in a language like Scala. For example, consider implementing complex rational numbers. If you have a complex number type, and a rational number type, it should be relatively easy to combine them. Julia does this with literally 11 lines of code in Rational.jl, and 0 lines of code in Complex.jl . In Python, this is extremely difficult, to the point that nobody does it – you would need to restructure the class hierarchy, and you can't do that without access to both. Another example is the lack of extension methods. For example, if you want to add a bit of functionality to a string or a sqlalchemy engine, you can either add functions (which have a different syntax) or inherit and follow the awful "MyString" pattern. Python chose to emphasize list comprehensions over map + filter. The problem with that is that you now have syntax that doesn't generalize to other collections, especially custom collections. Some patterns like async/await, decorators, and with syntax encourage hardcoding decisions when writing a function, as opposed to when using it. This makes your functions less flexible and means you have to write more of them. E.g. consider Julia's do-block syntax[1], which is very similar to Python's with but based on function composition and far more general as a result. Or compare Julia's @spawn to Python's async/await. [1]: https://docs.julialang.org/en/v1/manual/functions/#Do-Block-Syntax-for-Function-Arguments https://docs.julialang.org/en/v1/manual/functions/#Do-Block-...
coldtea 6y ago
>I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job. Static typing is not a job though. It's a language feature. The job is solving technical/business problems. And Python is a tool, but it's not a tool to do dynamic typing or static typing with, it's a tool to solve problems with. So, the comment "if you want static typing, you're better off recognizing that python is not the right tool for the job" doesn't quite sit right. You could instead better say that it's not a good fit for Python. But why would that be? Especially since one could easily have said the same for Javacript, but Typescript exists as basically Javascript + types, and people seem to love it. So there's that.
- lmm 6y ago
  Typescript a) is just plain a lot better than mypy b) is still a poor experience compared to using a first-class typed language. The extent to which a) is due to implementation decisions made by typescript/mypy vs being due to inherent differences between Javascript and Python is arguable. Certainly there are things that look like unforced design errors in mypy, and the fact that Dart existed (and largely failed) before Typescript shows that it's not just about what language you're based on. But there are also idioms and aspects of the Python object model that seem inherently hard to type nicely, and are sadly too entrenched in the ecosystem to change.
  - egeozcan 6y ago
    > Typescript (...) is still a poor experience compared to using a first-class typed language. I personally don't agree. I have coded in C# and TS extensively, and while first-class types available in runtime (especially with generics <cough>though not in java</cough>) is super nice, I think the benefits of looseness of TS overweight the costs. Also, you can always go crazy and use zod or io-ts, but in that road there's always the danger of just writing types and not doing any work because "typing is fun"(c).
    - lmm 6y ago
      I spent a couple of days trying to make an app work in typescript before thinking "I'll just give Scala.js a quick try, not going to spend a lot of time on it", and to my surprise everything just worked perfectly.
bryanrasmussen 6y ago
When programmers have learned a particular language really well and they encounter a problem the language does not handle well it is usual for them to want to add some capability to the language to handle their problem rather than going off and learning a new language, often because the constraints of time does not let them learn the new language. There is a tendency to think of pragmatism as throwing away core values in order to solve a problem, although generally this is in the use of the word pragmatism in the domains of business or politics and not in the domain of programming language extensibility.
strken 6y ago
I can't talk about python, but it's convenient to be able to cast something to any in typescript and get all the flexibility of javascript, but also have the rest of your code type checked if you want it. Statically typed languages usually don't let you mix-and-match static typing with duck typing.
dragonwriter 6y ago
> I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job. If the one and only thing you want is static typing, sure. That's, like, never the case in programming, so it's not really meaningful, though. In real world programming scenarios, you are always dealing with balancing multiple dimensional problems and “python, with some degree of static typing” is a reasonable component of the solution for lots of them. > Or said differently, adding mypy feels like trying to get out of a trade-off decision. No, considering python’s available static type checking (whether mypy, pyright, or whatever, or even a combination) is turning a big coarse trade-off decision into one with finer-grained options, not avoiding it. > For me, platform core values that stick out for python would be Approachability, Simplicity, and Velocity. I understand the posited value mypy brings to the table, but it feels in contention with the original core values that made python appealing to begin with. IME using Python’s typing, usually incrementally added, it's not particularly. In fact, it's an enhancer to velocity as the code base evolves.

by scudd 6y ago

seanmclo 6y ago

At this point, another big benefit of Python is its huge number of libraries. This is really attractive to lots of people who also want static type checking. Oftentimes, the benefits of using Python in a code base that would benefit from static typing outweigh the costs. Especially when tools like MyPy exist, which aren't perfect but help tremendously.

nonameiguess 6y ago
This can't be emphasized enough. I'm presently pushing mypy and type hints hard in a Python project (passing static analysis and type checks is required to get through the CI pipeline) and it's just a compromise. Honestly, I don't want a dynamic duck-typed language at all, but it is what it is. Right now, the single most important factor determining whether we have any future at all is speed to market, not the increased reliability you get from type safety. And Python just has libraries for basically everything. It's enabled us to spin up brand new services that do exactly what we need to do from scratch in a matter of hours sometimes. With competing priorities like that, this is the best we can do right now. The other factor is the rest of the team is already familiar with Python. They're mostly infrastructure developers. They're more likely to do everything in Bash if given the choice. I'm not going to teach them Scala or Haskell or Rust in the next three weeks before we need to deliver something. But I can at least teach them Python's optional type hints and mypy.
nradov 6y ago
Java also has a huge number of libraries, plus static type checking.
- fiedzia 6y ago
  It has many. But I know several companies that move from Java to Python because that's what developers, data engineers and ML/AI experts use.

mixmastamyk 6y ago

Projects tend to change over their lifetime. What might have been yesterday's freewheeling experimental prototype is tomorrow's boring mission-critical geriatric legacy. Sometimes this is (or should be) known in advance, but often not.

konschubert 6y ago
Sometimes you know in advance, but you still want to optimize for starting and not for maintaining.
lmm 6y ago
Which is why recent language design has converged on sound typing augmented by powerful type inference, so that you can use the same language at any scale. I've worked on ten-line database migration scripts and million-line applications in the same Scala.
- mixmastamyk 6y ago
  As I have in Python. It has issues at the high end, but with tooling they can mostly be overcome. It could be better, but I'm not complaining. On the other had we have: https://news.ycombinator.com/item?id=26539508 https://news.ycombinator.com/item?id=26539508 Sounds like not everything in Scalaland is sunshine and roses.

freeone3000 6y ago

What's the equivalent for numpy? Tensorflow? Pytorch? The python library support is simply unmatched: regardless of what the base language has as features, the proper choice for many projects is python.

scudd 6y ago
I think that consideration of libraries is a good point, I didn't initially consider, and especially relevant for Python. I think the one connection I'd make back to my original point is that perhaps python becoming the defacto interface for certain libraries is still a reflection of its core values. This is especially evident with libraries like Tensorflow, which have interfaces for a breadth of languages, and which the core is implemented in C++. The reason people tend to reach for python to call into Tensorflow is still the core platform values of ease of use, rapid prototyping (imo).

SatvikBeri 6y ago

Python is one of my least favorite languages, but it is a language I absolutely have to use for data work – it would be impractical to rewrite everything in Julia. Type annotations help a lot. They're not perfect, but for long-running jobs it's a huge help to catch something when PyCharm highlights it instead of 30 minutes into the job.

dreamer7 6y ago
I'm curious to know what makes it one of your least favourite languages. Could you elaborate? The reason I'm interested is because I love python and would like to hear differing opinions
- SatvikBeri 6y ago
  Sure! Broadly speaking, I think Python emphasizes a combination of features that lead to code that isn't very composable or decoupled, but without the error-checking benefits you might get in a language like Scala. For example, consider implementing complex rational numbers. If you have a complex number type, and a rational number type, it should be relatively easy to combine them. Julia does this with literally 11 lines of code in Rational.jl, and 0 lines of code in Complex.jl . In Python, this is extremely difficult, to the point that nobody does it – you would need to restructure the class hierarchy, and you can't do that without access to both. Another example is the lack of extension methods. For example, if you want to add a bit of functionality to a string or a sqlalchemy engine, you can either add functions (which have a different syntax) or inherit and follow the awful "MyString" pattern. Python chose to emphasize list comprehensions over map + filter. The problem with that is that you now have syntax that doesn't generalize to other collections, especially custom collections. Some patterns like async/await, decorators, and with syntax encourage hardcoding decisions when writing a function, as opposed to when using it. This makes your functions less flexible and means you have to write more of them. E.g. consider Julia's do-block syntax[1], which is very similar to Python's with but based on function composition and far more general as a result. Or compare Julia's @spawn to Python's async/await. [1]: https://docs.julialang.org/en/v1/manual/functions/#Do-Block-Syntax-for-Function-Arguments https://docs.julialang.org/en/v1/manual/functions/#Do-Block-...

coldtea 6y ago

>I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job. Static typing is not a job though. It's a language feature. The job is solving technical/business problems. And Python is a tool, but it's not a tool to do dynamic typing or static typing with, it's a tool to solve problems with. So, the comment "if you want static typing, you're better off recognizing that python is not the right tool for the job" doesn't quite sit right. You could instead better say that it's not a good fit for Python. But why would that be? Especially since one could easily have said the same for Javacript, but Typescript exists as basically Javascript + types, and people seem to love it. So there's that.

lmm 6y ago
Typescript a) is just plain a lot better than mypy b) is still a poor experience compared to using a first-class typed language. The extent to which a) is due to implementation decisions made by typescript/mypy vs being due to inherent differences between Javascript and Python is arguable. Certainly there are things that look like unforced design errors in mypy, and the fact that Dart existed (and largely failed) before Typescript shows that it's not just about what language you're based on. But there are also idioms and aspects of the Python object model that seem inherently hard to type nicely, and are sadly too entrenched in the ecosystem to change.
- egeozcan 6y ago
  > Typescript (...) is still a poor experience compared to using a first-class typed language. I personally don't agree. I have coded in C# and TS extensively, and while first-class types available in runtime (especially with generics <cough>though not in java</cough>) is super nice, I think the benefits of looseness of TS overweight the costs. Also, you can always go crazy and use zod or io-ts, but in that road there's always the danger of just writing types and not doing any work because "typing is fun"(c).
  - lmm 6y ago
    I spent a couple of days trying to make an app work in typescript before thinking "I'll just give Scala.js a quick try, not going to spend a lot of time on it", and to my surprise everything just worked perfectly.

bryanrasmussen 6y ago

When programmers have learned a particular language really well and they encounter a problem the language does not handle well it is usual for them to want to add some capability to the language to handle their problem rather than going off and learning a new language, often because the constraints of time does not let them learn the new language. There is a tendency to think of pragmatism as throwing away core values in order to solve a problem, although generally this is in the use of the word pragmatism in the domains of business or politics and not in the domain of programming language extensibility.

strken 6y ago

I can't talk about python, but it's convenient to be able to cast something to any in typescript and get all the flexibility of javascript, but also have the rest of your code type checked if you want it. Statically typed languages usually don't let you mix-and-match static typing with duck typing.

dragonwriter 6y ago

> I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job. If the one and only thing you want is static typing, sure. That's, like, never the case in programming, so it's not really meaningful, though. In real world programming scenarios, you are always dealing with balancing multiple dimensional problems and “python, with some degree of static typing” is a reasonable component of the solution for lots of them. > Or said differently, adding mypy feels like trying to get out of a trade-off decision. No, considering python’s available static type checking (whether mypy, pyright, or whatever, or even a combination) is turning a big coarse trade-off decision into one with finer-grained options, not avoiding it. > For me, platform core values that stick out for python would be Approachability, Simplicity, and Velocity. I understand the posited value mypy brings to the table, but it feels in contention with the original core values that made python appealing to begin with. IME using Python’s typing, usually incrementally added, it's not particularly. In fact, it's an enhancer to velocity as the code base evolves.