5 ms·

What the heck is 'bar' and 'baz'? So there's no docstring? And the actual variables are that random and indecipherable? Sounds like the problem is that you'r

by vanusa 5y ago

What the heck is 'bar' and 'baz'? So there's no docstring? And the actual variables are that random and indecipherable? Sounds like the problem is that you're tasked with looking at code written by someone who is either inexperienced or fundamentally careless. When dealing with reasonably maintained codebases, this kind of situation would seem pretty rare. In modern python we now have type hints of course, which have helped quite a lot.

maxwell86 5y ago
> In modern python we now have type hints of course, which have helped quite a lot. I had to laugh, hard. If your Python program uses any library whatsoever, chances are that library won't have types, so you can't really use them. Even super widely used libraries like numpy don't have good support for types, much less any library that consumes numpy for obvious reasons.
- vanusa 5y ago
  I had to laugh, hard. It's fine if you want to insulate yourself. But I don't see that you're making much of a point here.
  - arc619 5y ago
    They're probably laughing because a) you're suggesting manually doing the work static typing does in a dynamic language because its untenable not to for large projects, and b) you can't easily add type hints to other people's libraries.
    - vanusa 5y ago
      No - (a) is not what I'm suggesting. And (b) while disappointing, just doesn't slow one's work down very frequently in daily practice. Look, I just don't buy the suggestion that static typing magically solves a huge set of problems (or that it does so without imposing negative tradeoffs of its own -- the very topic of the original article). Or that dynamic languages are plainly crippled, and that one has to be a kind of a simpleton not to see this obvious fact.
      - yakshaving_jgt 5y ago
        > I just don't buy the suggestion that static typing magically solves a huge set of problems // compiles and runs, but does bad things function foo(x, y) { someDangerousEffect(); return x + y; } -- does not compile; huge sets of problems magically solved foo :: Int -> Int -> Int foo x y = someDangerousEffect >> pure $ x + y
        vanusa 5y ago
        A problem but not a huge one in practice. And you're neglecting the part of my statement you conveniently truncated.
        yakshaving_jgt 5y ago
        > not a huge one in practice. Our experiences have been wildly different :)
        vanusa 5y ago
        Yeah, life sometimes gets that way.
      - arc776 5y ago
        > just doesn't slow one's work down very frequently in daily practice. Well, maybe you don't feel it slows you down, but it is manual work you must do to get a reliable product only because of dynamic typing. Not only that, but you have to then refer to these docs to check you're not creating a type calamity at some nebulous point down the run time road. Static languages just won't let you mess that up, and often have utilities to generate this documentation for you at no effort. > I just don't buy the suggestion that static typing magically solves a huge set of problems Static typing really does "magically" solve a whole class of problems without any negative tradeoffs, assuming the language has decent type inference. Not all problems, but a specific class of them that you should do extra work to guard against in dynamic languages. Whether that is extra documentation that has to be reliably updated and checked, or run time code to check the types are what you expect at the point of use. Take for example JavaScript, where typing is not only dynamic, but weak. Numbers in particular can be quite spicy when mixed with strings as I'm sure you know. Strong, static typing forces you to be explicit in these cases and so removes this problem entirely. By the way, no one's saying anyone is a simpleton. The reality is our field is wide and varied, and different experiences are valid. Dynamic languages can do some things that static languages can't. For example, you can return completely different types from different execution paths in the same function. This has been something that has confused me when reading Python, but it does make it easier for stuff like tree parsing. In a static language you need to specify some variant mechanism that knows all data possibilities ahead of time to allow this. From my perspective the dynamic typing trade off isn't worth these bits of 'free' run time flexibility, but YMMV! It really depends what arena you're working in and what you're doing.
