4 ms·

I’m misunderstanding or that’s just not true. Maybe you’re imagining classic Java? I use Scala and the syntax is pretty slim to get very rich typing. Love it c

I’m misunderstanding or that’s just not true. Maybe you’re imagining classic Java? I use Scala and the syntax is pretty slim to get very rich typing. Love it compared to non-static typing.

ReflectedImage 3y ago
Well Java syntax is very verbose, but I'm referring to the effects of static typing on the program structure. Dynamically typed programs have much simpler structures and are much easier to reason about and test than their static typed counterparts. The larger the program you write with static typing, the worse it becomes compared to it's dynamically typed counterpart. The internal complexity of statically typed programs grows at a much higher rate. This increases development times and decreases program correctness. Through I don't think I can really do a fair comparsion with a functional language like Scala. I've only used Scala for 2 weeks on a single project. Functional languages tend to increase code correctness by trading away performance.
- therealdrag0 3y ago
  Sorry for being a pain, but I’m still not seeing it. You gave an example of LOC but now have stepped back again into speaking in generalities. What structures and what complexities are you talking about? Give me examples. Tbh I have no idea what you’re talking about. ELI5.
  - ReflectedImage 3y ago
    Roughly stuff like templating, abstract base classes, generics and non-trivial user defined types. Consider a simple program that adds 2 numbers: a & b together. In a dynamically typed language, this would be a + b. In a statically typed language, once you consider overflow and underflow, you will likely have a hundred lines of code. This creeps up again in JSON parsing where the types really are defined at runtime. But the most general case is people creating complex and hard to understand types in their code, which they then export to unsuspecting developers to use. e.g. The type of stuff that forced C++ to introduce the auto keyword.
    - paulmd 3y ago
      > In a dynamically typed language, this would be a + b. In a statically typed language, once you consider overflow and underflow, you will likely have a hundred lines of code. https://stackoverflow.com/questions/52376716/c-overloading-of-the-plus-operator https://stackoverflow.com/questions/52376716/c-overloading-o... literally a single line of code to overload an operator. anyway, if you don't consider error states in your dynamic implementation and you do this in static then yes, it could be simpler. But static doesn't force you to consider error conditions - just like this C++ example does not. and yes, if you fall back on javascript notions of default cross-type arithmetic (1 + "1" = ?) then you will get something, and if you take great care to structure your code you may get something useful as a side-effect, but, this is not meaningfully different from the error-state for most people. Getting [] or "11" isn't the expected outcome unless you've come to expect that quirk of javascript, and is something that a static compiler would rightfully complain about - because a user asking for an undefined operation computed across incompatible types seems like a classic type error. If it's not, then just define the operators that are meaningful to you - and you could define it as an interface if you wanted it to work with a bunch of classes etc. Again though, the complaint elsewhere that "a lot of this debate just ends up being dynamic programmers who are unaccustomed to using static types at all and think it must be so super burdensome all the time" seems pretty accurate. Defining custom operators is not something that occupies even 1% of my time in any static language.
      - ReflectedImage 3y ago
        The code you posted is incorrect and full of bugs. For example, if A is 9223372036854775807 and B is 10, then you will get the incorrect answer. Try it out if you don't believe me. Another example is A is -9223372036854775807 and B is -10. Again you will get an incorrect result. Once you finish fixing these bugs it will be at least 100 lines long. The dynamically typed version of the code is just A + B. "a lot of this debate just ends up being dynamic programmers who are unaccustomed to using static types at all" Static typing is objectively the inferior approach. It's just that people are too lazy to learn how to code with two different typing systems. Overall statically typed programmers only code at 1/3 of the speed as their dynamically typed counterparts. Of course, if you have only ever done statically typed programming, you are not going to understand how bad it is in comparsion.
- freilanzer 3y ago
  > Dynamically typed programs have much simpler structures and are much easier to reason about and test than their static typed counterparts. That just makes no sense. Both programs have the same underlying structure, but it's hidden in dynamic languages. Having no compiler and type system makes reasoning much more difficult, there is no discussion about that. > The larger the program you write with static typing, the worse it becomes compared to it's dynamically typed counterpart. Again, that's just not the case: try refactoring Python code without type hints in a large code base. It takes a lot more time and effort and you can never be sure you caught all the cases affected by changes. The compiler tells you about every change needed to be made to arrive at a working state.
  - ReflectedImage 3y ago
    Dynamically typed programs can be structured in far better ways than statically typed programs. >Both programs have the same underlying structure No they don't, this is just a massive gap in your knowledge. > try refactoring Python code without type hints in a large code base I've done that on multiple occasions, the test suite is fine, thank you very much.
    - deleted 3y ago
      [deleted]
    - freilanzer 3y ago
      > Dynamically typed programs can be structured in far better ways than statically typed programs. That's simply not true. > No they don't, this is just a massive gap in your knowledge. Based on your responses here I don't think you really know what you are talking about. > I've done that on multiple occasions, the test suite is fine, thank you very much. Well, if you say so.

