Button1, and depressing thoughts about complexity,elegance

[L505]

If one had let us say a Button... Button1, in a future application that used a language like Rel, then how could we elegantly model the button without resorting to the old object style coding which is supposedly bad, since it is not truly relational.

For example in current Object Oriented languages one uses:

Button1.Color
Button1.Left
Button1.Top

This is not truly relational above, but it is elegant and simple. In fact it may be the simplest and most elegant way to code/model a "button".

So I still see the need for objects or extended records (as Wirth calls them), or structures (as C calls them)- even if "tuples" will help us with other tasks, such as organizing repetitive similarly structured data. But I get the impression from Date's (and friends') books that the tuples will be almost a complete "replacement" for most of our objects that we sinfully use today. I think there should be some clear guidelines of where to draw the line. i.e. one does need to admit that our current objects are more elegant than tuples in cases were tuples would just be overkill! i.e. a button! I am fully open, though, and willing to accept criticism - maybe I am wrong here and you can model a button elegantly in a tuple. i.e. this is not an attack or flame on tuples, I want to hear what others think about solutions to problems in software using mostly tuples.

There are always compromises in models, since no model is perfect in all respects. The problem I see with tuples and the truly relational language.. is that it almost forces one to think that nearly everything could or should be in a tuple, when in fact there are sometimes more elegant spartan structures that suit the task (like poor objects that cannot be accessed relationally - but Aha! They can be accessed more directly! Which is sometimes needed, such as button1.color).

The syntax/notation required to construct a tuple is less elegant in some cases than an object. On the other hand, tuple syntax is more elegant in other situations. I.e. one model does not replace the other in all cases. Now one could modify the tuple syntax and make it easier to use in those situations where one wanted direct access to the tuple, but it is not just the syntax. It is also the fact that if we store a button1 and button2 in a database, it may be completely overkill and useless for our needs. Consider the OK/Cancel buttons.. well it is obvious that these buttons are... just buttons. I do not see any "relational advantages" for OK/Cancel buttons!

Sometimes we just need a fly swatter, not a complete shotgun to kill a fly. We may need arrays, which although are sinful.. are sometimes more elegant than a pure truly relational tuple. We may need objects, too? But how, if these relational languages of the future are going to replace our current object systems with a better truly relational... system? In C. Date and friends books, I still get the impression that he and friends think the truly relational language will mostly replace our current object systems. I have doubts since elegant solutions often require different models! And if elegant solutions do require different models, the bad news is that the more models a language supports, the more unmaintainable, monstrous, and large it gets.... such as ADA, compared to something more simple like Standard Pascal, C, or Rel which is crippled, but simple with one model focus!

Now Rel of course has not only tuples, but other features such as loops, abilities to create loose standalone integers not tied to a tuple, abilities to create arrays.. but what next? where do we draw the line? Shall rel also include objects too, i.e. records/structs that can be extended, without attaching themselves to a tuple? But then this will go against the recommendations of Date and friends which is to replace objects altogether, with the new object relational merge... the new truly relational way of coding. I cannot see it as a replacement - I see that both models have inelegance, and flaws - so in some cases one model will be more elegant, one will be less elegant for the situation at hand.

On the other hand, there are cases where people really are misusing objects and they should use tuples. There are also cases where people are misusing tuples though. Well consider that I want to store my sentences and paragraphs. I use a document, or a tuple? My periods, commas, where do they go? Well, sometimes an "essay" model, or document model, is better suited. Such as this long rambly posting here above

[Dave]

As simplistic answer -- offered to spur further discussion rather than provide a definitive solution -- is that there is nothing, to my mind, that precludes providing "conventional" object-oriented constructs like classes, objects, inheritance and polymorphism strictly as a facility for organising run-time code, as long as these cannot be stored in the database. This could provide the means to define and manipulate (for example) user-interfaces (buttons and the like) in a familiar manner.

I think a strong distinction needs to be drawn between using OO as a mechanism for organising run-time code (which may be good) vs using OO to define types and construct databases, which is bad.

Another simplistic answer, offered under the same basis, is that the specialisation-by-constraint type system defined by Date & Darwen may well offer the same (if not more) expressiveness as "conventional" object-oriented programming but (obviously) operating under a different model. This is an area in need of further exploration -- the empirical evaluation of which will be conducted when the Date & Darwen type system is fully implemented in Rel. I currently have a student working on implementing this.

[L505]

I think possibly that a compiler plug in, or interpreter plug in might be a way to work the problem out. Take an existing compiler, or language, and plug in industrial D (embed it right in the code using some special comment escape system or similar)

Code: Select all

 /* 
  START INDUSTRIAL D   
  ....
  ....
  END INDUSTRIAL D
*/ 

However, trying to get all current existing compiler and interpreter developers (and commercial companies) to add a plug in system to their compilers will prove tough. Maybe there will need to be a revolution - the first language that offers some built in (or plugged in) way of using an Industrial D, will have first dibs on grabbing the attention (and money, if commercial) of people in need of a rigorous database (i.e. everyone - if only they knew). As more and more compiler/interpreter developers understand the importance of Industrial D, slowly, maybe in 250 years, or 20 years, depending on how we evolve... more and more compilers will ship with industrial D abilities. I think it will be a slow process realistically, but then again computers and computing science have the ability to evolve quickly.

Embedding the language could also prove difficult or it could turn ugly, as we've seen in PHP for example when embedding code into HTML. Let's hope it is not so ugly or difficult. I am trying to dream up a way to for example share variables with the main language (say C++, Java, whatever) without resorting to below like in PHP or ASP

Code: Select all

<html><? ugly embedded php ?> </html>

Code: Select all

<html><% ugly embedded alternative %></html>

Code: Select all

{ 
  //.. some C code
  int foo;
  do_something();
  foo = 5;
 <?  // industrial D code here.  foo is available for access in D, from C, since it is shared. somehow
     WRITELN foo;
     VAR i INTEGER;
     DO i := 1 TO foo  // again foo is available from C, in D
         OUTPUT i;
     END;
 ?>
  something_else();
}