9 ms·

> When developing, you don't necessarily know about your types yet. This is absolutely not true for myself and my coworkers. We think in types first. Typically

> When developing, you don't necessarily know about your types yet. This is absolutely not true for myself and my coworkers. We think in types first. Typically we write out high-level functions with type signatures and make sure they all fit together and everything type-checks. Then, we'll fill in the detail and actually implement the functions. Often this process is recursive and we need to repeat it until we get small functions that are either easy to implement or available in a library. We have a type-based search tool to facilitate finding such library functions. Sometimes there are problems and alternative abstractions that only come to light when filling in the details. When a large re-organisation of code is necessary, types again help to get this right. Personally, I could never build a non-trivial piece of software in a dynamic language. Perhaps I just don't have the brain power to track the types manually in my head.

halbritt 8y ago
That's kind of the thing, though: Folks are using python to bang out trivial pieces of software all the time. Dynamic types are great for that. Occasionally, those trivial pieces of software become non-trivial, in which case, having the ability to refactor with type hints is a good thing vs. a complete rewrite in a strongly typed language.
- paganel 8y ago
  > Folks are using python to bang out trivial pieces of software all the time. Dynamic types are great for that. And I think that's ok, because (imho) 90%-to-95% of the code written right now falls under the "trivial" label.
  - willtim 8y ago
    Some large investment banks are writing millions of lines of non-trivial code in Python. Perhaps because management heard it was "strongly typed".
    - scrollaway 8y ago
      Or perhaps because they invested a lot of research and figured Python was the best tool for what they set out to do. You really should stop with the FUD in this thread, it's unconstructive and getting really annoying. We get it, you don't like Python.
      - naasking 8y ago
        Let's be real, probably 99% of projects just use a language that the main developer is already familiar with. Social and economic realities often trump technical merit, which is why inferior technology has such inertia long past the time when better replacements are available.
      - pjmlp 8y ago
        Banks also do lots of critical business decisions in Excel, sanity is not always their strongest point.
      - willtim 8y ago
        It's not FUD if someone posts an opposing viewpoint. My point was that some of the terminology used in this community is rather disingenuous. Python has a lot of strengths, but let's also be honest about its weaknesses.
        acdha 8y ago
        So far you haven’t had a good track record of making statements which are factually correct and detailed enough to discuss. If you want to contribute anything of value to the conversation try making a longer comment which explains in detail precisely what you believe is a problem and why it matters so much that you’re willing to accuse a popular open source community of making false claims. So far I’ve seen one concrete example from you (the SQL/file path one) which is either the same in every other language (if you store them as generic strings) or prevented by Python’s type system (if you use non-generic types).
        8y ago
- singingfish 8y ago
  s/Occasionally/Frequently/ I made a temporary kludge around 10 months ago whose time to live was supposed to be a few weeks. Guess what happened to that? I am definitely looking forward to retiring it mind you.
crdoconnor 8y ago
I develop making heavy use of behavioral tests, REPL and sanity checks. I don't worry too much about tracking types in my head because with a test and REPL I can quickly and trivially spin up and inspect to the minutest level of detail almost any line of code in a runtime state, use autocomplete, etc. and write reliable snippets of code with a near instantaneous feedback loop - getting instant feedback not just on an object's type and its properties, but on what it actually does when it is run. Usually when developers used to a statically typed language switch to a dynamically typed language changing their style of development does not occur to them simply because the economics are so different to what they are used to - they rely heavily on IDEs with autocomplete, etc. (which, in statically typed language provides instantaneous feedback) and are used to long compile/test feedback loop and REPLs that are poor to non-existent. In practice this means a lot of them don't think to go looking for potentially better forms of instantaneous feedback that are more readily available in dynamically typed languages but will kvetch because the one they are used to is suddenly unavailable... ;)
- Karrot_Kream 8y ago
  Static types mean that you never have to write behavioral tests. If you're writing behavior tests, you're just writing a very verbose subset of the same guarantees that types offer instantly. Moreover, running code snippets in a repl only help if your codebase is small and you're designing it mostly alone. 3 months later, when someone needs to add a new feature and they call your function with incorrect assumptions (sending a dictionary with missing keys for example) then you'll have something that can work in the happy path, but doesn't work around the edge cases. I've seen behavioral tests try to address this, but again, that's just an inferior form of typing.
  - deleted 8y ago
    [deleted]
- tigershark 8y ago
  REPL are not confined to dynamic typed languages. Using a better programming language you won’t have any need for a lot of your tests.
