5 ms·

A static type system requires the programmer to think about the types. It distracts and takes up mental space, especially when one is returning to old code and

by belorn 5y ago

A static type system requires the programmer to think about the types. It distracts and takes up mental space, especially when one is returning to old code and "just" want to quickly add a small feature that sound simple in concept but first require that one parse the thought process behind the old code.

gefhfff 5y ago
And with dynamic ts the programmer is not required to think about it? You don't think anymore if you return a number or a string or a map? I doubt it. Static TS require you to think correct (and occasionally write it down - depends on the language) before you run the code.
- belorn 5y ago
  Here is a real life example. I have a library that communicate with an API that extract information, and now I want it to also grab an additional field and extract it to a database. The goal is to figure out which functions in the code accesses the field, where the best spot is to extract the information, and what the best way to call into the database without adding too much code in places where it shouldn't be. In addition I need to keep the information synced over time. Do I care what the different functions in the library return? No. The field could exist in everything from an XML object, a dict, a string, a byte array, or a custom object made for easy interaction. What I need to know is where in the flow I can best inject my new code, and in order to do so I need to know when and where the information can be accessed. In an optimal world I would have written a shell script, and in that case every function has a single return type which is string.
  - scrollaway 5y ago
    If you do not care about the type, and indeed do not do anything special with it other than pass it through to somewhere (that may or may not care about it), then there are types that let you do that. A good typed language will allow you to be more or less strict about what you accept (eg. a specific literal string, a set of strings, any string, any string like object, any object...)
    - belorn 5y ago
      If there are types that allow you to not care about the type, then why have a type? People argue that they need types to very that you do not add in programming errors, and in order to easier read what the code does. In the environment I operate in and the jobs I do, types do not achieve those things. All they do is add unnecessary information and restrictions that need to be worked around. Shell is an interesting environment in that there really is only one type: string. There are no int, no floats, barely any arrays (rare enough that I don't ever use them). You run a program with string inputs and you may get an string output in return. The majority time writing a shell script is spent on manuals, understanding how different programs interact, and data flows. This remain mostly true for dynamic languages. For static typed languages some of the time get redirected on dealing with types, declaring types ahead, and making sure the type declarations and castings are correct.
      - scrollaway 5y ago
        You're making an entire argument about something you clearly haven't properly tried. It sounds like you have your own misconceptions about what static typing is and how types work. Your premise is flawed so it's difficult to have a conversation. I would encourage you to try typescript for a while, it's very approachable and has excellent tooling.
        belorn 5y ago
        One can measure the quality of a discussion in how often people refer to the arguments, and how often they refer to the person. You're making... you have your own misconceptions... Your premise is flawed... encourage you to try... I have worked with 10+ different languages, multiple different IDE's, some types and some dynamic, some like shell which doesn't really have the concept of types at all. If you are encouraging me to try typescript because you think its great, then I would encourage you in return to test python in combination with system and integration tests. It makes for a very safe environment where you know your code is working.
        5y ago
  - gefhfff 5y ago
    I can't answer your question. You may care since you may not want to break other code within the library that depends on what is returned by the function (depends how it looks like). Otherwise I don't know why you would particularly care more about types with st than otherwise You'd just follow the same pattern as you did when extracting the other fields. E.g. if the fields to extract are listed in a list like structure, you're just going to add the extra field to the list. And in case of static typing, you'll get soonish feedback if you messed something up. The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming.
    - belorn 5y ago
      > The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming. If we both agree that you do not need to care about types during every act of programming, then lets follow that thread and see where it leads. When do you need to care about types, and how big portion of a programmers time is spent on thinking about types? My own expensive provides the answer "rarely" and "as little as possible". The few times I do care about types is when interacting with third-party functions, and in those cases I read the manual to figure out what their functions are returning and what I can expect to use. I do not however write test that verify that a function that is documented to return a string actually do return a string (or expect my compiler to do it for me). If the documentation is incorrect then I treat that as a bug, just as if it was a logic bug. It would however be interesting to hear how much others spend time on it, and in what kind of acts of programming.
      - joelbluminator 5y ago
        This. I was wondering if it's because I'm a web dev that I rarely care/think/debug typing issues or what. I hear the stories I'm just not sure what everyone is talking about. I did have that in js a bit (the good old == vs ===) but not with Ruby.
      - gefhfff 5y ago
dragonwriter 5y ago
> A static type system requires the programmer to think about the types. Dynamic code requires the programmer to think about the same things; what static typing requires is communicating that thought to the type-checker through a constrained language (in the best cases, with robust type inference, this can be no additional cost for substantial fractions of a code base, though). On the other hand, it also provides fairly immediate feedback on the correctness of the information so communicated, and cam leverage it in dev tooling, so there is a benefit with the cost.
scrollaway 5y ago
Like others have said, dynamically typed languages still require you to think about the types, except that now you don't have the automatic hints the IDE can provide you, the guarantee of safety once your code compiles etc. Typed codebases are far better to return to than untyped ones. Anyone who doesn't think so has probably not tried a good, typed language with a good IDE.
- belorn 5y ago
  It is interesting that so many people believe, and strongly enough to downvote, that you must think about types when programming. A claim that people can't program unless they are thinking about types. I have provided examples in other comments where types is about as far away from my mind when writing complex programs. In terms of guarantee of safety, system and integration tests do that. Types are not based on customer requirements, nor do they verify that the program do what I get paid to do. A type is simply a limited set of automatic restrictions and tests to very that those restrictions are followed.
  - jerf 5y ago
    Because the claim "you're not thinking about types" is absurd. You can't pass a LoggedInUser to a thing expecting a URL. You can't pass a AccountIterator to a thing expecting a UUID. You can't pass a function closure to a thing expecting a string. And so on. You have to be thinking about types, because the computer can't. Since your programs work (I assume), and computers can't be doing this for you, by process of elimination, you're the one thinking about types. What is actually happening is either that you've so deeply internalized it you don't realize it any more than you think about individual muscle contractions while walking, or you don't recognize what "thinking about types" means. For instance, I imagine an obvious riposte to my first paragraph would be "But if the code expects a URL and I pass it an LoggedInUser, I can set it up so the LoggedInUser can yield or function as a URL", which is in fact precisely "thinking about types" because you just changed the type of your LoggedInUser. (You want to see someone who is truly "not thinking about types", go help someone learn programming for the first time, who truly innocently tries to pass a User to something expecting a URL and is truly surprised when that doesn't work because they truly, deeply thought the program would just figure out how to turn that into some URL they had in their head for the user, but never explained to the code. That's "not thinking about types". It is nonfunctional.) As others have said, dynamic code requires you to do more thinking about types, not less, for two reasons: One, the compiler isn't doing it for you, and two, you have a lot more things to juggle in a dynamic language than in most static ones precisely because they give you more power. You shouldn't be fighting this idea, you should be embracing it; it is precisely the fact that they make you think more about types and leave more of the decisions to you that gives you the additional power in dynamic types you are enjoying. But that additional power irreducibly comes with more responsibility. You can't claim you've obtained the power yet somehow dodged the responsibility of managing it. You are holding a lot more state in your head that has no existence in your source code than you would be in an equivalent static program. You can't claim you've got that state in your head but you're somehow not "thinking" about it. You're thinking about types all the time. Your complaint is more than you like a programming style that involves very complicated type ideas that are difficult to express in a static language. (Or, possibly, that you haven't taken the time to learn to express in a static language. There are some static languages that work better with this style than others.) Or that you don't want the constraint of having to express them. So you stick to an environment that loads the work on to you instead in return for the power of those more complicated things you never have to lay out for the compiler. But the work is getting done somewhere. It has to be, or your program wouldn't work.
