I think programmers often misinterpret what’s hard about building large projects.

It’s not correctness it’s communication. A type checker will save you from small errors but well written and easily understandable code will save you from a lot more.

Not saying readability is harder in c# java go or rust just that the type system doesn’t help with it that much.

As a Python developer, I love type annotations on function signatures because they're great, up-to-date documentation. I don't care so much about them being checked, I care that they make the function much easier to read and reason about.

If they weren’t checked, how would you know they are up to date?

I don't care how they're updated, I just care that they are. If that's by checking, it's fine by me.

Agreed. I love both (you can check my post history) but literally the most basic thing trips me up beyond a certain size/scope of programs: typos. Having a little structure that an IDE can leverage makes mountains of difference.

I'm sure a more competent typist wouldn't have these issues but it trips me up constantly just in dev. Tests protect this from hitting prod.

The extra refactor support just isn't there compared to java.

Some of the biggest web services are written with Python. There are tradeoffs, just like everything else. I happen to work for a company with a gigantic python codebase. It would be a hell of a lot easier to refactor our systems if we were in a statically typed system, but we work around this by having shitloads of tests. Tradeoffs.

I don't think python is good for large systems, but for companies, it's hard to get to that point without something that you can prototype quickly with.

Easy. They write code. Code "works". Cool, ship it. Oh what's that? It has lots of bugs? How much money is it going to make us if we fix them? Eh, maybe we'll get to it. /s

The real productivity win here is that you can hire a bunch of junior engineers out of university for "cheap" that "know" python. After all, why would you train a new hire in a different language for a few weeks or months when that would take a huge amount of time in startup-verse? /s?

It's important to note that the largest push for things like type checking and access control in dynamically-typed, shared-mutable-everything languages are coming from the companies that built themselves quickly on these languages and now need to deal with scaling.

Access modifiers are something that I only ever find to get in the way. I've recently moved to Java from Python for work. The underscore convention in python works fine for hiding stuff from the general public namespace, but its still there if you want to explore how some code or module works. Java really annoys me because I can't access implementation details when I'm trying something out in an interactive shell or debugger, even if I'd never access a private/protected variable in production code

The point of access modifiers is to get in the way. They're ways of allowing developers of one part of the source to control what the path of least resistance is for the users of that code.

If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.

It doesn't really matter for small teams, but it's essential for large ones without aggressive (and difficult) enforcement of contract between team members.

If you are working with a large team, you need a statically typed language. Access modifiers are the least of your problems, the lack of refactoring support is a much bigger problem.

I agree, but I was focusing on a single aspect and explaining why its value might not be apparent to the parent commenter. Really, the same argument can be adapted to other contentious features of popular static languages.

> If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.

> It doesn't really matter for small teams

Doesn't even have to be your team. We encountered this by way of a major library, celery.

I forget all the details, but celery was importing something else (name started with a "k", I think), and that was importing an underscore-prefixed function from uuid. Somewhere between python versions 2.7.8 and 2.7.13, the implementation of uuid changed and that import failed.

`foo._a` accessible outside `Foo` but it makes code look gross and means you're doing something wrong.

`foo.__a` accessible only inside `Foo`

I think it works.

> `foo.__a` accessible only inside `Foo`

It's not all that inaccessible. Try:

    class C:
      def __init__(self):
        self.__private = 'Is it private?'
    
    c = C()
    c._C__private

Double underscore names aren't so much about access control (because access control isn't strongly enforced) as about limiting name collisions (by including the class name in the underlying field name).

Specifically, it's about avoiding collision of "private" names via inheritance.

Personally, internal mutation is something you should avoid in general. Pretty hard to avoid in OO languages though.

> How are people writing large programs in Python? Isn’t the lack of compiler type checking making it difficult?

Python 2 and 3 both have AOT static type checkers available (this is essentially “pre-compile-time”). Presumably those for whom not having this would be a problem use it.

> And what about lack of access modifiers?

It's an issue, but use of the conventional underscore prefix makes mitigation via code review fairly simple.

That is why we have python type hints: https://docs.python.org/3/library/typing.html

Not as good as a real static type system with compiler, but still helpful for documenting the code and tools for static code analysis.

With unittests, proper planning and stern discipline. Access-control and typecheckers exist, but they are optional.

> Isn’t the lack of compiler type checking making it difficult?

There is type hinting.

> And what about lack of access modifiers?

There is @property decorators