4 ms·

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 (depen

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
  I think about types (almost?) every time I write a function. What type of data does the function expect, and what type of data am I supposed to transform this data to? For instance, if I calculate the time that has elapsed between two points in time: - what does my input look like (e.g. two objects that look like XY) - in what form should I return the difference? Time in seconds (i.e. number), again an object that looks like XY ? ... I can't imagine saying I would care about types rarely. Another nice benefit of st langs is that you have to read manuals less often. IDEs so a way better job showing you the type of every variable (and result of an operation) as well as the options you have at your hand for a given type (including their documentation and example code). Yes I know dt languages and their tools try to catch up. > 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. Well, I don't expect that with Dr languages as well, but I am glad that the compiler does this (or in DT languages at least the IDE due to type hints). I mean, it saves a lot of time (money) later on ... even if you notice it right away the first time you use the code
  - belorn 5y ago
    Interesting, let me do the same example and see how my thought process differ. I would first ask, should I write a function or maybe have this as an property of the object that has the original data. I want the intended interface to influence my design. What methods does my input has? Does it already implement what I want or have a helper function that makes writing the transformation easier? Is there built in functions or third-party libraries that do time differences calculations. Within python I would apply some minor assumptions about types. If something is a time it is either a string or an object with a time interface, and so I might need to cast it to a time-like object. Preferable this already occurred as close to the edge of the program as possible so in the rest of the program I don't need to put any thought about the type. If its a date, it should be a an object with a time interface. If time strings are floating around in the data flow, just as with byte strings, I should try to fix that as early and close to the edge of the program. There seems to be a similar view about unicode. You don't want to have every function check if the input is of the type unicode. Instead what people do is when they read a byte string, they turn it into unicode as everything else assume the unicode interface.

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
I think about types (almost?) every time I write a function. What type of data does the function expect, and what type of data am I supposed to transform this data to? For instance, if I calculate the time that has elapsed between two points in time: - what does my input look like (e.g. two objects that look like XY) - in what form should I return the difference? Time in seconds (i.e. number), again an object that looks like XY ? ... I can't imagine saying I would care about types rarely. Another nice benefit of st langs is that you have to read manuals less often. IDEs so a way better job showing you the type of every variable (and result of an operation) as well as the options you have at your hand for a given type (including their documentation and example code). Yes I know dt languages and their tools try to catch up. > 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. Well, I don't expect that with Dr languages as well, but I am glad that the compiler does this (or in DT languages at least the IDE due to type hints). I mean, it saves a lot of time (money) later on ... even if you notice it right away the first time you use the code
- belorn 5y ago
  Interesting, let me do the same example and see how my thought process differ. I would first ask, should I write a function or maybe have this as an property of the object that has the original data. I want the intended interface to influence my design. What methods does my input has? Does it already implement what I want or have a helper function that makes writing the transformation easier? Is there built in functions or third-party libraries that do time differences calculations. Within python I would apply some minor assumptions about types. If something is a time it is either a string or an object with a time interface, and so I might need to cast it to a time-like object. Preferable this already occurred as close to the edge of the program as possible so in the rest of the program I don't need to put any thought about the type. If its a date, it should be a an object with a time interface. If time strings are floating around in the data flow, just as with byte strings, I should try to fix that as early and close to the edge of the program. There seems to be a similar view about unicode. You don't want to have every function check if the input is of the type unicode. Instead what people do is when they read a byte string, they turn it into unicode as everything else assume the unicode interface.