5 ms·

Right, you’re treating the code as statically typed even when it’s not. In that case you never gain the advantage of dynamic languages. Thinking so strictly ab

Right, you’re treating the code as statically typed even when it’s not. In that case you never gain the advantage of dynamic languages. Thinking so strictly about what types a function will receive rules out making use of things like decorators in python that operate on function arguments regardless of type. Or generic validation utils that take many types and return the passed in type after performing internal validation logic relevant to the type.

DCoder 8y ago
"Takes many types" ≠ "cannot be typed". TypeScript supports decorators, union types, and `any`/`unknown` types. Those generic use cases are good examples of flexible types, but I have a hard time seeing how * "I don't know whether the `getMyReplies()` function returns a list of items, an iterator, a non-rewindable generator whose results I need to cache, or a closure with/without memoization" and * "I don't know whether the singular Reply entity has a field called pid, parent_id, parentId, ParentID, ParentGUID, or parent_message_identifier" are advantageous to rendering a list of replies.
- z3t4 8y ago
  For code written in JavaScript you check the source code to see what arguments it takes and what it returns. If it's not written in JavaScript, for example a Browser API's or NodeJS built in module, you read the documentation and use console.log's. Then you rely of good naming, for example (nrA, nrB) => sum vs (a:Number, b:Number) => c:Number where the one without static types is more clear of what the function does and what it returns.
  - untog 8y ago
    Having to search through source for the argument types of a function is usually an example given in favour of strong typing, not against it.
    - z3t4 8y ago
      There are not many reasons to read the code of your dependencies, you will learn a lot doing so. One issue when you work with the compiled code is that the type annotations have been removed, and that type annotations leads to more terse code as it would otherwise become too verbose eg. number:number tends to become n:number and when the type is removed it just becomes n, so you kinda become dependent of your tooling and can't easily just stop using it in favor of something better.
      - DCoder 8y ago
        Compiled code doesn't have to be unreadable. Languages like C and C++ made it readable with debug symbols. The web stack does the same with source maps. The TypeScript compiler also offers to emit .d.ts files with type information for reuse in other projects.
root_axis 8y ago
> In that case you never gain the advantage of dynamic languages. Treating the code as statically typed makes the code predictable, less prone to bugs, and easier to maintain. If a function's return type is determined by dynamic factors at run-time, it becomes a maintenance and debugging nightmare; the effect is compounded as more and more unpredictable dynamic functions are chained together. > operate on function arguments regardless of type parameterized types and other techniques allow you to describe this type of behavior in a type safe way. > Or generic validation utils that take many types and return the passed in type after performing internal validation logic relevant to the type. All these things are possible in typed languages.
geowwy 8y ago
> Right, you’re treating the code as statically typed even when it’s not. In that case you never gain the advantage of dynamic languages. Both the things you mention can be done in statically typed languages. The only difference is in dynamic languages you don't have to declare interfaces, subclasses, etc. I just wonder whether that really is as much of an advantage as people think. I've spend years using both types of languages and I think I think the safety of statically typed languages is usually worth the slight amount of friction it adds.

DCoder 8y ago

"Takes many types" ≠ "cannot be typed". TypeScript supports decorators, union types, and `any`/`unknown` types. Those generic use cases are good examples of flexible types, but I have a hard time seeing how * "I don't know whether the `getMyReplies()` function returns a list of items, an iterator, a non-rewindable generator whose results I need to cache, or a closure with/without memoization" and * "I don't know whether the singular Reply entity has a field called pid, parent_id, parentId, ParentID, ParentGUID, or parent_message_identifier" are advantageous to rendering a list of replies.

z3t4 8y ago
For code written in JavaScript you check the source code to see what arguments it takes and what it returns. If it's not written in JavaScript, for example a Browser API's or NodeJS built in module, you read the documentation and use console.log's. Then you rely of good naming, for example (nrA, nrB) => sum vs (a:Number, b:Number) => c:Number where the one without static types is more clear of what the function does and what it returns.
- untog 8y ago
  Having to search through source for the argument types of a function is usually an example given in favour of strong typing, not against it.
  - z3t4 8y ago
    There are not many reasons to read the code of your dependencies, you will learn a lot doing so. One issue when you work with the compiled code is that the type annotations have been removed, and that type annotations leads to more terse code as it would otherwise become too verbose eg. number:number tends to become n:number and when the type is removed it just becomes n, so you kinda become dependent of your tooling and can't easily just stop using it in favor of something better.
    - DCoder 8y ago
      Compiled code doesn't have to be unreadable. Languages like C and C++ made it readable with debug symbols. The web stack does the same with source maps. The TypeScript compiler also offers to emit .d.ts files with type information for reuse in other projects.

root_axis 8y ago

> In that case you never gain the advantage of dynamic languages. Treating the code as statically typed makes the code predictable, less prone to bugs, and easier to maintain. If a function's return type is determined by dynamic factors at run-time, it becomes a maintenance and debugging nightmare; the effect is compounded as more and more unpredictable dynamic functions are chained together. > operate on function arguments regardless of type parameterized types and other techniques allow you to describe this type of behavior in a type safe way. > Or generic validation utils that take many types and return the passed in type after performing internal validation logic relevant to the type. All these things are possible in typed languages.

geowwy 8y ago

> Right, you’re treating the code as statically typed even when it’s not. In that case you never gain the advantage of dynamic languages. Both the things you mention can be done in statically typed languages. The only difference is in dynamic languages you don't have to declare interfaces, subclasses, etc. I just wonder whether that really is as much of an advantage as people think. I've spend years using both types of languages and I think I think the safety of statically typed languages is usually worth the slight amount of friction it adds.