Lots of things work when your people and processes are good enough. We don't need seatbelts if we never crash. That can lead to problems with scaling your team if needed, however. At some point you might have to let a moron in, and stronger typing just might be the thing that prevents a catastrophic bug.

I did Python for embedded systems for a year. Python is so expressive and well equipped, but the lack of pre-execution type analysis leaves you vulnerable to severe defects unless your testing coverage is 100%. I would prefer Java over Python just for the safety the compilation step provides(and I don't care for Java). I love programming in Python, but system reliability trumps my personal desires in this case.

I'm sure you know this already but you might want to check out:

- https://docs.python.org/3/library/typing.html

- http://mypy-lang.org

Also flake8 has also helped -- it's just a linter but using it in conjunction with the typing module and running that in a watch loop in another terminal window has done wonders for me.

And that's awesome, but if you're dealing with a large legacy codebase it will take a while to annotate your code.

I love flake8. Properly tuned, it can be a great help. It saved my butt more than once.

You mean static-typing.

Both Java & Python are strongly typed..

e.g. in python, <3 + "2"> gives <TypeError: unsupported operand type(s) for +: 'int' and 'str'>

Strong typing is static, but usually entails more strictness (e.g. not allowing implicit nulls) and more features at typelevel (e.g. sum types, higher level types).

This really depends on definitions of strong and weak and this might be another point but C could be considered a static and weak language. Not sure of any other language like this.

> We stopped solely using strong-types after decades of only doing JAVA and C#, and it hasn’t decreased our code-quality.

How do you know this? It's exceedingly rare that anyone actually keeps track and monitors rate of defects in any application, but there have been studies done[0][1] on the ability of stronger typing in languages to reduce errors.

My condolences for your time using Java and C# -- they are often what people first consider when they think of languages with "good" type systems, but I dislike them both because what they introduce as "good" type systems are often very much not, in comparison to languages like Haskell.

It's a bit disingenuous to act like Haskell has been a performant/production-ready option as long as those languages but still, almost every time I talk to someone and we get to the topic of typing I almost always assume that their bad experiences came from those languages.

> We didn’t leave strong-typing to leave strong-typing btw, we just started doing more and more with Python.

What are your opinions on https://docs.python.org/3/library/typing.html ?

[0]: http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/...

[1]: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2935596/

I work in public service, we track and benchmark everything. Often way more than is needed, but that’s the consequence of a governing body that is very interested but doesn’t necessarily understand what you do.

I think we’ll see more and more use of the typing library, especially on big projects. Similarly we’re having debates on typescript for front-ends, not because we need it right now, but because it’ll probably really suck if it turns out we were wrong about not needing it.

I have years of experience with typed ECMAScript (3 years of ActionScript 3, 2 years of Java and 1 year of TypeScript).

What you're saying here and in your previous comment makes sense. From my experience, engineers who have a LOT of diverse experiences with different paradigms tend to agree that types don't reduce bug density in the code.

Types are a learning tool like training wheels on a bike; with comparable costs in terms of efficiency. Don't get me wrong, training wheels are great but you won't find them at the Olympics.

> Types are a learning tool like training wheels on a bike; with comparable costs in terms of efficiency. Don't get me wrong, training wheels are great but you won't find them at the Olympics.

That is such an idiotic comparison, I don't really know what to say here.

1.) Proper type inference means you don't have to explicitly write out most/any types, so there is no "cost in terms of efficiency". Some annotations might be required from time to time. If the type checker throws an error that means that your types don't align and that you further reason about your program - which is something you need to do in dynamic languages as well, just without any assurance in the first place.

2.) Types allow performance optimisations not available in dynamically typed languages, so again - no "cost in efficiency".

3.) In dynamic languages you don't get as much help from your tools as in static languages, so you can't exclude whole classes of bugs that your compiler finds for you.

So, where does this "cost in efficiency" occur? How is static code analysis a "training wheel"?

>and it hasn’t decreased our code-quality.

But it is.