Sometimes a restriction in a programming language makes sense and no sense at all — all at the same time.
Think about the Java restrictions on the modeling of classes: a given class can only have one supertype and a given object's class is fixed for its lifetime.
From a programming language perspective these restrictions make a good deal of sense: all kinds of ambiguities are possible with multiple inheritance and the very idea of allowing an object to be 'rebased' fills the compiler writer with horror. (Though SmallTalk allows it.)
The problem is that, in real life, these things do happen. A 'natural' domain model is quite likely to come up with situations involving multiple inheritance and dynamic rebasing.
For example, a person can go from being a customer, to an employee, to a manager to being retired. A given person might be both an employee and a customer simultaneously (someone else may not be).
Given a domain that is as flexible as this one if forced to 'simulate' it in Java. I.e., one cannot use a Java class called
At the same time, the modeling is not random and a good architect will try to ensure some discipline in the application.
The logical conclusion is that large applications tend to contain a variant of 'the type system' where the domain model is represented. Java is used to implement the meta model, not the domain model.
This dynamic type system may or may not be based on a well founded model (such as that of description logic); but in any case the programming language is not helping as much as it should.
On the face of it, it seems that the logical thing is to make a programming language's type system sufficiently flexible to actually model real world scenarios.
However, there is a difficulty with that: it is not the case that any one modeling system is best suited to all applications. In addition, a modeling system that is well-suited to modeling domain knowledge is not guaranteed to be equally well suited to regular programming tasks.
A better approach is to embrace diversity. A combination of DSLs and libraries enable one to build out a particular modeling system and to support the programmer with direct appropriate syntax.
For example, this pseudo-code example:
shows one example of a modeled customer. The 'actual' code implied by this fragment might look like:
The principal point here is that the syntactic sugar offered by a DSL is not mere syntactic sugar: it can help the application programmer to use a language that is appropriate for her needs while at the same time enforcing sanity checks implied by the particular modeling language.
At the same time, there is no implied permanent commitment to one particular way of modeling with the host language.
Modeling the real world
Think about the Java restrictions on the modeling of classes: a given class can only have one supertype and a given object's class is fixed for its lifetime.
From a programming language perspective these restrictions make a good deal of sense: all kinds of ambiguities are possible with multiple inheritance and the very idea of allowing an object to be 'rebased' fills the compiler writer with horror. (Though SmallTalk allows it.)
The problem is that, in real life, these things do happen. A 'natural' domain model is quite likely to come up with situations involving multiple inheritance and dynamic rebasing.
For example, a person can go from being a customer, to an employee, to a manager to being retired. A given person might be both an employee and a customer simultaneously (someone else may not be).
Given a domain that is as flexible as this one if forced to 'simulate' it in Java. I.e., one cannot use a Java class called
Customer to represent a customer; because Java's idea of class is not rich enough to model the domain.At the same time, the modeling is not random and a good architect will try to ensure some discipline in the application.
The logical conclusion is that large applications tend to contain a variant of 'the type system' where the domain model is represented. Java is used to implement the meta model, not the domain model.
This dynamic type system may or may not be based on a well founded model (such as that of description logic); but in any case the programming language is not helping as much as it should.
What is a language to do?
On the face of it, it seems that the logical thing is to make a programming language's type system sufficiently flexible to actually model real world scenarios.
However, there is a difficulty with that: it is not the case that any one modeling system is best suited to all applications. In addition, a modeling system that is well-suited to modeling domain knowledge is not guaranteed to be equally well suited to regular programming tasks.
A better approach is to embrace diversity. A combination of DSLs and libraries enable one to build out a particular modeling system and to support the programmer with direct appropriate syntax.
For example, this pseudo-code example:
customer isa person
customer has account
...
person has name
...
C instance of customer
...
if overdrawn(C's account) then
...
shows one example of a modeled customer. The 'actual' code implied by this fragment might look like:
C : object;
...
if overdrawn(findAttribute(C,"account")) then
...
The principal point here is that the syntactic sugar offered by a DSL is not mere syntactic sugar: it can help the application programmer to use a language that is appropriate for her needs while at the same time enforcing sanity checks implied by the particular modeling language.
At the same time, there is no implied permanent commitment to one particular way of modeling with the host language.