[cycomanic]

I think this is actually a big difference between SWEs and programmers who are scientists/data scientists/analysts etc. first. In my experience, people with more formal education in programming find type systems to be very helpful, while people from other backgrounds, find them confusing and an nuisance.

[hnarn]

I don’t think you need a “formal education” to see the benefits of strong typing. Whether someone is attracted to it or not probably has more to do with their specific use case.

Strongly typed languages is simply a trade off where you get peace of mind by paying for it with extra time and effort spent. For some people that’s a no-brainer and for some people that’s just something that gets in the way.

My background is mostly in sysops and monitoring, and for me types are a life-saver because I value stability and predictability over almost anything else. If my job was something more similar to “ship new stuff fast” I’m not sure that would be the case.

[adamddev1]

I agree it's a trade off but for me the ratio of effort spent/effort saved in lack of bugs and peace of minds is like 1/1000. Such a tiny bit of effort for huge payback in effort/mental energy saved.

[xedrac]

> If my job was something more similar to “ship new stuff fast”

Ironically, the slowest moving codebase I have ever seen was written in Python. It was impossible to "ship new stuff fast" without breaking things. I think Python works up to a certain size/complexity level, then it completely falls apart.

[michaelcampbell]

Yes; I've come to realize the yarn "Internal quality and productivity rise and fall together" is more true than I ever thought. And with python, (and IME most dynamically typed languages), the internal quality has far more ways to go awry.

[BerislavLopac]

> the benefits of strong typing

A couple of comments here:

1. Python is very strongly typed, every single item has a clearly defined type. That said, it is dynamically typed, meaning that the variables are not a "containers" for predefined types, but simply labels on objects.

2. What brings benefits is not static typing itself, but static analysis which is mandatory in most statically typed languages (i.e. the program won't compile/interpret if the analysis breaks). With tools like mypy Python has a perfectly capable static analysis - even without any type annotations, although they massively improve it - it's just not mandatory and the program will happily run even if it fails.

[michaelcampbell]

> I don’t think you need a “formal education” to see the benefits of strong typing.

Which is not what P said. They said those that have it tend to favor strong typing; those that don't tend to not.

IME I've seen the same thing. It's not a rule, it's a generalization that is often wrong, but more often right. Again, IME. YEMV.

[lgas]

Just anecdotal, but I dropped out after a year or so of CS and I value types more than the vast majority of developers I've ever worked with, most of whom have much more formal education than I do.

[dpkirchner]

You may well be right. Personally, I dislike writing python because it lacks static types and all too often I end up triggering runtime exceptions, especially when integrating with third-party code. Do you suppose scientists/etc are more tolerant of runtime errors, at least while writing the code?

[cycomanic]

In my experience, the biggest issue in numerical/scientific code is to get correct results, these cases will hardly every be caught by typing. Moreover in many scientific programs you deal with well defined inputs, i.e. the chances of e.g. calling a function with an incompatible type are quite low. The most common error I have encountered is a mismatch in dimensionality/shape of input arrays (which I believe isn't straight forward to type for either, in particular if you want the shapes to be flexible, but all inputs to have the same shape).

[mixmastamyk]

Try pyflakes, it will find a majority of those.

[notpushkin]

Wemake [1] is much more comprehensive, although you might find it overwhelming at first. It includes a lot of useful flake8 rules that tackle complexity, enforce consistency and best practices and much much more.

[1]: https://wemake-python-styleguide.readthedocs.io/en/latest/

[mixmastamyk]

Styling is not the problem the poster was complaining about, and why I specifically chose pyflakes out of dozens of such tools.

[ShredKazoo]

Relevant: https://danluu.com/empirical-pl/

[password1]

I feel naked without static types and my background is in humanities.