hindsightRegret 8y ago
Agreed 100%. For quick one-off scripts and coding interviews, I have no qualms with using python. But maintaining api input/output guarantees in a large piece of software w/o explicit typing sounds like a huge pain to me.
- scarface74 8y ago
  I spent the first 12 years of my career doing 80% C and C++ and a little Perl on the side and the last 10 years doing C# with a little PHP. Of course I've had to do some JavaScript. My experience with dynamic languages completely turned me off of them. But recently, I was forced to learn Python. I have to admit that Python is joy to use for small scripts and event driven AWS Lambda functions, but I would still use C# for any large projects. I can't put my finger on why Python+Visual Studio Code is such a joy to use compared to my previous experience with dynamic languages.

halbritt 8y ago

That's kind of the thing, though: Folks are using python to bang out trivial pieces of software all the time. Dynamic types are great for that. Occasionally, those trivial pieces of software become non-trivial, in which case, having the ability to refactor with type hints is a good thing vs. a complete rewrite in a strongly typed language.

paganel 8y ago
> Folks are using python to bang out trivial pieces of software all the time. Dynamic types are great for that. And I think that's ok, because (imho) 90%-to-95% of the code written right now falls under the "trivial" label.
- willtim 8y ago
  Some large investment banks are writing millions of lines of non-trivial code in Python. Perhaps because management heard it was "strongly typed".
  - scrollaway 8y ago
    Or perhaps because they invested a lot of research and figured Python was the best tool for what they set out to do. You really should stop with the FUD in this thread, it's unconstructive and getting really annoying. We get it, you don't like Python.
    - naasking 8y ago
      Let's be real, probably 99% of projects just use a language that the main developer is already familiar with. Social and economic realities often trump technical merit, which is why inferior technology has such inertia long past the time when better replacements are available.
    - pjmlp 8y ago
      Banks also do lots of critical business decisions in Excel, sanity is not always their strongest point.
    - willtim 8y ago
      It's not FUD if someone posts an opposing viewpoint. My point was that some of the terminology used in this community is rather disingenuous. Python has a lot of strengths, but let's also be honest about its weaknesses.
      - acdha 8y ago
        So far you haven’t had a good track record of making statements which are factually correct and detailed enough to discuss. If you want to contribute anything of value to the conversation try making a longer comment which explains in detail precisely what you believe is a problem and why it matters so much that you’re willing to accuse a popular open source community of making false claims. So far I’ve seen one concrete example from you (the SQL/file path one) which is either the same in every other language (if you store them as generic strings) or prevented by Python’s type system (if you use non-generic types).
        8y ago
singingfish 8y ago
s/Occasionally/Frequently/ I made a temporary kludge around 10 months ago whose time to live was supposed to be a few weeks. Guess what happened to that? I am definitely looking forward to retiring it mind you.

crdoconnor 8y ago

I develop making heavy use of behavioral tests, REPL and sanity checks. I don't worry too much about tracking types in my head because with a test and REPL I can quickly and trivially spin up and inspect to the minutest level of detail almost any line of code in a runtime state, use autocomplete, etc. and write reliable snippets of code with a near instantaneous feedback loop - getting instant feedback not just on an object's type and its properties, but on what it actually does when it is run. Usually when developers used to a statically typed language switch to a dynamically typed language changing their style of development does not occur to them simply because the economics are so different to what they are used to - they rely heavily on IDEs with autocomplete, etc. (which, in statically typed language provides instantaneous feedback) and are used to long compile/test feedback loop and REPLs that are poor to non-existent. In practice this means a lot of them don't think to go looking for potentially better forms of instantaneous feedback that are more readily available in dynamically typed languages but will kvetch because the one they are used to is suddenly unavailable... ;)

Karrot_Kream 8y ago
Static types mean that you never have to write behavioral tests. If you're writing behavior tests, you're just writing a very verbose subset of the same guarantees that types offer instantly. Moreover, running code snippets in a repl only help if your codebase is small and you're designing it mostly alone. 3 months later, when someone needs to add a new feature and they call your function with incorrect assumptions (sending a dictionary with missing keys for example) then you'll have something that can work in the happy path, but doesn't work around the edge cases. I've seen behavioral tests try to address this, but again, that's just an inferior form of typing.
- deleted 8y ago
  [deleted]
tigershark 8y ago
REPL are not confined to dynamic typed languages. Using a better programming language you won’t have any need for a lot of your tests.

hindsightRegret 8y ago

Agreed 100%. For quick one-off scripts and coding interviews, I have no qualms with using python. But maintaining api input/output guarantees in a large piece of software w/o explicit typing sounds like a huge pain to me.

scarface74 8y ago
I spent the first 12 years of my career doing 80% C and C++ and a little Perl on the side and the last 10 years doing C# with a little PHP. Of course I've had to do some JavaScript. My experience with dynamic languages completely turned me off of them. But recently, I was forced to learn Python. I have to admit that Python is joy to use for small scripts and event driven AWS Lambda functions, but I would still use C# for any large projects. I can't put my finger on why Python+Visual Studio Code is such a joy to use compared to my previous experience with dynamic languages.