Declarative Programming
From APIDesign
(→Have You Ever Wondered...?) |
(→Less is Better) |
||
| Line 7: | Line 7: | ||
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. | 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. | + | 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. If your program is written in [[Java]] and your ''declarations'' are in [[JavaScript]] you are unlikely to get much benefits - you need to interpret and execute all the [[JavaScript]] snippets as they can provide different results on Monday, or Tuesday or on first or second execution, etc. [[JavaScript]] is just too powerful language for declarations. |
| - | 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 | + | 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 and optimizations not available with regular execution of plain code. |
| + | |||
| + | <comments/> | ||
Revision as of 14:34, 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. If your program is written in Java and your declarations are in JavaScript you are unlikely to get much benefits - you need to interpret and execute all the JavaScript snippets as they can provide different results on Monday, or Tuesday or on first or second execution, etc. JavaScript is just too powerful language for declarations.
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 and optimizations not available with regular execution of plain code.
<comments/>
Follow
