For the record, what I stated is fact, not opinion. Python is a fine language for the disciplined lone developer, but a terrible one for most teams. And it is not up to you to suppress this fact as you surely seem to want to do.

If you want to make the case that Python is too flexible and it does not have guardrails for less experienced developers and undisciplined teams, I'd agree 10000%. I'm still traumatized by my time working in an academic setting and having to make sense of some bioinformatics packages.

If you want to make the case that some other language makes a better fit for a world where LLMs and people can work at the same time and need to deal with complex codebases, fine.

You can even make the case where language expressiveness is less desirable now that LLMs can deal with implementation details and "engineers" can go by simply with English and UML.

These would all be interesting arvuments and worthy of a conversation. But again, this has nothing to do with the original point of the discussion.

I am not going to sit back and let you fool users into an incorrect conclusion falsely insinuating the safety of a Python project when I know that it isn't safe due to the pervasive poor team discipline that hounds most teams. You're just complaining that your scam got busted.

I think Python could be okay as long as appropriate tooling is aggressively added to the project right at its start, with strict CI enforcement. At that point it residually becomes a culture issue which remains poor.

> let you fool users into an incorrect conclusion

You continue to argue over something that was not on the table. That tells me that you just have an axe to grind.

> At that point it residually becomes a culture issue which remains poor.

Ok, so we are clear that the language itself is not missing the abstractions. I guess that's all I wanted to hear. Thank you, we are done.

The culture issue is unfixable. Python attracts good engineers but it overwhelmingly also attracts bad engineers who don't give a rat's azz about code comprehension and maintainability. These engineers last long enough to get a new job elsewhere, and the ones left are holding the bag. Type-enforced languages seem to avoid this problem. I am willing to bet that type-enforced languages have a lower rate of failed projects that last less than four years.

Holy crap, you really can not take the hint!

> Type-enforced languages seem to avoid this problem.

Right, we all know how typescript projects are known for their longevity and we all know that people working in typescript are doing it because of their exceptional care about the craft and concern about maintainability. It has nothing to do with employability or the fact that startups:

- favor agility and time-to-market over long-term maintainability (i.e, they accrue a lot of technical debt)

- are more budget constrained and less likely to have enough resources to focus on cultivating good engineering discipline.

- have to compete with everyone else to attact talent in the labor pool and can not all afford to choose a tech stack that is less popular.

- will have a wild variance in the quality of the average developer.

No, sir. None of this really is really important to understand why startup teams have crappy code. It's all about the choice of statically- vs dynamically-typed languages.

I am afraid the issue isn't limited to startups at all. I have worked at bigger firms too, those managing trillions, and they have the same issue for some of same reasons, e.g. agility, low wages, etc. The poorly-typed Python project goes to shyt in the same ways at them too.

I won't speak for TypeScript since I don't have comparable experience.

So, you are all pissy and judgemental against Python claiming the issue is with its type system without looking at other widely popular languages that has stricter type checking? Really?!

I don't need to, because typing is at the core of consistent and comprehensible usage of code. Granted, code can be bad for various other reasons too, but this doesn't mean typing gets a free pass.

Typing is like the vascular system of the code, and untyped Python code is like having progressively higher blood pressure. Other problems with the code don't mean that you get to ignore the high blood pressure -- it remains a major killer of projects. Typed languages have other killers.

Now you are not only turning a blind eye to the closest language that could test your hypothesis (aside from typing system, Python and Typescript are more similar than not on all relevant characteristics, so it would be a perfect candidate to make a meaningful comparison about how the type system affects code quality, longevity and maintainability), you are resorting to vaccous platitudes that amount to "all languages have faults, but let me pick on this particular one just because I don't like one aspect of it".

You have nothing tangible to show. No success story about turning a project around by changing the stack from a dynamic to static-based project. All you have is this axe to grind, but no real solution to make things better.

On another thread you are chastising another poster for "ignoring the science". I'd suggest you take a good look in the mirror... you talked about how you worked on all these different companies, and how they all keep failing and how it could've been avoided if only they listened to you. I'm surprised you never considered that the problem might not be the language, but with yourself.

Feel free to bury your head in the sand, taking companies down with you, but don't expect to convince others to stay willfully blind. It is obvious that you're in it only for the money at the expense of everything else, and will not care if it burns the firm.

I did everything I could in my capacity to bring good practices wherever I have worked, but ultimately it's in the hands of the project lead which I wasn't. Almost always, the leads favor speed at all costs, typically lacking the experience to understand they're on a path of destruction.

I have indeed worked with statically typed languages, and they dramatically lower the surface area for what can go wrong. Your utterly dumb argument is like saying that just because everyone eventually dies, addressing high blood pressure is pointless.