'. '

Declarative Programming

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Have You Ever Wondered...?)
(Have You Ever Wondered...?)
Line 2: Line 2:
You [[Runtime Aspects of APIs|have just scared us]] with runtime implications of APIs, is there a way to minimize their impact? Is there a way to prevent race conditions, deadlocks, etc.? Yes, as far as I know there are two ways. Either prevent shared access to data, objects, structures, resources or allow it. The [[Declarative Programming|chapter 12]] explains how to do that with a little help of [[Declarative Programming]]. [[Declarative Programming]]!? Is there something like that? Well, that is indeed good question, which the [[Declarative Programming|chapter 12]] analyses as well and it even suggest some good forms to use for this style of APIs.
You [[Runtime Aspects of APIs|have just scared us]] with runtime implications of APIs, is there a way to minimize their impact? Is there a way to prevent race conditions, deadlocks, etc.? Yes, as far as I know there are two ways. Either prevent shared access to data, objects, structures, resources or allow it. The [[Declarative Programming|chapter 12]] explains how to do that with a little help of [[Declarative Programming]]. [[Declarative Programming]]!? Is there something like that? Well, that is indeed good question, which the [[Declarative Programming|chapter 12]] analyses as well and it even suggest some good forms to use for this style of APIs.
 +
 +
== Less is Better ==
 +
 +
The ''less flexible'' a declarative approach is, ''the better''. The reason seems to lie in the fact that due to restricted expressiveness one can make more assumptions about the declarations and can optimize them, cache them, etc. If the declarative registration is as power as [[wikipedia::Turing Machine|Turing Machine]] - e.g. as powerful as regular programming languages like C, Java, Perl, and all the others, then one cannot optimize much, and often needs to resort to actual execution of the registered code snippets.
 +
 +
This is caused by the presence of [[wikipedia::Halting Problem|Halting Problem]]: there are programs that one cannot analyse to find out what they do, without executing them. And in such situations you can give up on any caching, or optimizations.
 +
 +
That is why, if one wishes to worship declarative programming inside existing imperative languages, it seems very important to make the declarative syntax less powerful than [[wikipedia::Turing Machine|Turing Machine]]. Only then it can really bring some benefits over regular execution of plain code.

Revision as of 14:29, 5 December 2008

Have You Ever Wondered...?

You have just scared us with runtime implications of APIs, is there a way to minimize their impact? Is there a way to prevent race conditions, deadlocks, etc.? Yes, as far as I know there are two ways. Either prevent shared access to data, objects, structures, resources or allow it. The chapter 12 explains how to do that with a little help of Declarative Programming. Declarative Programming!? Is there something like that? Well, that is indeed good question, which the chapter 12 analyses as well and it even suggest some good forms to use for this style of APIs.

Less is Better

The less flexible a declarative approach is, the better. The reason seems to lie in the fact that due to restricted expressiveness one can make more assumptions about the declarations and can optimize them, cache them, etc. If the declarative registration is as power as Turing Machine - e.g. as powerful as regular programming languages like C, Java, Perl, and all the others, then one cannot optimize much, and often needs to resort to actual execution of the registered code snippets.

This is caused by the presence of Halting Problem: there are programs that one cannot analyse to find out what they do, without executing them. And in such situations you can give up on any caching, or optimizations.

That is why, if one wishes to worship declarative programming inside existing imperative languages, it seems very important to make the declarative syntax less powerful than Turing Machine. Only then it can really bring some benefits over regular execution of plain code.

buy