| > Have you been in static types the whole time? In fact, Python has been my most-used language for 15+ years and I rarely use annotations. > the Everything Function This doesn't happen in my own code; 10 lines is unusually long for me. In others' code, it comes across that the problem is more to do with not properly splitting up the task (a lot of the time, a reluctance to extract loop bodies, in particular). The case logic does have to go somewhere and it isn't always practical to hide it with polymorphism (which has its own problems; I write my own classes quite a bit less than average I would say, and especially avoid inheritance). It's often better when you have one thing that lays out the case logic explicitly while delegating all the actual work. But aside from Everything Functions, a lot of code bases have more of a problem with the Everything Class that just contains way too much state and still doesn't neatly refactor the work away (and where there are passing attempts to extract a few lines, they often end up in a "method" that doesn't actually touch `self`). > I mean that one of the "everything functions" I tore down had two distinct calling patterns that were distinct functions that not only shouldn't have been festooned with so many options, but never should have been one function at all because they weren't even conceptually the same thing or even particularly related. Yeah, sounds like you work in unusually unpleasant circumstances. But I don't really see how a lack of type expression leads to this kind of thing. The default assumption for the type of a parameter, in untyped Python, should be: "an object that supports the operations currently used with it in the existing code". Going beyond that is like adding additional methods to a class that hasn't actually been written, and needs to be well considered. A lot of people on HN don't seem to like dynamic typing. I think it's more that it's not for them, and that's fine. There will always be people with different mental models. |