I did a short presentation (3 slides) about requirements for a new subject-centric programming language on TMRA 2007. I made a reference to COBOL as a language that had built-in high-level support for defining and manipulating “business data”. Many modern programming languages “outsourced” data handling to relational databases and lost transparency and simplicity in manipulation of data.
Object-oriented programming languages (starting with Simula ) help to model various “things” in our computers. But object-oriented languages are not optimized for representing our knowledge about these “things”. For example, it is quite easy to define a class that represents people with several properties such as ‘first_name’ and ‘last_name’ (Ruby notation):
class Person attr_accessor :first_name,:last_name end
It is easy to create a new instance and assign some values:
p=Person.new p.first_name='John' p.last_name='Smith'
But what if we need to represent a situation when names can be changed over time? What if different sources have different information about names of the same person? What if information about names is not available directly but can be inferred/calculated based on exiting data and various inference rules? How can we specify that some object properties can be viewed/modified only by specific user groups?
What if we need to persist information about an object in some data store and retrieve this information later? What if we need to access and modify this information on a laptop when we do not have connectivity. How can we synchronize this information with a desktop that is connected to the network all the time?
These “basic”, everyday requirements break easily simplicity of traditional interpretation of the object-oriented paradigm and introduce complicated “frameworks” and APIs. Instead of using objects to model “things” we need a lot of objects do deal with infrastructure and to model technical aspects of our knowledge about “things”.
Dynamic languages such as Lisp, Prolog, Python, Ruby etc. allow to “hide” technicalities using meta-programming. These languages allow to build required “technical” constructs behind the scenes and help programmers to work with domain level objects.
For example, we can use “metaproperties” to define domain specific associations, names, occurrences and types:
class KnowsPerson < ActiveTopic::Association psi 'http://psi.ontopedia.net/knows_person' historical true symmetrical true role :person, :player_type => :person, :as_property => :knows_person, :card_min => 2, :card_max => 2 end class FirstName < ActiveTopic::Name psi 'http://psi.ontopedia.net/first_name' historical true card_max 1 domain :person end class LastName < ActiveTopic::Name psi 'http://psi.ontopedia.net/last_name' historical true card_max 1 domain :person end class DateOfBirth < ActiveTopic::Occurrence psi 'http://psi.ontopedia.net/date_of_birth' domain :person card_max 1 data_type :date end class Person < ActiveTopic::Topic psi 'http://psi.ontopedia.net/Person' sub_type :thing name :first_name name :last_name occurrence :date_of_birth association :knows_person end
We can use defined constructs to manipulate domain specific objects:
a=Person.create(:psi=>'JohnSmith',:at_date => '2007-10-01') a.first_name='John' a.last_name='Smith' a.save b=Person.create(:psi=>'JoeSmith', :first_name=>'Joe', :last_name=>'Smith', :at_date => '2007-10-02') b.save a=Person.find(:psi=>'JohnSmith',:at_date => '2007-10-03') b=Person.find(:psi=>'JoeSmith',:at_date => '2007-10-03') b.knows_person << a a.save b.save
Ruby and other dynamic languages allow us to go quite far in defining domain specific languages. But if we look at CTM, TMQL and TMCL, we can think about even more advanced programming language that natively supports various assertion contexts (time, source, etc.), metadata, information provenance and various inference/calculation mechanisms.