You are obviously correct, but even if we let aside parent's confusion about strong/static typing, it's a weak argument.
Python does provide type annotations and extensive tooling to make static analysis, so this whole "missing abstractions to help with understanding" is simply false. You can even setup a python project to make annotations mandatory.
There are plenty of things to criticize about Python - performance, packaging and multiplatform distribution come to mind - but to think that it is missing the tools to help build and understand complex codebases is frankly absurd.
In all the years I used Python at startups and firms, there always was extremely heavy resistance to using types correctly if even using them at all. Not one of the firms would have passed at even 80%. Moreover, me encouraging its use was always met with antagonism. In summary, Python types are a disaster for code comprehension and maintainability because they're optional. So you're right that Python has the tools, but wrong overall because you shouldn't be needing tools for something that should be a default.
You are moving the goalposts. The point is that the abstractions exist. You can use them if you want and they will help you to build an understanding and managing complexity if you do.
If you inherit a complex-but-working python code base and you think that types would help you, getting an LLM to add type annotations and enforce checking is certainly less work than "rewrite it in Rust".
Plenty of teams in startups will ignore automated testing as well, it does not mean that python is lacking the tools for it, nor does it mean that a hypothetical language that mandates 100% test code coverage would be better to "build understanding" or "managing complexity".
You are ignoring what actually matters on the job in the real world wrt code maintainability. It is impossible to get an LLM to correctly add many missing types since it's not clear at all what many of the types ought to be, and because different parts of the code have vastly different expectations (due to bugs) of the types. Should the LLM then support the bug or should it fix it -- it will never know for sure since it takes the code as a precondition. The vast majority of commercial Python code out there is truly horrible considering it is lacking type definitions and enforcement.
I rarely actually care about tests if the code is written clearly and with good logging.
Python doesn't enforce discipline, so anything goes. While this personal freedom is good in a religious sense for one's own project, it's disastrous for code that requires development by a team. Some programming languages are just better than others for team development. I say this as someone who benefited from Python professionally for a decade.
There also are more unrelated severe problems with Python, e.g. no official container for no-GIL (free-threaded), thereby making real parallelism impractical.
> it's disastrous for code that requires development by a team
Honestly, my experience over (mumbles) decades has been that this argument has been trotted out hype cycle after hype cycle for different paradigms and languages, and it's never really true.
Teams can ship totally fine with just about anything. Teams can find ways to fuck up just fine with just about anything. Nothing really adds an appreciable overall positive over other alternatives in a global sense. The hard parts are always the hard parts. Most code still winds up kind of horrific but yet "good enough" for whatever business purpose is being met.
Peoples individual tastes differ and change over time, so they may feel these claims are true. But the folly is in projecting it onto others.
I think both things can be true. Obviously a competent professional in any industry (not just software) can make shoddy or inappropriate tools work well enough. Obviously an incompetent or only barely competent or competent but pressed for time professional can screw up with even the most carefully designed highest quality tools.
But I also think it's clear that tool design impacts quality, safety, and efficiency. Programming languages aren't an exception to that.
> But I also think it's clear that tool design impacts quality, safety, and efficiency
Yes, to an extent. And it's also the case that it usually doesn't matter. And that's my point.
I have also been someone like GP poster who has declared that it's physically impossible to produce valid software with XYZ tool in a team environment. And yet, there are oodles and oodles of counterexamples in the real world that proved me wrong and it worked AOK for them.
Could they all have been better off using another tool? Hypothetically yes. But their business needs (or whatever) were met and thus disproves a claim it can't be done.
Business needs can be met in the short term only so long as the original developer of the project stays in the team. As soon as they leave, when excellent type definitions and annotations are missing, the project terminates because it's simply unmaintainable. I have seen this happen countless times. In other words, the deliverable will in the short term fool many clients who don't know better, but it is ultimately a scam.
This is what I'm disagreeing with. I can hammer a nail with a rock well enough in a pinch but extrapolating from that to "it doesn't matter if we save some cash by equipping our carpenters with rocks instead of hammers" is obviously wrong.
There's a whole continuum of less extreme examples of the same principle. The quality and purpose fit of your tools absolutely does matter but in the case of programming languages it's a bunch of nontrivial tradeoffs that vary from one project to the next so it's all quite fuzzy.
> I can hammer a nail with a rock well enough in a pinch
The original post to which I responded said "it's disastrous for code that requires development by a team". Anyone claiming that using Python in a production environment is "disastrous", or equivalent to hitting a nail with a rock, is being obtuse. It has and continues to happen all the time with no notable ill effects. It's not like these teams are using Brainfuck here, Python is one of the most mainstream languages in the world, and I don't think I need a cite to make the claim that many, many teams manage just fine with it.
When I said "it usually doesn't matter", i'm talking in terms of the most important metric for a team: are the business goals being met i na timely and cost efficient manner. And my experience has been that as much as I've been a zealot in the past claiming that this tool or that tool can't possibly achieve useful results, teams that do use those tools still manage to achieve their business goals. Meanwhile I could also look around and find plenty of teams using whatever the flavor of the week "ideal" tool is and find teams that aren't meeting their goals.
Now, in an absolute objective sense, is it true that some tools are better fit for some purposes than others? Of course. Is it true that some languages lend themselves to robust coding practices than others? Of course. But the world's not a vacuum, and one must do the calculus at a higher level because as I said, the most important metric for a development team is achieving business goals. Would adopting tool A over tool B (for any A, B) improve the business? That's when these questions get a lot murkier, and the relative advantages & disadvantages tend to drop into the "noise" category.
I agree with you that it clearly works well enough in practice and I agree with you that it's murky - specifically I believe that there are substantial upsides provided by the language and its ecosystem.
> It has and continues to happen all the time with no notable ill effects.
But that statement of yours is patently false. The ill effects of duck typing and extreme flexibility in the face of massive code bases and large teams are incredibly well documented at this point. Literally the entire driving force behind typescript is directly analogous to the situation in the python world.
You might as well claim that concurrent programming in C or manual memory management have no notable ill effects. Even if there are places where you think they make more sense clearly they bring lots of fairly serious issues along for the ride.
Can it cause bugs? Yes. Do teams ship production code that meet their business goals? Also yes. The former doesn't necessarily preclude the latter. And as long as the business keeps on trucking along, complaining about the bugs and headaches is just a matter of engineering sensibilities. Which I agree with fully and grind my teeth every time.
If the business proceeds along just fine, having the perfect temple of dependently typed, category theoried, memory checked, fuzz tested software may have turned out to just be a waste of money.
If, on the other hand, the business does not proceed along just fine because the team can't get anything done due to not being able to understand that a float probably shouldn't go into a variable that's supposed to be a string, then yes, you're right.
Huh. If you're going to be blind to the science, then the team that you're in will continue to ship garbage code until finally one day they burn down the house. Feel free to bury your head in the sand, but don't drag us down with you. Preaching ignorance and apathy is what you're doing, and it doesn't relate with those who actually have standards and hold oneself accountable.
Not only your whole argument is pure conjecture, it's completely orthogonal to my original objection. People are just throwing completely silly takes as "python does not provide the abstractions to build and manage complex codebases" and this is demonstrably false. Let's just drop this line of discussion, because it's getting beyond ridiculous.
---
The funny thing is, I mostly agree with the core premise of the article: shipping today a functional proof of concept in Rust is not that more difficult than doing it from Python, and Rust has become the default choice for high performance libraries, so one might as well just go all-in Rust. But this has a lot more to do with real shortcomings of Python (performance, packaging and multi-platform distribution) than "Python does not provide the abstractions to manage complex codebases".
Your original objection is altogether irrelevant. It and Python miss the point of what matters, which is the end result in teams. And I never actually said Rust; you did. Rust is not the answer to everything. It is easy to spot a religious zealot as you are for Python -- these people are the worst for the Python community as their blindness prevents from making the hard changes necessary for keeping up with the times.
Using your logic, someone could similarly argue that C is a perfectly fine language if used with appropriate tooling which checks for errors, but it would be a similarly bogus argument.
The thread started with "Python lack abstractions to help thinking n large scale systems".
I am not saying Python typing story is perfect in reducing errors or making code safe, I am just saying that the abstractions to "help manage large scale systems" are there.
No talk about "the end result in teams". No talk about "adoption on startups". I just called out a ridiculous, demonstrably false claim and you for some reason want to completely redefine the discussion around your opinion.
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.
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.
> 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.
Python is a strongly typed language. Strong and Static typing aren't the same thing.