doomvox 5y ago
Douglas Crockford, "Javascript: The Good Parts" (2008): "But it turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are not the errors I worry about."

by belorn 5y ago

gefhfff 5y ago

And with dynamic ts the programmer is not required to think about it? You don't think anymore if you return a number or a string or a map? I doubt it. Static TS require you to think correct (and occasionally write it down - depends on the language) before you run the code.

belorn 5y ago
Here is a real life example. I have a library that communicate with an API that extract information, and now I want it to also grab an additional field and extract it to a database. The goal is to figure out which functions in the code accesses the field, where the best spot is to extract the information, and what the best way to call into the database without adding too much code in places where it shouldn't be. In addition I need to keep the information synced over time. Do I care what the different functions in the library return? No. The field could exist in everything from an XML object, a dict, a string, a byte array, or a custom object made for easy interaction. What I need to know is where in the flow I can best inject my new code, and in order to do so I need to know when and where the information can be accessed. In an optimal world I would have written a shell script, and in that case every function has a single return type which is string.
- scrollaway 5y ago
  If you do not care about the type, and indeed do not do anything special with it other than pass it through to somewhere (that may or may not care about it), then there are types that let you do that. A good typed language will allow you to be more or less strict about what you accept (eg. a specific literal string, a set of strings, any string, any string like object, any object...)
  - belorn 5y ago
    If there are types that allow you to not care about the type, then why have a type? People argue that they need types to very that you do not add in programming errors, and in order to easier read what the code does. In the environment I operate in and the jobs I do, types do not achieve those things. All they do is add unnecessary information and restrictions that need to be worked around. Shell is an interesting environment in that there really is only one type: string. There are no int, no floats, barely any arrays (rare enough that I don't ever use them). You run a program with string inputs and you may get an string output in return. The majority time writing a shell script is spent on manuals, understanding how different programs interact, and data flows. This remain mostly true for dynamic languages. For static typed languages some of the time get redirected on dealing with types, declaring types ahead, and making sure the type declarations and castings are correct.
    - scrollaway 5y ago
      You're making an entire argument about something you clearly haven't properly tried. It sounds like you have your own misconceptions about what static typing is and how types work. Your premise is flawed so it's difficult to have a conversation. I would encourage you to try typescript for a while, it's very approachable and has excellent tooling.
      - belorn 5y ago
        One can measure the quality of a discussion in how often people refer to the arguments, and how often they refer to the person. You're making... you have your own misconceptions... Your premise is flawed... encourage you to try... I have worked with 10+ different languages, multiple different IDE's, some types and some dynamic, some like shell which doesn't really have the concept of types at all. If you are encouraging me to try typescript because you think its great, then I would encourage you in return to test python in combination with system and integration tests. It makes for a very safe environment where you know your code is working.
        5y ago
- gefhfff 5y ago
  I can't answer your question. You may care since you may not want to break other code within the library that depends on what is returned by the function (depends how it looks like). Otherwise I don't know why you would particularly care more about types with st than otherwise You'd just follow the same pattern as you did when extracting the other fields. E.g. if the fields to extract are listed in a list like structure, you're just going to add the extra field to the list. And in case of static typing, you'll get soonish feedback if you messed something up. The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming.
  - belorn 5y ago
    > The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming. If we both agree that you do not need to care about types during every act of programming, then lets follow that thread and see where it leads. When do you need to care about types, and how big portion of a programmers time is spent on thinking about types? My own expensive provides the answer "rarely" and "as little as possible". The few times I do care about types is when interacting with third-party functions, and in those cases I read the manual to figure out what their functions are returning and what I can expect to use. I do not however write test that verify that a function that is documented to return a string actually do return a string (or expect my compiler to do it for me). If the documentation is incorrect then I treat that as a bug, just as if it was a logic bug. It would however be interesting to hear how much others spend time on it, and in what kind of acts of programming.
    - joelbluminator 5y ago
      This. I was wondering if it's because I'm a web dev that I rarely care/think/debug typing issues or what. I hear the stories I'm just not sure what everyone is talking about. I did have that in js a bit (the good old == vs ===) but not with Ruby.
    - gefhfff 5y ago

dragonwriter 5y ago

> A static type system requires the programmer to think about the types. Dynamic code requires the programmer to think about the same things; what static typing requires is communicating that thought to the type-checker through a constrained language (in the best cases, with robust type inference, this can be no additional cost for substantial fractions of a code base, though). On the other hand, it also provides fairly immediate feedback on the correctness of the information so communicated, and cam leverage it in dev tooling, so there is a benefit with the cost.

scrollaway 5y ago

Like others have said, dynamically typed languages still require you to think about the types, except that now you don't have the automatic hints the IDE can provide you, the guarantee of safety once your code compiles etc. Typed codebases are far better to return to than untyped ones. Anyone who doesn't think so has probably not tried a good, typed language with a good IDE.

belorn 5y ago
It is interesting that so many people believe, and strongly enough to downvote, that you must think about types when programming. A claim that people can't program unless they are thinking about types. I have provided examples in other comments where types is about as far away from my mind when writing complex programs. In terms of guarantee of safety, system and integration tests do that. Types are not based on customer requirements, nor do they verify that the program do what I get paid to do. A type is simply a limited set of automatic restrictions and tests to very that those restrictions are followed.
- jerf 5y ago
  Because the claim "you're not thinking about types" is absurd. You can't pass a LoggedInUser to a thing expecting a URL. You can't pass a AccountIterator to a thing expecting a UUID. You can't pass a function closure to a thing expecting a string. And so on. You have to be thinking about types, because the computer can't. Since your programs work (I assume), and computers can't be doing this for you, by process of elimination, you're the one thinking about types. What is actually happening is either that you've so deeply internalized it you don't realize it any more than you think about individual muscle contractions while walking, or you don't recognize what "thinking about types" means. For instance, I imagine an obvious riposte to my first paragraph would be "But if the code expects a URL and I pass it an LoggedInUser, I can set it up so the LoggedInUser can yield or function as a URL", which is in fact precisely "thinking about types" because you just changed the type of your LoggedInUser. (You want to see someone who is truly "not thinking about types", go help someone learn programming for the first time, who truly innocently tries to pass a User to something expecting a URL and is truly surprised when that doesn't work because they truly, deeply thought the program would just figure out how to turn that into some URL they had in their head for the user, but never explained to the code. That's "not thinking about types". It is nonfunctional.) As others have said, dynamic code requires you to do more thinking about types, not less, for two reasons: One, the compiler isn't doing it for you, and two, you have a lot more things to juggle in a dynamic language than in most static ones precisely because they give you more power. You shouldn't be fighting this idea, you should be embracing it; it is precisely the fact that they make you think more about types and leave more of the decisions to you that gives you the additional power in dynamic types you are enjoying. But that additional power irreducibly comes with more responsibility. You can't claim you've obtained the power yet somehow dodged the responsibility of managing it. You are holding a lot more state in your head that has no existence in your source code than you would be in an equivalent static program. You can't claim you've got that state in your head but you're somehow not "thinking" about it. You're thinking about types all the time. Your complaint is more than you like a programming style that involves very complicated type ideas that are difficult to express in a static language. (Or, possibly, that you haven't taken the time to learn to express in a static language. There are some static languages that work better with this style than others.) Or that you don't want the constraint of having to express them. So you stick to an environment that loads the work on to you instead in return for the power of those more complicated things you never have to lay out for the compiler. But the work is getting done somewhere. It has to be, or your program wouldn't work.

doomvox 5y ago

Douglas Crockford, "Javascript: The Good Parts" (2008): "But it turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are not the errors I worry about."