duped 5y ago
Coming from any statically typed language to Python or JavaScript codebases this plagues me. Virtually every project I have seen suffers from this. Function names and doc comments describe behavior, not argument and return types.
- vanusa 5y ago
  Not argument and return types. When conventions are followed they do exactly that, actually. And unless the code is a complete trainwreck, it's pretty easy to tell what the return type is, even without explicit annotation in the docstring.
  - duped 5y ago
    What conventions are those, besides Hungarian notation (which I don't think I've ever seen in Python)?
    - vanusa 5y ago
      PEP 257, and local conventions in certain projects. What all comes down to is: if you really have people on your project writing code like the foo/bar/baz example way up above - then you have problems way bigger than static type checks can possibly help you with.
      - duped 5y ago
        Wouldn't it be something if there existed tooling that enforced this level of discipline and checked its validity before executing any code such that you didn't rely on the entire ecosystem to adhere to the same standards and remove that as a source of ambiguity...
        vanusa 5y ago
        Which Python has had since 3.5.
- kgeist 5y ago
arc619 5y ago
In other words, in Python you have to rely on your colleagues manually writing documentation, and if they don't you're out of luck and they're 'bad developers' and potentially the whole product is affected. In static languages this simply isn't a problem. Types are checked for consistency at compile time and you don't have to rely on people toiling on this busy work. Not to say documentation isn't necessary, or good, but isn't something you need to create working programs because otherwise no one knows wtf any variable is without running the program.
- vanusa 5y ago
  No, actually I advocate static typing approaches for precisely the reasons you give. As does Python, since years and years ago. I'm just saying that core problem it solves -- "bad developers" -- is going bite you no matter what (if not addressed at the source). And that supposed magical efficacy of measures designed to protect against it is somewhat overstated.
- prewett 5y ago
  What I've found is even worse: on medium-size personal projects I inevitably pass the wrong type to a function (or refactor and forget to change a call somewhere). Generally it does not fail until somewhere else, which relies on it being a certain type. So even though I know what my functions should take, I still spend a bunch of time tracking down the problems, which involves a printing out a lot of stuff because the error happened outside the current call stack. This is something a static type system would just prevent for me, and I've basically decided that anything beyond really simple stuff is actually faster for me to write in a statically typed language. (Examples in the past are a parser for a static site generator with a mostly Turing-complete language, and 3D model generators)
timeon 5y ago
I do not want to argument against Python. This is more like off topic / side note. What I like about Rust is that it even checks code in your 'docstring'. So it is easier to keep it maintained.

by vanusa 5y ago

maxwell86 5y ago

> In modern python we now have type hints of course, which have helped quite a lot. I had to laugh, hard. If your Python program uses any library whatsoever, chances are that library won't have types, so you can't really use them. Even super widely used libraries like numpy don't have good support for types, much less any library that consumes numpy for obvious reasons.

