5 ms·

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

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.
        scrollaway 5y ago
        I've worked with python for 17 years. I maintain that given your arguments, you haven't tried a properly set up static language. I know how to make python safe with TDD. It doesn't even sort of compare.
        belorn 5y ago
        You can maintain that if you like. I don't want to speculate why you feel so attached to static languages. I worked with python in 15 years, you in 17. I have done low level embedded C code. I done web development, and shell scripts. Tried lisp, and programmed in Ada. If you have also worked with similar amount of languages and reach a different conclusion then either your work is very different from mine, or you as an other person have a different experience than mine. When it comes to keeping simple thing being simple, static languages has never delivered for me. In embedded system I live with that aspect, but that's the nature of such environments. The primary question when working with dynamic language is: "is there already a library that does what I want, and how do I modify it to work in my use case". Instead of thinking about structure and types, I am thinking about interfaces. I will conceit one example where a static typed language is much better than a dynamic typed, and it illustrate the environment where such language aspect shine. SQL. SQL with dynamic types would be horrible and any database which treat types some-what dynamic is a horror to work with. SQL does not make simple things simple, and database exceptions are quite harsh in every aspect. There is also few if any interfaces, so its types or nothing.
- 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

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.
      - scrollaway 5y ago
        I've worked with python for 17 years. I maintain that given your arguments, you haven't tried a properly set up static language. I know how to make python safe with TDD. It doesn't even sort of compare.
        belorn 5y ago
        You can maintain that if you like. I don't want to speculate why you feel so attached to static languages. I worked with python in 15 years, you in 17. I have done low level embedded C code. I done web development, and shell scripts. Tried lisp, and programmed in Ada. If you have also worked with similar amount of languages and reach a different conclusion then either your work is very different from mine, or you as an other person have a different experience than mine. When it comes to keeping simple thing being simple, static languages has never delivered for me. In embedded system I live with that aspect, but that's the nature of such environments. The primary question when working with dynamic language is: "is there already a library that does what I want, and how do I modify it to work in my use case". Instead of thinking about structure and types, I am thinking about interfaces. I will conceit one example where a static typed language is much better than a dynamic typed, and it illustrate the environment where such language aspect shine. SQL. SQL with dynamic types would be horrible and any database which treat types some-what dynamic is a horror to work with. SQL does not make simple things simple, and database exceptions are quite harsh in every aspect. There is also few if any interfaces, so its types or nothing.
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