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
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.
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