6 ms·

That's often a good direction. When developing, you don't necessarily know about your types yet. And you might not even want to think about them. It's easier t

• grumpyprole 8y ago
  > 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.
  • 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.
• lkrubner 8y ago
  "It's not until later when the code has partially stabilised that you can start spotting what data structures are robust enough to be close to final" That's the argument I made in "How ignorant am I, and how do I formally specify that in my code?" http://www.smashcompany.com/technology/how-ignorant-am-i-and-how-do-i-specify-that http://www.smashcompany.com/technology/how-ignorant-am-i-and... "2.) the other group of programmers start off saying “There is a great deal that I do not know about this particular problem, and I am unwilling to commit myself to absolute statements of truth, while I’m still groping in the dark.” They proceed with small experiments, they see where they fail, they learn about the problem, they discover the solutions, and they add in type information incrementally, as they feel more confident that they understand the problem and possess a workable solution. These are the dynamic type advocates."
  • quikoa 8y ago
    That's odd, I consider myself to be firmly in group 2. I'm often fine with stating things I don't know. Yet I'm a big advocate of static type systems. Starting with types allows you to play around with data models of the problem space quickly before committing a lot of code to provide a solution. At least that's my take on this.
  • dahauns 8y ago
    But I would assert that it is misleading to pretend that you understand the system at the beginning. I want to be honest about how ignorant I am when I begin to work on a problem that I have never encountered before. But are you honest with yourself? When working "in the unknown", the basis of your code is nevertheless a set of assumptions. You might not spell them out, but they are there. Static types do not equate pretense of understanding - they are those assumptions made explicit, and more importantly, universal (and not existential like tests). They help reasoning about code (esp with larger codebases/teams) and it is easier to adapt and extend (well, refactor) them in a safe way as the code and with it your knowledge about the problem develops.
    • lkrubner 8y ago
      To take a blob of JSON and ram into MongoDB doesn't reveal much bias. If we later decided "This JSON needs to have, at a minimum, 4 keys, including user_id, import_id, source, and version" then that is the first layer of runtime checks we can add, or type hints, or Schema with Clojure. And that becomes version 1. If we later say "We also need to add created_at and processed_bool" then that becomes version 2. The lack of the 4 keys in version 0 reveals my ignorance, just as the lack of the extra 2 keys reveals my ignorance in version 1. There will always be ignorance, there will always be things I don't know, the important thing is to make that as explicit as possible. Adding explicit types in version 0 suggests that I have a confidence that I do not have, and in fact, I eagerly wish to communicate the opposite of confidence in that early code.
• sanxiyn 8y ago
  Haskell has defer-type-errors option so that you can defer type decision while developing.
• Tehnix 8y ago
  To contrast this, types help a LOT for me when developing something. The last thing you know are the implementation details of what you're doing, so I usually start by sketching what I want to do put, with some simple ADTs (algebraic data types, e.g. union/sum types and product types just to give something tangible). Then create a couple of functions I think make sense, give them an undefined for now in their function body, and align the types up from the inputs and outputs. Now, here's where you usually hear people praise dynamically typed languages—I want to change the design, because I still prototyping. How do I do this? Just change the types (ADTs)! After changing my design, the compiler will now let me know where my functions don't make sense anymore. Contrast this with when I usually dev in a dynamical language, I end up running my program again at this step, finding out that one function over here didn't like that I'm now passing a string down instead of an Intel, another function was expecting a boolean, but now I'm returning the result instead, etc. The saying that static languages are not great for prototyping needs to die. They are magnificent, you just need to have a conversation with the compiler instead of fighting it. Of course, this all assumes a language with a sophisticated enough type system, e.g. Haskell, OCaml, Idris, PureScript, Elm (somewhat), Rust (depending on your do domain), etc.