4 ms·

> Why it's deemed unsuitable for large, complex, multi-person projects is that enterprise types know only the byzantine OOP mess. And when all you have is OOP,

> Why it's deemed unsuitable for large, complex, multi-person projects is that enterprise types know only the byzantine OOP mess. And when all you have is OOP, everything is a FactoryFactoryFactory and everything else is "unmanageable". Have you ever worked in a large, dynamically typed codebase written by other people?

TomSwirly 3y ago
Python has had useful type-checking for a decade now.
- oskarkk 3y ago
  "Useful" is very relative. I work with python daily and I try typing everything I can, but it can be such a pain in the ass compared to TypeScript that I want to throw my computer at the wall sometimes. And I can't imagine using Python's typing even 3 years ago, as many essential features that I constantly use are very new (typed kwargs for example). Many people that like typed languages just don't bother and don't use typing in Python because of how cumbersome it is.
dbrueck 3y ago
Yes! Python has worked tremendously well in those scenarios - the things that make it good for small projects can scale up very, very well. Similarly, I've worked on very large, multi-team projects where the language was statically typed, compiled, etc. and they've been total disasters, and others that have been a huge success. I've yet to see any language that can fully negate the power of sloppy, undisciplined programmers. Those programmers are like water and always find a way.
- HarHarVeryFunny 3y ago
  > the things that make it good for small projects can scale up very, very well Sorry, but that makes zero sense. Dynamic typing is a language design choice where one is trading off automated error detection for faster development. The larger and more complex a project becomes, the more moving parts and interfaces (APIs) it has, and the more potential there is for API errors. Choosing NOT to prioritize automated (compile time) error detection is NOT something that scales up "very, very well". It's not just about size of project, but also about expected project lifetime. For a one-time use script, or experiment, or thesis project, then maybe development time is the prime concern. You're going to hack it to get it working ASAP, and don't care what happens later (there is no later). However, for a corporate project that will be in production use for years, then initial coding effort is only a small part of the lifetime project costs, and optimizing this at the expense of ease of maintenance is a poor decision. Years down the road the project will have had staff turnover, developers will have forgotten the details of all the code, the original design has probably been compromised due to feature creep, too many hands, etc, etc. At this stage you want all the help you can get so that people can still maintain the code, and the larger and more complex the project, the more so this will be. Again, the small/throwaway project language choice trade off of optimize development time at the cost of ease of bug detection will NOT scale up "very, very well". If you anticipate sloppy undisciplined programmers working on a project, then all the more reason to give them less weapons with which to shoot themselves in the foot.
  - dbrueck 3y ago
    > Sorry, but that makes zero sense. Well, I hate to break it to you, but I've been using Python in large production environments for nearly a quarter of a century now and either I'm just extraordinarily lucky, or it does in fact make quite a bit of sense and really does work quite well. :) Here's one example: we once had an enterprise Java system of roughly 1 million lines of code. For a number of reasons the whole thing got replaced by a port of it to Python, and the Python version weighed in at just over 100kLOC. Disregarding all of the other benefits (which were many), there were meaningful advantages to maintaining a codebase 1/10th the size. > Dynamic typing is a language design choice where one is trading off automated error detection for faster development. No, not at all. First of all, if you are dealing with any sort of production code, you have to be investing in good testing. The idea of dynamic languages hiding bugs that don't show up into production is mostly a bogeyman to cover inadequate testing. We've also found that languages like Python tend to encourage a style of iterative development that lends itself to each section of code being very well tested as it gets written, so in the end it's easy to wind up with code that is both tested more during the dev process but then also well-tested due to the automated tests that all software should end up having anyway. I mean, all software gets tested, it's just a question of whether you do it or your customers do it. (anecdotally we've seen evidence that people come to over-rely on compile time error checking in lieu of good iterative testing, and that's an interesting topic in and of itself, but beyond the scope of this discussion and IMO falls under the 'sloppy developer' umbrella anyway) > The larger and more complex a project becomes, the more moving parts and interfaces (APIs) it has The implicit argument here is based mainly on the assumption of lots of (even exponential) growth in coupling as a project grows, and the reality is that, the level of coupling tends to go in the opposite direction as projects grow large, unless it's simply poorly architected. For example, instead of intercommunication between modules, you're dealing with intercommunication between entire systems - the points of contact between systems tends to be over very well-defined interfaces and are small in number relative to the amount of communication internally between modules. > initial coding effort is only a small part of the lifetime project costs, and optimizing this at the expense of ease of maintenance is a poor decision Speed of initial implementation is certainly one benefit, but it actually pays dividends over the lifetime of the project. Code is read more than it is written, so having fewer lines of code, in a language that is easy to read, in a language that removes so much of the noise associated with more verbose languages, is always helpful. It helps you implement stuff to begin with, it helps you add new features later, and it helps you fix bugs. There are also lots of second-order advantages too, such as making it easier to bring new hires up to speed and needing fewer people both initially and long term. It's about a lot more than just dynamic typing though; a higher level language just provides a ton of benefits that are often worth the tradeoffs. There are so many parallels to e.g. when we moved from assembly to C. > If you anticipate sloppy undisciplined programmers working on a project That point was just that so many knocks against certain things are actually covering the problem of sloppy developers. Rather than just take them for a given, a better approach is to set them on a path to improvement if they are willing, or let them go if they are not.
