4 ms·

Dynamic typing aka type inferencing (like in Python, but also in Java and C# when you use "var") can get you in trouble quickly. Consider this code: var fir

Dynamic typing aka type inferencing (like in Python, but also in Java and C# when you use "var") can get you in trouble quickly. Consider this code: var fireable = someMethod(); firable.fire(); The programmer intended this code to fire an employee. Let's say this code is in a military application, and another programmer modified the someMethod() function to return a missile. As long as the missile object has a fire() method this code will compile just fine... and do something the code didn't intend to do, i.e., fire a missile! How likely are you to have employee firing and missile firing in the same program? Not very likely, but the principle is valid, nonetheless. You need to express your intention more clearly like this: Employee fireable = someMethod(); Now if someMethod() is modified to return a missile you get a compilation error, and the world will be a lot safer. You don't want missiles being fired by accident!

bazoom42 3y ago
If you think a method called ‘someMethod()’ is a good idea, then it will probably return a type called ‘Something’ and you are back to the same problem.
Jtsummers 3y ago
> Dynamic typing aka type inferencing Dynamic typing and type inference are not synonymous.
- breadwinner 3y ago
  Both have the same problem. I should have said Dynamic typing and type inferencing...
leptons 3y ago
Maybe don't name your methods as vaguely as "someMethod()", name it something like "Employee()", or "Missile()" depending on what is needed in the program. That way the vagueness of "someMethod()" doesn't cause unintended consequences.
- medellin 3y ago
  Naming doesn’t fix unintended consequences. If you are the only person to ever work in the codebase and you never hire anyone new and you have a perfect memory… sure i guess it works than.
  - leptons 3y ago
    static typing also doesn't fix unintended consequences. In the example given above, naming things descriptively and applying the smallest bit of common sense would achieve practically the same thing as static typing.
    - deleted 3y ago
      [deleted]
    - medellin 3y ago
      Sure but it finds compile time errors a whole lot easier. And when modifying code i can say from experience it’s much smoother to modify large statically typed projects than large dynamically typed ones. Actually anyone arguing against that i don’t even think it’s worth my breath since you likely just don’t have much experience and really like whatever your pet language is
      - leptons 3y ago
        >Actually anyone arguing against that i don’t even think it’s worth my breath since you likely just don’t have much experience and really like whatever your pet language is Thanks for the ad hominem attack, but I've been coding in C, C++, C#, python, javascript, php and a dozen other languages, as well as assembly language which doesn't even have types at all, for 40+ years. Maybe your ad hominem attacks work on other social media sites, but not here kiddo.
- ravenstine 3y ago
  Better yet, avoid methods and classes when possible in favor of functions that act on data structures, which live in contextual directories and can be renamed so as to avoid confusion.
hexane360 3y ago
"Dynamic typing" refers to types which can be determined only at runtime, not at compile time. "Type inference" is what you're referring to, and is an optional feature of static type checkers. For instance, C has static types but no type inference, while C++ has static types with type inference. The concept of "type inference" doesn't make sense for dynamic typing.
unlikelytomato 3y ago
I can understand what you are getting at. However, a more real world example should clear this up slightly. Both the variable name and method name are not conveying meaning in the above example. val underperformingEmployee = selectLowestPerformingEmployee(); which can be reduced to selectLowestPerformingEmployee().terminateEmployment(); But there are already a lot of strange state management issues with this code style. I would expect something more like this in the wild terminateWorstEmployee(){ var employee = hrService.lookupEmployeeByLowestPerformanceReview(); employeeTerminationService.initiateTermination(employee.id); } When things are named and abstracted properly, it should be very clear what is happening. var conventions won't save you here. Assignment from method calls seems to be the most likely place where this could POSSIBLY cause confusion. Maybe we can compromise on variable assignment directly from constructors? That seems to be the clearest example where the extra text is purely noise. It also causes a lot of line wrapping which indirectly causes even more noise.
nuancebydefault 3y ago
I see this being downvoted over the difference between dynamic typing and type inference. I feel this is unjustified. The example shows what can go wrong with type inference, which is in fact a feature of dynamicly typed languages (even though it is not explitly called type inference in that context).
- steveklabnik 3y ago
  > programmers tend to read essays until they getting to the first line they disagree with and then tweet about it, like a compiler https://twitter.com/tef_ebooks/status/1108101434141298695 https://twitter.com/tef_ebooks/status/1108101434141298695 I suspect many people didn't get past the first five words. That said, I agree with you that the point is more legitimate, but I don't think it's a particularly strong argument.
- IshKebab 3y ago
  Type inference isn't really a feature of dynamically typed languages any more than emergency stop is a feature of hand saws. It isn't applicable because there are no static types to infer. Type inference can in some cases lead to type confusion in a way that can also happen with dynamic types. In my experience it is extraordinarily rare, especially in languages with only limited or local type inference like Rust or C++.
  - nuancebydefault 3y ago
    Today I learned: don't call type introspection type inference if you do not want your HN popularity to decrease.
    - IshKebab 3y ago
      Type introspection is another thing entirely! That's basically reflection, which is nothing to do with anything mentioned so far. To be clear: * Dynamic typing: types are not known at compile time * Static typing: types are known at compile time and written down in the source code. * Static typing with type inference: types are known at compile time and inferred rather than being explicitly written down * Dynamic typing with type inference: nonsensical; not a thing * Type introspection: types can be inspected by code at runtime. Unrelated to any of the above. Can be found (or not found) in both dynamically typed and statically typed languages.

bazoom42 3y ago

If you think a method called ‘someMethod()’ is a good idea, then it will probably return a type called ‘Something’ and you are back to the same problem.

Jtsummers 3y ago

> Dynamic typing aka type inferencing Dynamic typing and type inference are not synonymous.

breadwinner 3y ago
Both have the same problem. I should have said Dynamic typing and type inferencing...

leptons 3y ago

Maybe don't name your methods as vaguely as "someMethod()", name it something like "Employee()", or "Missile()" depending on what is needed in the program. That way the vagueness of "someMethod()" doesn't cause unintended consequences.

medellin 3y ago
Naming doesn’t fix unintended consequences. If you are the only person to ever work in the codebase and you never hire anyone new and you have a perfect memory… sure i guess it works than.
- leptons 3y ago
  static typing also doesn't fix unintended consequences. In the example given above, naming things descriptively and applying the smallest bit of common sense would achieve practically the same thing as static typing.
  - deleted 3y ago
    [deleted]
  - medellin 3y ago
    Sure but it finds compile time errors a whole lot easier. And when modifying code i can say from experience it’s much smoother to modify large statically typed projects than large dynamically typed ones. Actually anyone arguing against that i don’t even think it’s worth my breath since you likely just don’t have much experience and really like whatever your pet language is
    - leptons 3y ago
      >Actually anyone arguing against that i don’t even think it’s worth my breath since you likely just don’t have much experience and really like whatever your pet language is Thanks for the ad hominem attack, but I've been coding in C, C++, C#, python, javascript, php and a dozen other languages, as well as assembly language which doesn't even have types at all, for 40+ years. Maybe your ad hominem attacks work on other social media sites, but not here kiddo.
ravenstine 3y ago
Better yet, avoid methods and classes when possible in favor of functions that act on data structures, which live in contextual directories and can be renamed so as to avoid confusion.

hexane360 3y ago

"Dynamic typing" refers to types which can be determined only at runtime, not at compile time. "Type inference" is what you're referring to, and is an optional feature of static type checkers. For instance, C has static types but no type inference, while C++ has static types with type inference. The concept of "type inference" doesn't make sense for dynamic typing.

unlikelytomato 3y ago

I can understand what you are getting at. However, a more real world example should clear this up slightly. Both the variable name and method name are not conveying meaning in the above example. val underperformingEmployee = selectLowestPerformingEmployee(); which can be reduced to selectLowestPerformingEmployee().terminateEmployment(); But there are already a lot of strange state management issues with this code style. I would expect something more like this in the wild terminateWorstEmployee(){ var employee = hrService.lookupEmployeeByLowestPerformanceReview(); employeeTerminationService.initiateTermination(employee.id); } When things are named and abstracted properly, it should be very clear what is happening. var conventions won't save you here. Assignment from method calls seems to be the most likely place where this could POSSIBLY cause confusion. Maybe we can compromise on variable assignment directly from constructors? That seems to be the clearest example where the extra text is purely noise. It also causes a lot of line wrapping which indirectly causes even more noise.

nuancebydefault 3y ago

I see this being downvoted over the difference between dynamic typing and type inference. I feel this is unjustified. The example shows what can go wrong with type inference, which is in fact a feature of dynamicly typed languages (even though it is not explitly called type inference in that context).

steveklabnik 3y ago
> programmers tend to read essays until they getting to the first line they disagree with and then tweet about it, like a compiler https://twitter.com/tef_ebooks/status/1108101434141298695 https://twitter.com/tef_ebooks/status/1108101434141298695 I suspect many people didn't get past the first five words. That said, I agree with you that the point is more legitimate, but I don't think it's a particularly strong argument.
IshKebab 3y ago
Type inference isn't really a feature of dynamically typed languages any more than emergency stop is a feature of hand saws. It isn't applicable because there are no static types to infer. Type inference can in some cases lead to type confusion in a way that can also happen with dynamic types. In my experience it is extraordinarily rare, especially in languages with only limited or local type inference like Rust or C++.
- nuancebydefault 3y ago
  Today I learned: don't call type introspection type inference if you do not want your HN popularity to decrease.
  - IshKebab 3y ago
    Type introspection is another thing entirely! That's basically reflection, which is nothing to do with anything mentioned so far. To be clear: * Dynamic typing: types are not known at compile time * Static typing: types are known at compile time and written down in the source code. * Static typing with type inference: types are known at compile time and inferred rather than being explicitly written down * Dynamic typing with type inference: nonsensical; not a thing * Type introspection: types can be inspected by code at runtime. Unrelated to any of the above. Can be found (or not found) in both dynamically typed and statically typed languages.