3 ms·

Most of my serious work has been done with statically typed languages, though of course I have worked with dynamically typed ones as well. There are a few thin

Most of my serious work has been done with statically typed languages, though of course I have worked with dynamically typed ones as well. There are a few things about dynamically typed languages that seem to productivity-negative, but it may just be my lack of understanding of how people expert at a dynamic languages work with them. 1 - When working with a large enough code base that you don't remember exactly what every function you have written needs, or using third party libraries, function signatures lacking type specifications make it harder to know what is expected. if there is documentation that is good, you can of course load that up, but this slows you down. IDEs today can usually show you the function signature as you type it, but with dynamic types you get less information. 2 - When refactoring something in a statically typed language, changing a data structure or type name will cause the compiler to error every single place that you need to adjust for your change. With a dynamic language you need to rely on unit tests or you will be finding places you missed during runtime for a long time afterwards. If you do rely on unit tests for this kind of thing, then you have sort of built an effectively statically typed environment, at some large degree of effort, with worse runtime performance to show for it. I understand some of the workarounds people use to deal with these problem but a lot of them seem to push you to the point that you might as well use static typing and get better runtime performance for it.

Rotareti 8y ago
Python has type annotations since 3.5 and you can get static type checking via mypy. This is a type system that works quite well IMHO and eleminates most of the issues you mentioned.
- kod 8y ago
  The main benefit of Python is the ecosystem of libraries. Those libraries don't have type annotations. Mypy is a far cry from a real statically typed language.
  - weberc2 8y ago
    There is typeshed for stubbing libraries that don’t have their own annotations, but there are still several popular libraries that can’t be annotated—like SQLAlchemy or boto—because they generate their own types at runtime.
- theshrike79 8y ago
  The problem is that WAY too many projects are still on Python 2.x. Either some weird support library hasn't been upgraded to 3.x yet or some expensive piece of software/hardware can't be accessed with Python 3.x
  - garettmd 8y ago
    Have you used Python and Python libraries recently? That used to be the case, but ever since the Python 2 "death clock" has started this has become a fairly rare occurrence, except in some specific domains.
- weberc2 8y ago
  As someone who does most of their professional development in Python, I’ve been eagerly waiting for something like Mypy, but my experience with it has been really disappointing and frustrating compared to languages like Go. Mypy mostly seems immature, buggy, and completely unergonomic (typing support was shoehorned into the syntax so most things chafe—declaring a type variable or a callable that takes args and kwargs). Python needs a better static typing story in order to be a productive language in medium-to-large-sized projects.
  - Rotareti 8y ago
    As someone who works full time in Python and TypeScript, I find the typing experience quite similar in both languages. You can be "productive" in both languages "in medium-to-large-sized projects". > Mypy mostly seems immature, buggy ... That was my experience some time ago as well, but it's getting better from release to release. Look at the repo [0], it's continuously improving. I find Mypy deserves more recognition. The same guys working on mypyc [1], which I think is very interesting too. [0]: https://github.com/python/mypy/graphs/contributors https://github.com/python/mypy/graphs/contributors [1]: https://github.com/mypyc/mypyc https://github.com/mypyc/mypyc
    - weberc2 8y ago
      That’s great to hear. It’s been a while so I should go back and try it again!
sjellis 8y ago
I think that you are right, but I'd say that the underlying issue behind these points is the number of people working on the project. Dynamic languages mean that you can rely on implicit knowledge, rather than be explicit about everything. If your project is just _your_ project, then dynamic languages let you start faster and produce quicker. Apart from anything else, these languages attract people who value productivity, so clunky tools don't survive in those ecosystems. Of course, almost no successful project stays in the hands of just one or two people: new developers come in, or it's Open Source and more people show up, as well as the "drive-by" contributions. IME, Ruby on Rails projects scale to about three core developers before you start to feel pain. The strict conventions of the framework help mitigate the communications issues of keeping people in sync. Beyond that, the implicit knowledge that is not in the codebase is harder and harder to scale.

Rotareti 8y ago

Python has type annotations since 3.5 and you can get static type checking via mypy. This is a type system that works quite well IMHO and eleminates most of the issues you mentioned.

kod 8y ago
The main benefit of Python is the ecosystem of libraries. Those libraries don't have type annotations. Mypy is a far cry from a real statically typed language.
- weberc2 8y ago
  There is typeshed for stubbing libraries that don’t have their own annotations, but there are still several popular libraries that can’t be annotated—like SQLAlchemy or boto—because they generate their own types at runtime.
theshrike79 8y ago
The problem is that WAY too many projects are still on Python 2.x. Either some weird support library hasn't been upgraded to 3.x yet or some expensive piece of software/hardware can't be accessed with Python 3.x
- garettmd 8y ago
  Have you used Python and Python libraries recently? That used to be the case, but ever since the Python 2 "death clock" has started this has become a fairly rare occurrence, except in some specific domains.
weberc2 8y ago
As someone who does most of their professional development in Python, I’ve been eagerly waiting for something like Mypy, but my experience with it has been really disappointing and frustrating compared to languages like Go. Mypy mostly seems immature, buggy, and completely unergonomic (typing support was shoehorned into the syntax so most things chafe—declaring a type variable or a callable that takes args and kwargs). Python needs a better static typing story in order to be a productive language in medium-to-large-sized projects.
- Rotareti 8y ago
  As someone who works full time in Python and TypeScript, I find the typing experience quite similar in both languages. You can be "productive" in both languages "in medium-to-large-sized projects". > Mypy mostly seems immature, buggy ... That was my experience some time ago as well, but it's getting better from release to release. Look at the repo [0], it's continuously improving. I find Mypy deserves more recognition. The same guys working on mypyc [1], which I think is very interesting too. [0]: https://github.com/python/mypy/graphs/contributors https://github.com/python/mypy/graphs/contributors [1]: https://github.com/mypyc/mypyc https://github.com/mypyc/mypyc
  - weberc2 8y ago
    That’s great to hear. It’s been a while so I should go back and try it again!

sjellis 8y ago

I think that you are right, but I'd say that the underlying issue behind these points is the number of people working on the project. Dynamic languages mean that you can rely on implicit knowledge, rather than be explicit about everything. If your project is just _your_ project, then dynamic languages let you start faster and produce quicker. Apart from anything else, these languages attract people who value productivity, so clunky tools don't survive in those ecosystems. Of course, almost no successful project stays in the hands of just one or two people: new developers come in, or it's Open Source and more people show up, as well as the "drive-by" contributions. IME, Ruby on Rails projects scale to about three core developers before you start to feel pain. The strict conventions of the framework help mitigate the communications issues of keeping people in sync. Beyond that, the implicit knowledge that is not in the codebase is harder and harder to scale.