Spivak 3y ago
Is every successful Rails project work as a counterexample that expressive dynamically typed languages work? Ruby has to be the worst programming language to anyone who likes rigid structure and static typing where metaprogramming and monkeypatching is first class and not a sometimes feature for library authors. But it nonetheless works well for people.

TomSwirly 3y ago

Python has had useful type-checking for a decade now.

oskarkk 3y ago
"Useful" is very relative. I work with python daily and I try typing everything I can, but it can be such a pain in the ass compared to TypeScript that I want to throw my computer at the wall sometimes. And I can't imagine using Python's typing even 3 years ago, as many essential features that I constantly use are very new (typed kwargs for example). Many people that like typed languages just don't bother and don't use typing in Python because of how cumbersome it is.

dbrueck 3y ago

Yes! Python has worked tremendously well in those scenarios - the things that make it good for small projects can scale up very, very well. Similarly, I've worked on very large, multi-team projects where the language was statically typed, compiled, etc. and they've been total disasters, and others that have been a huge success. I've yet to see any language that can fully negate the power of sloppy, undisciplined programmers. Those programmers are like water and always find a way.

HarHarVeryFunny 3y ago
> the things that make it good for small projects can scale up very, very well Sorry, but that makes zero sense. Dynamic typing is a language design choice where one is trading off automated error detection for faster development. The larger and more complex a project becomes, the more moving parts and interfaces (APIs) it has, and the more potential there is for API errors. Choosing NOT to prioritize automated (compile time) error detection is NOT something that scales up "very, very well". It's not just about size of project, but also about expected project lifetime. For a one-time use script, or experiment, or thesis project, then maybe development time is the prime concern. You're going to hack it to get it working ASAP, and don't care what happens later (there is no later). However, for a corporate project that will be in production use for years, then initial coding effort is only a small part of the lifetime project costs, and optimizing this at the expense of ease of maintenance is a poor decision. Years down the road the project will have had staff turnover, developers will have forgotten the details of all the code, the original design has probably been compromised due to feature creep, too many hands, etc, etc. At this stage you want all the help you can get so that people can still maintain the code, and the larger and more complex the project, the more so this will be. Again, the small/throwaway project language choice trade off of optimize development time at the cost of ease of bug detection will NOT scale up "very, very well". If you anticipate sloppy undisciplined programmers working on a project, then all the more reason to give them less weapons with which to shoot themselves in the foot.
- dbrueck 3y ago
  > Sorry, but that makes zero sense. Well, I hate to break it to you, but I've been using Python in large production environments for nearly a quarter of a century now and either I'm just extraordinarily lucky, or it does in fact make quite a bit of sense and really does work quite well. :) Here's one example: we once had an enterprise Java system of roughly 1 million lines of code. For a number of reasons the whole thing got replaced by a port of it to Python, and the Python version weighed in at just over 100kLOC. Disregarding all of the other benefits (which were many), there were meaningful advantages to maintaining a codebase 1/10th the size. > Dynamic typing is a language design choice where one is trading off automated error detection for faster development. No, not at all. First of all, if you are dealing with any sort of production code, you have to be investing in good testing. The idea of dynamic languages hiding bugs that don't show up into production is mostly a bogeyman to cover inadequate testing. We've also found that languages like Python tend to encourage a style of iterative development that lends itself to each section of code being very well tested as it gets written, so in the end it's easy to wind up with code that is both tested more during the dev process but then also well-tested due to the automated tests that all software should end up having anyway. I mean, all software gets tested, it's just a question of whether you do it or your customers do it. (anecdotally we've seen evidence that people come to over-rely on compile time error checking in lieu of good iterative testing, and that's an interesting topic in and of itself, but beyond the scope of this discussion and IMO falls under the 'sloppy developer' umbrella anyway) > The larger and more complex a project becomes, the more moving parts and interfaces (APIs) it has The implicit argument here is based mainly on the assumption of lots of (even exponential) growth in coupling as a project grows, and the reality is that, the level of coupling tends to go in the opposite direction as projects grow large, unless it's simply poorly architected. For example, instead of intercommunication between modules, you're dealing with intercommunication between entire systems - the points of contact between systems tends to be over very well-defined interfaces and are small in number relative to the amount of communication internally between modules. > initial coding effort is only a small part of the lifetime project costs, and optimizing this at the expense of ease of maintenance is a poor decision Speed of initial implementation is certainly one benefit, but it actually pays dividends over the lifetime of the project. Code is read more than it is written, so having fewer lines of code, in a language that is easy to read, in a language that removes so much of the noise associated with more verbose languages, is always helpful. It helps you implement stuff to begin with, it helps you add new features later, and it helps you fix bugs. There are also lots of second-order advantages too, such as making it easier to bring new hires up to speed and needing fewer people both initially and long term. It's about a lot more than just dynamic typing though; a higher level language just provides a ton of benefits that are often worth the tradeoffs. There are so many parallels to e.g. when we moved from assembly to C. > If you anticipate sloppy undisciplined programmers working on a project That point was just that so many knocks against certain things are actually covering the problem of sloppy developers. Rather than just take them for a given, a better approach is to set them on a path to improvement if they are willing, or let them go if they are not.

Spivak 3y ago

Is every successful Rails project work as a counterexample that expressive dynamically typed languages work? Ruby has to be the worst programming language to anyone who likes rigid structure and static typing where metaprogramming and monkeypatching is first class and not a sometimes feature for library authors. But it nonetheless works well for people.