This was on HN the other day: https://github.com/hwayne/awesome-cold-showers#static-vs-dyn.... I would probably add a caveat to the listed caveats that testing might not be considered? Like if every dynamically typed code base implements an ad-hoc typechecker with a testing framework, it's a distinction without a difference.

I’ve passed wrong type of arguments to Python functions and assumed type of the return value wrong countless of times. That has never happened in Haskell. I don’t know how to reconcile my experience with the statement that there’s no evidence that strong typing reduces bugs.

I program primarily in (untyped) Python (which, I get is technically strongly typed but people don't think in technical terms) these days, and I almost never experience type errors. I guess I could attribute this to a couple things:

- I'm very specific about when I use None

- I'm a big fan of named function arguments

- I like to think my naming of things is pretty good, as are my conventions for parameters

- I try to handle all possible cases (what I mean here is I do and if I don't I made a mistake)

I use tests very sparingly in personal projects, but yet I haven't really felt their absence. If I ever write a piece of particularly hairy code (metaprogramming comes to mind... lord) I'll write a quick script testing some cases and then delete it.

Anyway, all that is to say I think part of dynamic programming is you build an immune system for this stuff.

Python is OK for throwaway code, but I've mostly seen it used for big systems that people (for whatever reason) didn't think were important enough to write in a real language. The people with that opinion don't share your degree of rigor.

I usually avoid bugs in python code by rewriting in bash (at 1-10% the size of the original python, since bash's error handling can be set to "always do the right thing" with "set euxo pipefail")

If bash is a bad fit for the rewrite, go usually works. I don't work on linear algebra software much these days. Python seems to be a good option for that.

Yeah I love Python for quick work and prototyping, and it's great for small web services and as a DSL for data analysis. I suppose I could also envision it as a backend language for a fleet of microservices too.

I think Python gets bailed out a lot because those things turn out to be a lot of programming these days. The people who have a beef w/ Python are those who've worked with it on large, old codebases. This is a tough job for any language though like, raise your hand if you've ever worked on a large, old codebase in C++ or Java that you liked.

Usually when people push microservices I'm quick with Conway's law, saying "this is a tech solution to an organizational problem that won't actually make a difference", and I think I'm right about that. But I think I've been ignoring that a really nice thing about microservices for engineers is you can keep using languages like Python on small codebases, and at least mentally and emotionally avoid the feeling of working on a huge monolith. That counts for something.

I’ve similarly developed my own habits. But why spend our effort into developing habits, when we can address the problems across people --- junior and senior --- automatically with a type system.

Oh 100% agree. The problem I've run into is my habits aren't others' habits, so we burn time arguing about how best to $CODE, and I rarely walk away from those satisfied or more educated (I'm sure this feeling is mutual haha). I wonder if "immune system" is to "type system" as "my special formatting" is to "use a formatter" here.

I think the big win is actually immutable data and pure functions. It just so happens that strong typing tends to come along with these things (e.g. Haskell, OCaml)

Clojure is the big outlier

And Erlang / Elixir. These are also some of the most widely used FP languages in delivering real world software.