5 ms·

from tfa: "One reasonable take might be that we’re stretching Python beyond what it was intended for. It works great for smaller teams on smaller codebases tha

by cat199 6y ago

from tfa: "One reasonable take might be that we’re stretching Python beyond what it was intended for. It works great for smaller teams on smaller codebases that can maintain good discipline around how to use it, and we should switch to a less dynamic language. But we’re past the point of codebase size where a rewrite is even feasible. " YMMV.

Guthur 6y ago
I've been doing this for long enough to know that if you think static typing will save us from the complexity of large organically grown code bases you'll be sorely mistaken. The code and system design will reflect you culture per Conway's. If you value fast delivery it'll be full of dirty hacks throughout, piling one on top of each other. If you have single tight nit team it'll ram a million and one concerns into the same system, and so on. Languages will not save us from ourselves, ever.
- sateesh 6y ago
  I agree static typing is no silver bullet.But when there is a choice between looking at python code written some time ago and wondering (and at times speculating) what type the function args are v/s inferring from function args (say in Go) is a smoother experience, especially when debugging a thorny heisenbug causing an outage.
  - Guthur 6y ago
    Don't worry golang will have it's day of horror story code bases where developers made all sorts of wacky decisions around pointer passing and badly specified interfaces within a code bases 100kloc too large.
  - redis_mlc 6y ago
    FYI: Perl5 has always had moderately strong static typing and runtime warnings, as well as forward references. I always wince when people try to tell me that python is "better" or "more modern." To enable in Perl: use strict; use diagnostics;
- mhh__ 6y ago
  I think this is true however there is a tendency to think that not using Python can only mean using C++, Something on the JVM, etc. C++ is an awful language, you can do better (albeit it's potentially not for the faint of heart) Static Typing is important, but the thing with Python is really the lack of a compiler - compilers (ignoring efficiency) catch bugs now rather than half way through a job (Obviously Linters do exist but a sufficiently advanced Linter is not only repeating work a compiler would've done, but also probably requires some kind of help e.g. annotation) An example of something that demonstrates Static Typing working and not working at the same time: Compare the code of GCC and LLVM, they're both in C++ (now) but one is hugely better structured and easier to read - GCC grew organically which is part of the problem, but LLVM was specifically designed around a certain architecture (And still grew quickly). To paraphrase Batman, "It's not what type-system I use underneath, but what I do that defines me" definitely applies but drawing equivalence between all code regardless of language isn't right either - the language you use affects the way you code and how you structure your programs.
  - dragonwriter 6y ago
    > Static Typing is important, but the thing with Python is really the lack of a compiler - compilers (ignoring efficiency) catch bugs now rather than half way through a job Nope, that's static type checkers (which are often part of compilers), not compilers as a separate thing from static type checking. In fact, Python has a compiler run in the course of normal execution. And Python also has static type checkers available (and good editor integrations for them), they are just separate from the compiler. > Obviously Linters do exist but a sufficiently advanced Linter is not only repeating work a compiler would've done, but also probably requires some kind of help e.g. annotation) Yes, static type checkers whether incorporated in a compiler or separately tend to need type annotations to do their best work, especially if the type system isn't specifically crafted to maximize inferrability (Haskell can get away with fewer annotations than Java, often.)
- oblio 6y ago
  Giving up and not using superior tools won't help us, either.
- lmm 6y ago
  That's like saying a workout plan can't keep you in shape because you need discipline to stay in shape. Static typing is the only way I've found to save you from yourself; it's how you can set guardrails that make it easier to do the right thing than the wrong thing. If not static typing then what?
- pjmlp 6y ago
  I learned during the first .com wave while using our own in-house version of ActiveAOL inspired server, and friends doing Zope projects, not to take shortcuts with dynamic languages at scale. Static typing does solve some issues, provides tooling opportunities, and easier ways to generate native code when that performance gets called into action and like here the application is behind any hope of getting rewritten. In fact, pretty much so, that all dynamic languages that got widespread adoption are now trying to fit some kind of static typing support into their infrastructure.
- luord 6y ago
  Indeed. In fact, a strong contender for the absolute worst codebase I've worked on was in Go. No type system is going to save you if you if you don't follow pretty much any good practice. Conversely, well modeled systems can be coded in any language, as long as good practices and good communication are continuously enforced. There are even studies on this and, so far, there's no strong correlation between type system (or paradigm, for that matter) and number of bugs in a codebase. In fact, one recent study on the matter ended up turning into a flamewar between two different groups of scientists, the ones who first published the study and the ones trying to replicate and double check the data... As discussions on type systems and paradigms are won't to do. Evidently not even academia is safe. I wish there actually were empirical evidence to support one's preference in that area, if only to get rid of those flamewars that have been going on for decades. Alas, until that happens, what language one prefers mostly remains opinion or personal experience.
  - strokirk 6y ago
    Can you send a link to the study? Sounds interesting!
    - luord 6y ago
      My favorite summary of the whole thing is here: https://www.hillelwayne.com/post/this-is-how-science-happens/ https://www.hillelwayne.com/post/this-is-how-science-happens... It was shared here a while ago (https://news.ycombinator.com/item?id=22531453 https://news.ycombinator.com/item?id=22531453), if you also want to read the HN discussion about it.
  - lmm 6y ago
    > In fact, a strong contender for the absolute worst codebase I've worked on was in Go. So the most notoriously limited typesystem of the century, the one that ignored decades of progress, lead to a bad codebase? And you see this as an argument against type systems?
    - luord 6y ago
      I don't think I was making any arguments. Furthermore, if there's a takeaway from my comment, is that I don't think there are arguments to be said in that particular discussion, only opinions supported by one's specific experience. There's certainly a dearth of solid empirical evidence one way or the other. I was also agreeing with GP's saying that "static typing won't save us". There are many things to say about Go's type system, but it is definitely more static than Python's, which I've also worked with.