I’m misunderstanding or that’s just not true. Maybe you’re imagining classic Java? I use Scala and the syntax is pretty slim to get very rich typing. Love it compared to non-static typing.

ReflectedImage 3y ago

Well Java syntax is very verbose, but I'm referring to the effects of static typing on the program structure. Dynamically typed programs have much simpler structures and are much easier to reason about and test than their static typed counterparts. The larger the program you write with static typing, the worse it becomes compared to it's dynamically typed counterpart. The internal complexity of statically typed programs grows at a much higher rate. This increases development times and decreases program correctness. Through I don't think I can really do a fair comparsion with a functional language like Scala. I've only used Scala for 2 weeks on a single project. Functional languages tend to increase code correctness by trading away performance.

therealdrag0 3y ago
Sorry for being a pain, but I’m still not seeing it. You gave an example of LOC but now have stepped back again into speaking in generalities. What structures and what complexities are you talking about? Give me examples. Tbh I have no idea what you’re talking about. ELI5.
- ReflectedImage 3y ago
  Roughly stuff like templating, abstract base classes, generics and non-trivial user defined types. Consider a simple program that adds 2 numbers: a & b together. In a dynamically typed language, this would be a + b. In a statically typed language, once you consider overflow and underflow, you will likely have a hundred lines of code. This creeps up again in JSON parsing where the types really are defined at runtime. But the most general case is people creating complex and hard to understand types in their code, which they then export to unsuspecting developers to use. e.g. The type of stuff that forced C++ to introduce the auto keyword.
  - paulmd 3y ago
    > In a dynamically typed language, this would be a + b. In a statically typed language, once you consider overflow and underflow, you will likely have a hundred lines of code. https://stackoverflow.com/questions/52376716/c-overloading-of-the-plus-operator https://stackoverflow.com/questions/52376716/c-overloading-o... literally a single line of code to overload an operator. anyway, if you don't consider error states in your dynamic implementation and you do this in static then yes, it could be simpler. But static doesn't force you to consider error conditions - just like this C++ example does not. and yes, if you fall back on javascript notions of default cross-type arithmetic (1 + "1" = ?) then you will get something, and if you take great care to structure your code you may get something useful as a side-effect, but, this is not meaningfully different from the error-state for most people. Getting [] or "11" isn't the expected outcome unless you've come to expect that quirk of javascript, and is something that a static compiler would rightfully complain about - because a user asking for an undefined operation computed across incompatible types seems like a classic type error. If it's not, then just define the operators that are meaningful to you - and you could define it as an interface if you wanted it to work with a bunch of classes etc. Again though, the complaint elsewhere that "a lot of this debate just ends up being dynamic programmers who are unaccustomed to using static types at all and think it must be so super burdensome all the time" seems pretty accurate. Defining custom operators is not something that occupies even 1% of my time in any static language.
    - ReflectedImage 3y ago
      The code you posted is incorrect and full of bugs. For example, if A is 9223372036854775807 and B is 10, then you will get the incorrect answer. Try it out if you don't believe me. Another example is A is -9223372036854775807 and B is -10. Again you will get an incorrect result. Once you finish fixing these bugs it will be at least 100 lines long. The dynamically typed version of the code is just A + B. "a lot of this debate just ends up being dynamic programmers who are unaccustomed to using static types at all" Static typing is objectively the inferior approach. It's just that people are too lazy to learn how to code with two different typing systems. Overall statically typed programmers only code at 1/3 of the speed as their dynamically typed counterparts. Of course, if you have only ever done statically typed programming, you are not going to understand how bad it is in comparsion.
freilanzer 3y ago
> Dynamically typed programs have much simpler structures and are much easier to reason about and test than their static typed counterparts. That just makes no sense. Both programs have the same underlying structure, but it's hidden in dynamic languages. Having no compiler and type system makes reasoning much more difficult, there is no discussion about that. > The larger the program you write with static typing, the worse it becomes compared to it's dynamically typed counterpart. Again, that's just not the case: try refactoring Python code without type hints in a large code base. It takes a lot more time and effort and you can never be sure you caught all the cases affected by changes. The compiler tells you about every change needed to be made to arrive at a working state.
- ReflectedImage 3y ago
  Dynamically typed programs can be structured in far better ways than statically typed programs. >Both programs have the same underlying structure No they don't, this is just a massive gap in your knowledge. > try refactoring Python code without type hints in a large code base I've done that on multiple occasions, the test suite is fine, thank you very much.
  - deleted 3y ago
    [deleted]
  - freilanzer 3y ago
    > Dynamically typed programs can be structured in far better ways than statically typed programs. That's simply not true. > No they don't, this is just a massive gap in your knowledge. Based on your responses here I don't think you really know what you are talking about. > I've done that on multiple occasions, the test suite is fine, thank you very much. Well, if you say so.