4 ms·

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 pr

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.
  - belorn 5y ago
    You can pass a LoggedInUser to a thing expecting a URL in a dynamic language if the LoggedInUser has the same methods as defined in the interface of an URL. It called ducktyping. In the same line of thought, you should even actively avoid checking if LoggedInUser is of the type URL because a different type sharing the same interface as URL should be equally accepted as URL. Two objects with the same interface should not be treated different unless very special circumstances. If the code only expect the interface of an URL, the type of the object being sent in is irrelevant, and thus the programmer do not need to think about the type. Instead we are thinking about interfaces. Programming in a dynamic language do allow a programmer to not think about types, but they do need to think about interfaces. Programming in a static language require the programmer to think about types, but they also need to think about interfaces. Having types does not eliminate the obligations to think about interfaces regardless of programming style. If we want to use TypeScript as an example, a type is a data type of either Any Type, Built-In Type, and User-Defined Type. The Type System in TypeScript is responsible for checking the data type of any value taken before it can be provided as an input to the program. Interface in TypeScript: An Interface in TypeScript is a syntactical obligation that all entities must follow. It can only contain the declaration of the members and is responsible for defining the properties, methods, and events. In a way, it is responsible for defining a standard structure that the derived classes will have to follow. (above taken from https://www.geeksforgeeks.org/what-is-the-difference-between-interface-and-type-in-typescript/ https://www.geeksforgeeks.org/what-is-the-difference-between...) Is a type, as defined above, required for all programming? No. Interfaces? Yes. Interfaces are also more similar to customer requirements in that they define behavior. Do the object has an absolute path method. Do it has an UUID property. Can it be used to call open on. Those questions are not type questions, and so I do not think about type when answering them.
    - adwn 5y ago
      > Two objects with the same interface should not be treated different unless very special circumstances. ...until you accidentally pass the ClientsTable object to the delete_supplier() function, which expects a Supplier object. Unfortunately, the delete_supplier() function calls the delete() function of the passed object, which is helpfully provided by ClientsTable. Bummer. Eh, just restore it from backups, right?

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.
- belorn 5y ago
  You can pass a LoggedInUser to a thing expecting a URL in a dynamic language if the LoggedInUser has the same methods as defined in the interface of an URL. It called ducktyping. In the same line of thought, you should even actively avoid checking if LoggedInUser is of the type URL because a different type sharing the same interface as URL should be equally accepted as URL. Two objects with the same interface should not be treated different unless very special circumstances. If the code only expect the interface of an URL, the type of the object being sent in is irrelevant, and thus the programmer do not need to think about the type. Instead we are thinking about interfaces. Programming in a dynamic language do allow a programmer to not think about types, but they do need to think about interfaces. Programming in a static language require the programmer to think about types, but they also need to think about interfaces. Having types does not eliminate the obligations to think about interfaces regardless of programming style. If we want to use TypeScript as an example, a type is a data type of either Any Type, Built-In Type, and User-Defined Type. The Type System in TypeScript is responsible for checking the data type of any value taken before it can be provided as an input to the program. Interface in TypeScript: An Interface in TypeScript is a syntactical obligation that all entities must follow. It can only contain the declaration of the members and is responsible for defining the properties, methods, and events. In a way, it is responsible for defining a standard structure that the derived classes will have to follow. (above taken from https://www.geeksforgeeks.org/what-is-the-difference-between-interface-and-type-in-typescript/ https://www.geeksforgeeks.org/what-is-the-difference-between...) Is a type, as defined above, required for all programming? No. Interfaces? Yes. Interfaces are also more similar to customer requirements in that they define behavior. Do the object has an absolute path method. Do it has an UUID property. Can it be used to call open on. Those questions are not type questions, and so I do not think about type when answering them.
  - adwn 5y ago
    > Two objects with the same interface should not be treated different unless very special circumstances. ...until you accidentally pass the ClientsTable object to the delete_supplier() function, which expects a Supplier object. Unfortunately, the delete_supplier() function calls the delete() function of the passed object, which is helpfully provided by ClientsTable. Bummer. Eh, just restore it from backups, right?