by cat199 6y ago

Guthur 6y ago

I've been doing this for long enough to know that if you think static typing will save us from the complexity of large organically grown code bases you'll be sorely mistaken. The code and system design will reflect you culture per Conway's. If you value fast delivery it'll be full of dirty hacks throughout, piling one on top of each other. If you have single tight nit team it'll ram a million and one concerns into the same system, and so on. Languages will not save us from ourselves, ever.

sateesh 6y ago
I agree static typing is no silver bullet.But when there is a choice between looking at python code written some time ago and wondering (and at times speculating) what type the function args are v/s inferring from function args (say in Go) is a smoother experience, especially when debugging a thorny heisenbug causing an outage.
- Guthur 6y ago
  Don't worry golang will have it's day of horror story code bases where developers made all sorts of wacky decisions around pointer passing and badly specified interfaces within a code bases 100kloc too large.
- redis_mlc 6y ago
  FYI: Perl5 has always had moderately strong static typing and runtime warnings, as well as forward references. I always wince when people try to tell me that python is "better" or "more modern." To enable in Perl: use strict; use diagnostics;
mhh__ 6y ago
I think this is true however there is a tendency to think that not using Python can only mean using C++, Something on the JVM, etc. C++ is an awful language, you can do better (albeit it's potentially not for the faint of heart) Static Typing is important, but the thing with Python is really the lack of a compiler - compilers (ignoring efficiency) catch bugs now rather than half way through a job (Obviously Linters do exist but a sufficiently advanced Linter is not only repeating work a compiler would've done, but also probably requires some kind of help e.g. annotation) An example of something that demonstrates Static Typing working and not working at the same time: Compare the code of GCC and LLVM, they're both in C++ (now) but one is hugely better structured and easier to read - GCC grew organically which is part of the problem, but LLVM was specifically designed around a certain architecture (And still grew quickly). To paraphrase Batman, "It's not what type-system I use underneath, but what I do that defines me" definitely applies but drawing equivalence between all code regardless of language isn't right either - the language you use affects the way you code and how you structure your programs.
- dragonwriter 6y ago
  > Static Typing is important, but the thing with Python is really the lack of a compiler - compilers (ignoring efficiency) catch bugs now rather than half way through a job Nope, that's static type checkers (which are often part of compilers), not compilers as a separate thing from static type checking. In fact, Python has a compiler run in the course of normal execution. And Python also has static type checkers available (and good editor integrations for them), they are just separate from the compiler. > Obviously Linters do exist but a sufficiently advanced Linter is not only repeating work a compiler would've done, but also probably requires some kind of help e.g. annotation) Yes, static type checkers whether incorporated in a compiler or separately tend to need type annotations to do their best work, especially if the type system isn't specifically crafted to maximize inferrability (Haskell can get away with fewer annotations than Java, often.)
oblio 6y ago
Giving up and not using superior tools won't help us, either.
lmm 6y ago
That's like saying a workout plan can't keep you in shape because you need discipline to stay in shape. Static typing is the only way I've found to save you from yourself; it's how you can set guardrails that make it easier to do the right thing than the wrong thing. If not static typing then what?
pjmlp 6y ago
I learned during the first .com wave while using our own in-house version of ActiveAOL inspired server, and friends doing Zope projects, not to take shortcuts with dynamic languages at scale. Static typing does solve some issues, provides tooling opportunities, and easier ways to generate native code when that performance gets called into action and like here the application is behind any hope of getting rewritten. In fact, pretty much so, that all dynamic languages that got widespread adoption are now trying to fit some kind of static typing support into their infrastructure.
luord 6y ago
Indeed. In fact, a strong contender for the absolute worst codebase I've worked on was in Go. No type system is going to save you if you if you don't follow pretty much any good practice. Conversely, well modeled systems can be coded in any language, as long as good practices and good communication are continuously enforced. There are even studies on this and, so far, there's no strong correlation between type system (or paradigm, for that matter) and number of bugs in a codebase. In fact, one recent study on the matter ended up turning into a flamewar between two different groups of scientists, the ones who first published the study and the ones trying to replicate and double check the data... As discussions on type systems and paradigms are won't to do. Evidently not even academia is safe. I wish there actually were empirical evidence to support one's preference in that area, if only to get rid of those flamewars that have been going on for decades. Alas, until that happens, what language one prefers mostly remains opinion or personal experience.
- strokirk 6y ago
  Can you send a link to the study? Sounds interesting!
  - luord 6y ago
    My favorite summary of the whole thing is here: https://www.hillelwayne.com/post/this-is-how-science-happens/ https://www.hillelwayne.com/post/this-is-how-science-happens... It was shared here a while ago (https://news.ycombinator.com/item?id=22531453 https://news.ycombinator.com/item?id=22531453), if you also want to read the HN discussion about it.
- lmm 6y ago
  > In fact, a strong contender for the absolute worst codebase I've worked on was in Go. So the most notoriously limited typesystem of the century, the one that ignored decades of progress, lead to a bad codebase? And you see this as an argument against type systems?
  - luord 6y ago
    I don't think I was making any arguments. Furthermore, if there's a takeaway from my comment, is that I don't think there are arguments to be said in that particular discussion, only opinions supported by one's specific experience. There's certainly a dearth of solid empirical evidence one way or the other. I was also agreeing with GP's saying that "static typing won't save us". There are many things to say about Go's type system, but it is definitely more static than Python's, which I've also worked with.