4 ms·

> Are you proposing that a distinct `assoc-in` function should be written for every combination of types you'd need in your program? No. I'm proposing somethi

> Are you proposing that a distinct `assoc-in` function should be written for every combination of types you'd need in your program? No. I'm proposing something like what tel described elsewhere in the thread. If that's not dynamic enough for you, then you can go with something like JSON's Value type. In both cases lenses give you very convenient and composable access and manipulation. > I've always thought the function was trivial. I mean, it's just four lines of code: But you have to read the code. The type signature / code boundary is very useful for allowing you to chunk things and abstract over implementation details. This particular case may not be much code to read, but that is often not true in the general case. > Sure, but you have to write the type signatures, too. Type inference certainly cuts down on a lot of work, but it doesn't entirely eliminate the need for explicit typing. > I also tend to prefer adding explicit type signatures, even for functions that could be inferred. It makes type errors easier to catch. That's exactly my point. Type signatures can be inferred, specs cannot. Choosing to add them is irrelevant. If you want the add them that can be done automatically.

weavejester 9y ago
"No. I'm proposing something like what tel described elsewhere in the thread." tel's solutions are "use lenses" or "assume all keys are strings", both of which miss the point. Yes, you can work around the limitations of a static type system, either by finding another solution (lenses) or by making functions more specific (assume all keys are strings), but that doesn't mean the limitations disappear. It just means you're working around them. In a statically typed language the solutions to a problem are constrained by the type system. The question is not whether statically typed languages are more constrained than dynamically typed languages, but whether the constraints that static typing introduces are offset by the guarantees they purchase. "That's exactly my point. Type signatures can be inferred, specs cannot." The compiler can infer some type signatures, and if you're not explicitly typing your named functions (which is generally cited as good practice), that does mean you get some checking "for free". But specs can also test more things than types; they occupy a space somewhere inbetween static types and a generative testing solution like QuickCheck. Depending on the function, a spec might be more or less verbose than the equivalent checks in a language like Haskell.
- mightybyte 9y ago
  > Yes, you can work around the limitations of a static type system, either by finding another solution (lenses) or by making functions more specific (assume all keys are strings), but that doesn't mean the limitations disappear. It just means you're working around them. I'm less concerned about the theoretical limitations of types that you seem to be talking about and more interested in looking at concrete real-world applications where you think you need dynamic types and seeing exactly what we can do to address them with a type system. I know there exist things that are difficult or maybe impossible to define types for (the Y combinator for instance, or possibly this assoc-in). My argument is that you don't need this power. I don't care whether difficult to type things exist, I care about whether real-world problems require them. I have yet to encounter one that I felt requires the same amount of dynamic typing power that you seem to be arguing for. See this thread for some concrete examples: https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_the_static_typing_world_haskell_in/doyn7im/ https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_...

weavejester 9y ago

"No. I'm proposing something like what tel described elsewhere in the thread." tel's solutions are "use lenses" or "assume all keys are strings", both of which miss the point. Yes, you can work around the limitations of a static type system, either by finding another solution (lenses) or by making functions more specific (assume all keys are strings), but that doesn't mean the limitations disappear. It just means you're working around them. In a statically typed language the solutions to a problem are constrained by the type system. The question is not whether statically typed languages are more constrained than dynamically typed languages, but whether the constraints that static typing introduces are offset by the guarantees they purchase. "That's exactly my point. Type signatures can be inferred, specs cannot." The compiler can infer some type signatures, and if you're not explicitly typing your named functions (which is generally cited as good practice), that does mean you get some checking "for free". But specs can also test more things than types; they occupy a space somewhere inbetween static types and a generative testing solution like QuickCheck. Depending on the function, a spec might be more or less verbose than the equivalent checks in a language like Haskell.

mightybyte 9y ago
> Yes, you can work around the limitations of a static type system, either by finding another solution (lenses) or by making functions more specific (assume all keys are strings), but that doesn't mean the limitations disappear. It just means you're working around them. I'm less concerned about the theoretical limitations of types that you seem to be talking about and more interested in looking at concrete real-world applications where you think you need dynamic types and seeing exactly what we can do to address them with a type system. I know there exist things that are difficult or maybe impossible to define types for (the Y combinator for instance, or possibly this assoc-in). My argument is that you don't need this power. I don't care whether difficult to type things exist, I care about whether real-world problems require them. I have yet to encounter one that I felt requires the same amount of dynamic typing power that you seem to be arguing for. See this thread for some concrete examples: https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_the_static_typing_world_haskell_in/doyn7im/ https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_...