vanusa 5y ago
I had to laugh, hard. It's fine if you want to insulate yourself. But I don't see that you're making much of a point here.
- arc619 5y ago
  They're probably laughing because a) you're suggesting manually doing the work static typing does in a dynamic language because its untenable not to for large projects, and b) you can't easily add type hints to other people's libraries.
  - vanusa 5y ago
    No - (a) is not what I'm suggesting. And (b) while disappointing, just doesn't slow one's work down very frequently in daily practice. Look, I just don't buy the suggestion that static typing magically solves a huge set of problems (or that it does so without imposing negative tradeoffs of its own -- the very topic of the original article). Or that dynamic languages are plainly crippled, and that one has to be a kind of a simpleton not to see this obvious fact.
    - yakshaving_jgt 5y ago
      > I just don't buy the suggestion that static typing magically solves a huge set of problems // compiles and runs, but does bad things function foo(x, y) { someDangerousEffect(); return x + y; } -- does not compile; huge sets of problems magically solved foo :: Int -> Int -> Int foo x y = someDangerousEffect >> pure $ x + y
      - vanusa 5y ago
        A problem but not a huge one in practice. And you're neglecting the part of my statement you conveniently truncated.
        yakshaving_jgt 5y ago
        > not a huge one in practice. Our experiences have been wildly different :)
        vanusa 5y ago
        Yeah, life sometimes gets that way.
    - arc776 5y ago
      > just doesn't slow one's work down very frequently in daily practice. Well, maybe you don't feel it slows you down, but it is manual work you must do to get a reliable product only because of dynamic typing. Not only that, but you have to then refer to these docs to check you're not creating a type calamity at some nebulous point down the run time road. Static languages just won't let you mess that up, and often have utilities to generate this documentation for you at no effort. > I just don't buy the suggestion that static typing magically solves a huge set of problems Static typing really does "magically" solve a whole class of problems without any negative tradeoffs, assuming the language has decent type inference. Not all problems, but a specific class of them that you should do extra work to guard against in dynamic languages. Whether that is extra documentation that has to be reliably updated and checked, or run time code to check the types are what you expect at the point of use. Take for example JavaScript, where typing is not only dynamic, but weak. Numbers in particular can be quite spicy when mixed with strings as I'm sure you know. Strong, static typing forces you to be explicit in these cases and so removes this problem entirely. By the way, no one's saying anyone is a simpleton. The reality is our field is wide and varied, and different experiences are valid. Dynamic languages can do some things that static languages can't. For example, you can return completely different types from different execution paths in the same function. This has been something that has confused me when reading Python, but it does make it easier for stuff like tree parsing. In a static language you need to specify some variant mechanism that knows all data possibilities ahead of time to allow this. From my perspective the dynamic typing trade off isn't worth these bits of 'free' run time flexibility, but YMMV! It really depends what arena you're working in and what you're doing.

duped 5y ago

Coming from any statically typed language to Python or JavaScript codebases this plagues me. Virtually every project I have seen suffers from this. Function names and doc comments describe behavior, not argument and return types.

vanusa 5y ago
Not argument and return types. When conventions are followed they do exactly that, actually. And unless the code is a complete trainwreck, it's pretty easy to tell what the return type is, even without explicit annotation in the docstring.
- duped 5y ago
  What conventions are those, besides Hungarian notation (which I don't think I've ever seen in Python)?
  - vanusa 5y ago
    PEP 257, and local conventions in certain projects. What all comes down to is: if you really have people on your project writing code like the foo/bar/baz example way up above - then you have problems way bigger than static type checks can possibly help you with.
    - duped 5y ago
      Wouldn't it be something if there existed tooling that enforced this level of discipline and checked its validity before executing any code such that you didn't rely on the entire ecosystem to adhere to the same standards and remove that as a source of ambiguity...
      - vanusa 5y ago
        Which Python has had since 3.5.
kgeist 5y ago

arc619 5y ago

In other words, in Python you have to rely on your colleagues manually writing documentation, and if they don't you're out of luck and they're 'bad developers' and potentially the whole product is affected. In static languages this simply isn't a problem. Types are checked for consistency at compile time and you don't have to rely on people toiling on this busy work. Not to say documentation isn't necessary, or good, but isn't something you need to create working programs because otherwise no one knows wtf any variable is without running the program.

vanusa 5y ago
No, actually I advocate static typing approaches for precisely the reasons you give. As does Python, since years and years ago. I'm just saying that core problem it solves -- "bad developers" -- is going bite you no matter what (if not addressed at the source). And that supposed magical efficacy of measures designed to protect against it is somewhat overstated.
prewett 5y ago
What I've found is even worse: on medium-size personal projects I inevitably pass the wrong type to a function (or refactor and forget to change a call somewhere). Generally it does not fail until somewhere else, which relies on it being a certain type. So even though I know what my functions should take, I still spend a bunch of time tracking down the problems, which involves a printing out a lot of stuff because the error happened outside the current call stack. This is something a static type system would just prevent for me, and I've basically decided that anything beyond really simple stuff is actually faster for me to write in a statically typed language. (Examples in the past are a parser for a static site generator with a mostly Turing-complete language, and 3D model generators)

timeon 5y ago

I do not want to argument against Python. This is more like off topic / side note. What I like about Rust is that it even checks code in your 'docstring'. So it is easier to keep it maintained.