Declarative Programming - Revision history

JaroslavTulach: /* Have You Ever Wondered...? */

JaroslavTulach — Thu, 25 Mar 2010 03:14:21 GMT

Have You Ever Wondered...?

←Older revision		Revision as of 03:14, 25 March 2010
Line 1:		Line 1:
	== [[Have You Ever Wondered]]...? ==		== [[Have You Ever Wondered]]...? ==

-	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 including XML or [[PropertyFiles]].	+	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 including [[XML]], [[PropertyFiles]] or other [[protocols]].

	== Less is Better ==		== Less is Better ==

JaroslavTulach at 08:21, 15 September 2009

JaroslavTulach — Tue, 15 Sep 2009 08:21:38 GMT

←Older revision		Revision as of 08:21, 15 September 2009
Line 10:		Line 10:

	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.		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.
		+
		+	== Documenting Declarative APIs ==
		+
		+	{{:DocumentDeclarativeAPI}}

JaroslavTulach at 12:48, 9 May 2009

JaroslavTulach — Sat, 09 May 2009 12:48:35 GMT

←Older revision		Revision as of 12:48, 9 May 2009
Line 10:		Line 10:

	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.		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/>~~

JaroslavTulach: /* Have You Ever Wondered...? */

JaroslavTulach — Tue, 30 Dec 2008 12:40:36 GMT

Have You Ever Wondered...?

←Older revision		Revision as of 12:40, 30 December 2008
Line 1:		Line 1:
	== [[Have You Ever Wondered]]...? ==		== [[Have You Ever Wondered]]...? ==

-	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 including XML or [[PropertyFiles]].

	== Less is Better ==		== Less is Better ==

JaroslavTulach: /* Less is Better */

JaroslavTulach — Sun, 07 Dec 2008 12:51:12 GMT

Less is Better

←Older revision		Revision as of 12:51, 7 December 2008
Line 5:		Line 5:
	== Less is Better ==		== 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.	+	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, create general proxies that delay loading of the actual implementations, 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. 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.		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.

JaroslavTulach: /* Less is Better */

JaroslavTulach — Fri, 05 Dec 2008 14:34:02 GMT

Less is Better

←Older revision		Revision as of 14:34, 5 December 2008
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 ~~over~~ regular execution of plain code.	+	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/>

JaroslavTulach: /* Have You Ever Wondered...? */

JaroslavTulach — Fri, 05 Dec 2008 14:29:52 GMT

Have You Ever Wondered...?

←Older revision		Revision as of 14:29, 5 December 2008
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.

JaroslavTulach: /* Have You Ever Wondered...? */

JaroslavTulach — Sun, 17 Aug 2008 20:32:23 GMT

Have You Ever Wondered...?

←Older revision		Revision as of 20:32, 17 August 2008
Line 1:		Line 1:
-	== Have You Ever Wondered...? ==	+	== [[Have You Ever Wondered]]...? ==

	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.

JaroslavTulach at 22:12, 13 August 2008

JaroslavTulach — Wed, 13 Aug 2008 22:12:39 GMT

←Older revision	Revision as of 22:12, 13 August 2008
Line 1:	Line 1:
	+	== Have You Ever Wondered...? ==

	+	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.

Apidesign: Removing all content from page

Apidesign — Sat, 14 Jun 2008 06:07:05 GMT

Removing all content from page

←Older revision		Revision as of 06:07, 14 June 2008
Line 1:		Line 1:
-	~~'''Done: 17ef6cbd11b0'''~~

-	~~s/Turning Machine/Turing Machine~~
-
-	~~Put in an explicit example of XML declarative (e.g. NB menus), to make clear how the implementation code builds the menus and how the module exposes a very minimal and high-level SPI to client modules~~
-
-	~~--[[User:RichUnger\|RichUnger]] 22:40, 10 April 2008 (UTC)~~
-
-	* Page 207: As advised in part I, "Empiristic" should be "empirical."
-	* Page 208: Since you discussed in the testing section how tools can help prevent errors, it might be worth mentioning here that the merged contents of the system filesystem can be viewed right from the IDE at development time (Important Files -> XML Layer -> This layer in context). I can say that number of errors related to malformed layer files have decreased significantly on my team since this tool was introduced and that when errors do occur, they're now much more easily found because of this tool.
-	** I'd like to discuss even automatic validation a bit more - if you execute ant -f nbbuild/build.xml commit-validation you will get even compile time errors if your layers are not correct - however that is too much for the book. Let's leave it for wiki.
-
-	~~--[[User:TomWheeler\|TomWheeler]] Sun Apr 13 16:49:16 CDT 2008~~

←Older revision		Revision as of 14:34, 5 December 2008
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 ~~over~~ regular execution of plain code.	+	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/>