3 ms·

The problem with complex type systems is that they force you to spend a lot of your development time thinking about type structures and their relationships (in

The problem with complex type systems is that they force you to spend a lot of your development time thinking about type structures and their relationships (in a universal way) instead of thinking about actual logic (in a more localized way). For example, when you introduce third party modules into your code, sometimes it's impossible to cleanly reconcile the type structures exposed by the module with the type structures within your own system... You may end up with essentially identical concepts being classified as completely different types/classes/interfaces... It creates an unnecessary impedance mismatch between your logic and the logic exposed by third-party modules. This type impedance mismatch may discourage developers from using third-party modules altogether. That might explain why dynamically typed languages like JavaScript and Ruby have such rich third-party module ecosystems compared to that of statically typed languages. Unless there is a single standardized and universally accepted type system which is fully consistent across the minds of all developers of a specific language/platform (for all possible applications), then a type system makes no sense at all; especially a complex one.

whateveracct 8y ago
Those impedance mismatches are equally present in dynamically typed code. The only thing types do is help make it obvious when there are problems with composition. I work in Haskell with many other Haskell developers and a wide variety of Haskell mindsets. It’s a very complex type system we use a lot of, and so far, the issues you mention are so minor and worth it.
- grosjona 8y ago
  With dynamically languages, the type of an object is not important so you don't need to explicitly typecast external objects to fit into your logic. With dynamically typed languages, if two different objects expose the same functions then you can use them in the same way. The behavior of an object is all that counts.
  - wtetzner 8y ago
    You seem to be talking about nominal types being a problem. Structural subtyping and row types are two ways of getting the benefits you're talking about while still being statically typed.
  - mannykannot 8y ago
    If two different objects expose the same functions then you can call them in the same way. You have no way of knowing, from the function names and arity, whether their semantics are what you need. Once you start asking that question, you are asking the sort of questions that using types helps answer.
hardwaresofton 8y ago
Yeah this is almost completely wrong IMHO, could you give some concrete examples of when this happened to you or someone you know? I'm writing a relatively small haskell app, and though I've had large swaths of time where I had to think about the types I was writing exclusively, I almost always come out of the 30 minutes or so understanding my code, and what I'm trying to do so much better. Forcing you to spend time thinking about type structures and their relationships is (dare I say) the essence of programming. Programming is in the end about transforming data for some useful end (and some side effects along the way), and no one wants to work with 0s and 1s directly. Integrating with third party modules in haskell is no more painful than integrating with 3rd party modules in Java, in fact is way way way simpler, given Java's infamous verbosity and love of enterprise patterns (tm).
- grosjona 8y ago
  Java gets away with it because it has a very large core library which defines pretty much any type that a developer could think of. For example, there is even a standard class type for URLs which all good Java developers must agree on. All these standardized types are often unnecessarily restrictive and demand too much attention and global awareness of the environment. It's often possible to write good code without necessarily understanding everything that is happening above or below a particular unit of logic; so why force the developer to internalize all these rigid concepts?
  - hardwaresofton 8y ago
    The larger standard library of languages like Java is indeed a big benefit -- I think I see more where you're coming from now. Haskell does not have a large standard library like other languages, but people usually build on one or two libraries in a given problem space to avoid duplication (checking to see if someone has a lib you can use instead of writing one yourself is pretty natural). In my experience, it's been rare to find two libraries that need to interoperate that defined two different classes for URLs (for example) -- but you're absolutely right, it could be a problem. The problem would be solved if Haskell were to adopt a large standard library, but I still don't see this as a problem with types, this is more a language/community issue. Speaking more concretely, I'd consider understanding the types flowing in and out of a function/abstraction that you got from a library table stakes for writing good code. IMO it's rare that you can just import a library, write strictly glue code (without thinking about the concepts) that magically solves all your problems. For example, lets say you needed to parse a ISO 8601 date string (and it isn't in your standard library) -- in that kind of case you can just pull down a library and run one function and be done. Usually though, you'll need to at least understand the functions inputs (unless the function is defined for every kind of input you could give it), and understand the output...

whateveracct 8y ago

Those impedance mismatches are equally present in dynamically typed code. The only thing types do is help make it obvious when there are problems with composition. I work in Haskell with many other Haskell developers and a wide variety of Haskell mindsets. It’s a very complex type system we use a lot of, and so far, the issues you mention are so minor and worth it.

grosjona 8y ago
With dynamically languages, the type of an object is not important so you don't need to explicitly typecast external objects to fit into your logic. With dynamically typed languages, if two different objects expose the same functions then you can use them in the same way. The behavior of an object is all that counts.
- wtetzner 8y ago
  You seem to be talking about nominal types being a problem. Structural subtyping and row types are two ways of getting the benefits you're talking about while still being statically typed.
- mannykannot 8y ago
  If two different objects expose the same functions then you can call them in the same way. You have no way of knowing, from the function names and arity, whether their semantics are what you need. Once you start asking that question, you are asking the sort of questions that using types helps answer.

hardwaresofton 8y ago

Yeah this is almost completely wrong IMHO, could you give some concrete examples of when this happened to you or someone you know? I'm writing a relatively small haskell app, and though I've had large swaths of time where I had to think about the types I was writing exclusively, I almost always come out of the 30 minutes or so understanding my code, and what I'm trying to do so much better. Forcing you to spend time thinking about type structures and their relationships is (dare I say) the essence of programming. Programming is in the end about transforming data for some useful end (and some side effects along the way), and no one wants to work with 0s and 1s directly. Integrating with third party modules in haskell is no more painful than integrating with 3rd party modules in Java, in fact is way way way simpler, given Java's infamous verbosity and love of enterprise patterns (tm).

grosjona 8y ago
Java gets away with it because it has a very large core library which defines pretty much any type that a developer could think of. For example, there is even a standard class type for URLs which all good Java developers must agree on. All these standardized types are often unnecessarily restrictive and demand too much attention and global awareness of the environment. It's often possible to write good code without necessarily understanding everything that is happening above or below a particular unit of logic; so why force the developer to internalize all these rigid concepts?
- hardwaresofton 8y ago
  The larger standard library of languages like Java is indeed a big benefit -- I think I see more where you're coming from now. Haskell does not have a large standard library like other languages, but people usually build on one or two libraries in a given problem space to avoid duplication (checking to see if someone has a lib you can use instead of writing one yourself is pretty natural). In my experience, it's been rare to find two libraries that need to interoperate that defined two different classes for URLs (for example) -- but you're absolutely right, it could be a problem. The problem would be solved if Haskell were to adopt a large standard library, but I still don't see this as a problem with types, this is more a language/community issue. Speaking more concretely, I'd consider understanding the types flowing in and out of a function/abstraction that you got from a library table stakes for writing good code. IMO it's rare that you can just import a library, write strictly glue code (without thinking about the concepts) that magically solves all your problems. For example, lets say you needed to parse a ISO 8601 date string (and it isn't in your standard library) -- in that kind of case you can just pull down a library and run one function and be done. Usually though, you'll need to at least understand the functions inputs (unless the function is defined for every kind of input you could give it), and understand the output...