3 ms·

It sounds like there's a lot of PL innovators† here on HN, who value new technology for its intrinsic value, rather than for its benefits. I would expect PL th

by 6ren 15y ago

It sounds like there's a lot of PL innovators† here on HN, who value new technology for its intrinsic value, rather than for its benefits. I would expect PL theory to deliver great benefits at about the same rate as for other fields, e.g. that pure mathematics does for physics - some of it does; though it's common for it to be reinvented independently by people trying to solve specific problems. BTW: Notwithstanding the over-general flame-bait title, I think his "types are anti-modular" is really just making the point that, while interfaces reduce your dependence on implementation, now you depend on interfaces. i.e. The problem with using types to hide decisions that you think will change is if your prediction about what will change is wrong. "On the Criteria to Be Used in Decomposing Systems Into Modules" http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crite... Perhaps one solution is to specify all the types you use in a module, internally; and provide a mechanism for converting between equivalent types at the boundary, to remove the dependency while facilitating interoperation. This mechanism acts as a buffer or glue (or middleware) - a kind of interface between interfaces if you will. † Although the technology adoption lifecycle gives the impression that a new technology with interesting properties is just the beginning of great things, the vast majority of new things do not become massively successful - it's just that the lifecycle is based on those that were. http://en.wikipedia.org/wiki/Technology_adoption_lifecycle http://en.wikipedia.org/wiki/Technology_adoption_lifecycle

dingfeng_quek 15y ago
It is easy to agree that there MUST be essential dependencies between modules in a system designed separated in a certain way. (Ignoring some philo arguments on identity, separation and reference point...) The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique. Types add constraints, thus increasing coupling (and decreasing modularity). Although types have benefits. And direct modularity is seldom the only concern. I.e. Correctness and reliability also enhances modularity in an indirect way - an erroneous module definitely decreases modularity.
- 6ren 15y ago
  > The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique. I'm not sure exactly what you mean. Could you elaborate please? I'll clarify my view with an analogous example: you can think of a database as having a set of types - its schema. Think of each of the applications that use that database as also having its own set of types - its classes or data structures in general. Now, an example of the "mechanism" I mean is that SQL provides a way for each app to translate data in the database's schema into its own data structures. If its data structures change, the SQL can change to adapt to that; similarly, if the DB's schema changes, it can also adapt by changing SQL (or even creating a virtual schema with another layer of SQL - a view). Of course, this only works if these are only changes of the representation of the information, and the information content itself is the same. If the information changes, in a way that the DB or an app depends on, then there's no avoiding that dependency. A similar example are JSON/XML API's, where the JSON/XML is like the DB, and the data binding code is like SQL. The "type" of XML is often explicitly defined with an "XML Schema" document; JSON doesn't usually have that, but it is of an implicit expected form - which is still a type, just informally defined. There are also tools for converting between XML types - XSLT, and may GUI "XML mappers" that display two xml schema and let you draw lines between them. tl;dr These enable "modules" with different types to interoperate without dependency. Each defines its own types at its own boundary, and so can be compiled independently. The middleware glue (SQL/databinder/XSLT/datamapper) facilitates interoperation by converting between types at the respective boundaries of two modules - provided those types are equivalent, i.e. contain the same information, just in a different schema/type. Does your concept of "non-essential coupling" include the requirement of precisely identical types at the boundary? If so, by loosening that to only require the same information, this mechanism avoids that particular kind of non-essential coupling.
  - dingfeng_quek 15y ago
    Typing adds constraints - the type must be represented by and implemented in a particular type system. A trivial anti-modular constraint is that interacting modules must all use the same type system. The type system matters too - in Java, choosing from easily implementable types can easily add a lot to the complexity of the data structure, leading to a complex interface (in a more expressive type system, less of this happens). More trivially, adding types IS adding constraints that are verifiable at compile time. If compile-time verification of that sort is not essential (or not desired, which is the more general form of not essential), then the constraints are non-essential (or not desired). --- Whether you choose to 1. Choose a particular data-structure and implement both modules to pass and receive that data-structure. 2. Specify an interface: The interface requires the data-structure to have certain properties (e.g. some methods work on them). The modules then build to the interface. 3. Specify that an adaptor exist to convert the data-structure to whatever the module requires. is a somewhat different issue, although the kind of type system used does affect the implementation complexity and effort required.

by 6ren 15y ago

dingfeng_quek 15y ago

It is easy to agree that there MUST be essential dependencies between modules in a system designed separated in a certain way. (Ignoring some philo arguments on identity, separation and reference point...) The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique. Types add constraints, thus increasing coupling (and decreasing modularity). Although types have benefits. And direct modularity is seldom the only concern. I.e. Correctness and reliability also enhances modularity in an indirect way - an erroneous module definitely decreases modularity.

6ren 15y ago
> The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique. I'm not sure exactly what you mean. Could you elaborate please? I'll clarify my view with an analogous example: you can think of a database as having a set of types - its schema. Think of each of the applications that use that database as also having its own set of types - its classes or data structures in general. Now, an example of the "mechanism" I mean is that SQL provides a way for each app to translate data in the database's schema into its own data structures. If its data structures change, the SQL can change to adapt to that; similarly, if the DB's schema changes, it can also adapt by changing SQL (or even creating a virtual schema with another layer of SQL - a view). Of course, this only works if these are only changes of the representation of the information, and the information content itself is the same. If the information changes, in a way that the DB or an app depends on, then there's no avoiding that dependency. A similar example are JSON/XML API's, where the JSON/XML is like the DB, and the data binding code is like SQL. The "type" of XML is often explicitly defined with an "XML Schema" document; JSON doesn't usually have that, but it is of an implicit expected form - which is still a type, just informally defined. There are also tools for converting between XML types - XSLT, and may GUI "XML mappers" that display two xml schema and let you draw lines between them. tl;dr These enable "modules" with different types to interoperate without dependency. Each defines its own types at its own boundary, and so can be compiled independently. The middleware glue (SQL/databinder/XSLT/datamapper) facilitates interoperation by converting between types at the respective boundaries of two modules - provided those types are equivalent, i.e. contain the same information, just in a different schema/type. Does your concept of "non-essential coupling" include the requirement of precisely identical types at the boundary? If so, by loosening that to only require the same information, this mechanism avoids that particular kind of non-essential coupling.
- dingfeng_quek 15y ago
  Typing adds constraints - the type must be represented by and implemented in a particular type system. A trivial anti-modular constraint is that interacting modules must all use the same type system. The type system matters too - in Java, choosing from easily implementable types can easily add a lot to the complexity of the data structure, leading to a complex interface (in a more expressive type system, less of this happens). More trivially, adding types IS adding constraints that are verifiable at compile time. If compile-time verification of that sort is not essential (or not desired, which is the more general form of not essential), then the constraints are non-essential (or not desired). --- Whether you choose to 1. Choose a particular data-structure and implement both modules to pass and receive that data-structure. 2. Specify an interface: The interface requires the data-structure to have certain properties (e.g. some methods work on them). The modules then build to the interface. 3. Specify that an adaptor exist to convert the data-structure to whatever the module requires. is a somewhat different issue, although the kind of type system used does affect the implementation complexity and effort required.