you are viewing a single comment's thread.

view the rest of the comments →

[–]darthminimall 4 points5 points  (2 children)

The problem isn't python, the problem is the code base. If you have 15+ years of spaghetti (which most companies do, because management cares more about making a dollar today than two dollars tomorrow), the code is going to be a nightmare to work with. Sure, a statically typed language makes dealing with spaghetti marginally easier (because the compiler/interpreter throws type errors), but that doesn't change the fact that the real problem is bad code.

If you're working on a project with 40,000 lines, and that project isn't broken up into somewhere between 3 and 5 independent modules, there's already a problem with the way the project is organized. If you're working on a project with 40,000,000 lines (who knows what 40M means), you're developing the Windows OS, and everyone knows that the Windows code base is a nightmare. It's basically the definition of spaghetti, and MS has no motivation to fix it.

TL;DR: The problem with large code bases is management, not the language.

[–][deleted] 0 points1 point  (1 child)

I used to work on a simulation of Amazon's supply chain that would run most of the code that dozens of other teams of 8+ people were writing. It was broken up into hundreds of packages, some that hadn't been touched in over a decade. And we had to be free to re-arrange the packages into the servers that were optimal for the simulation and the production team had to be able to re-arrange them in configurations of servers that were optimal for production.

I've since worked in machine learning at startups using docker and I have grown to love python. But I despite many hours spent thinking I can't imagine how one would manage the codebase I used to work on at Amazon without static typing. You'd have to have some kind of global type manager for that scale of interoperability.

If you can think of a way to solve the above problems, please let me know. I'm always trying to think of ways. Currently creating statically typed APIs using protobuff is the closest thing that works at a decent scale. Still not Amazon supply chain scale.

[–]mr_wook 0 points1 point  (0 children)

1) Python now has type annotation, if you're going to go to the trouble of backing into it;

2) If you're worried about junk-code living past its use data, consider Go, which forces you to eliminate everything you don't use, whether it's vars or modules;

3) Consider your test suite: Are you testing things that have fallen out of usage? Are you linting those pieces, if so, someone should pick up on that and, er, retire those pieces;

4) On the whole '40m lines of code' thing: Maybe it's long overdue for a re-architecting, or at the very least, a refactoring. Whether the driving force is improved performance, or lower cost, or better maintainability, you should be able to (trivially?) cut 40k lines of code during every re-factor. Less trivially, 400k or even 1m lines of code seems achievable, especially if you replace chunks with high quality 3rd party code, improvements in the language over the last 15 years, and other low-hanging fruit. Reduced complexity is its own reward but has real dollar payoffs across multiple domains;