API Design - Revision history

Checker at 07:30, 22 January 2007

2007-01-22T07:30:39Z

← Older revision		Revision as of 07:30, 22 January 2007
Line 23:		Line 23:
	<div style="font-weight:normal;font-size:66.67%">		<div style="font-weight:normal;font-size:66.67%">

	A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' as conventional programming wisdom states. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path. It's a great point.		A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' as conventional programming wisdom states. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path. It's a great point (and is Casey's ''Redundancy'' point above).

	</div></li>		</div></li>

Checker at 07:29, 22 January 2007

2007-01-22T07:29:31Z

← Older revision		Revision as of 07:29, 22 January 2007
Line 1:		Line 1:
	This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.		This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.

	----		<ol>
			<li style="font-weight:bold;font-size:150%">
			<div style="font-weight:normal;font-size:66.67%">

	[http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game\|Tech] on		[http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game\|Tech] on
Line 17:		Line 19:
	\|}		\|}

	----		</div></li>
			<li style="font-weight:bold;font-size:150%">
			<div style="font-weight:normal;font-size:66.67%">

	A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' as conventional programming wisdom states. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path. It's a great point.		A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' as conventional programming wisdom states. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path. It's a great point.

	~~----~~		</div></li>
			</ol>

	[[Category:Programming]]		[[Category:Programming]]

Checker at 14:23, 21 January 2007

2007-01-21T14:23:10Z

← Older revision		Revision as of 14:23, 21 January 2007
Line 18:		Line 18:

	----		----
	A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' ~~like people are used to thinking~~. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.		A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' as conventional programming wisdom states. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path. It's a great point.

	----		----

Checker at 14:22, 21 January 2007

2007-01-21T14:22:05Z

← Older revision		Revision as of 14:22, 21 January 2007
Line 21:		Line 21:

	----		----


			[[Category:Programming]]

Checker at 14:21, 21 January 2007

2007-01-21T14:21:13Z

← Older revision		Revision as of 14:21, 21 January 2007
Line 19:		Line 19:
	----		----
	A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.		A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.

			----

Checker at 14:21, 21 January 2007

2007-01-21T14:21:02Z

← Older revision		Revision as of 14:21, 21 January 2007
Line 1:		Line 1:
	This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.		This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.

	~~===1===~~		----

	[http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game\|Tech] on		[http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game\|Tech] on
	[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.		[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.

	Here's the executive summary:		Here's the executive summary:
	~~<table><tr><td valign="top">~~		{\|
			\|
	* Granularity - A or BC<br>Flexibility vs. simplicity		* Granularity - A or BC<br>Flexibility vs. simplicity
	* Redundancy - A or B<br>Convenience vs. orthgonality		* Redundancy - A or B<br>Convenience vs. orthgonality
	* Coupling - A implies B<br>Less is always better		* Coupling - A implies B<br>Less is always better
	~~</td><td~~ valign="top">		\|valign=top\|
	* Retention - A equals B<br>Synchronization vs. automation		* Retention - A equals B<br>Synchronization vs. automation
	* Flow Control - A invokes B<br>More game control is always better		* Flow Control - A invokes B<br>More game control is always better
	~~</td></tr></table>~~		\|}

	~~===2===~~		----
	A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.		A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.

Checker at 14:15, 21 January 2007

2007-01-21T14:15:59Z

← Older revision		Revision as of 14:15, 21 January 2007
Line 1:		Line 1:
	This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.		This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.

	===~~Casey~~===		===1===
	[http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game\|Tech] on		[http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game\|Tech] on
	[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.		[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.
Line 15:		Line 15:
	</td></tr></table>		</td></tr></table>

	===~~Jon~~===		===2===
	A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.		A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.

Checker at 14:15, 21 January 2007

2007-01-21T14:15:11Z

← Older revision		Revision as of 14:15, 21 January 2007
Line 6:		Line 6:

	Here's the executive summary:		Here's the executive summary:
			<table><tr><td valign="top">
	* Granularity - A or BC<br>Flexibility vs. simplicity		* Granularity - A or BC<br>Flexibility vs. simplicity
	* Redundancy - A or B<br>Convenience vs. orthgonality		* Redundancy - A or B<br>Convenience vs. orthgonality
	* Coupling - A implies B<br>Less is always better		* Coupling - A implies B<br>Less is always better
			</td><td valign="top">
	* Retention - A equals B<br>Synchronization vs. automation		* Retention - A equals B<br>Synchronization vs. automation
	* Flow Control - A invokes B<br>More game control is always better		* Flow Control - A invokes B<br>More game control is always better
			</td></tr></table>

	===Jon===		===Jon===
	~~Another~~ great insight on API and language design ~~was~~ from Larry Wall, the designer of Perl, but I heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.		A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.

Checker at 14:00, 21 January 2007

2007-01-21T14:00:57Z

← Older revision		Revision as of 14:00, 21 January 2007
Line 2:		Line 2:

	===Casey===		===Casey===
	[http://mollyrocket.com Casey] gave a good talk at [http://game-tech.com/ Game\|Tech] on		[http://mollyrocket.com Casey Muratori] gave a good talk at [http://game-tech.com/ Game\|Tech] on
	[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.		[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.

Checker at 14:00, 21 January 2007

2007-01-21T14:00:30Z

← Older revision		Revision as of 14:00, 21 January 2007
Line 1:		Line 1:
	This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.		This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.

			===Casey===
	[http://mollyrocket.com Casey] gave a good talk at [http://game-tech.com/ Game\|Tech] on		[http://mollyrocket.com Casey] gave a good talk at [http://game-tech.com/ Game\|Tech] on
	[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.		[https://mollyrocket.com/forums/viewtopic.php?t=215 Designing and Evaluating Reusable Components], which was really a talk on API design.
Line 11:		Line 12:
	* Flow Control - A invokes B<br>More game control is always better		* Flow Control - A invokes B<br>More game control is always better

			===Jon===
	Another great insight on API and language design was from Larry Wall, the designer of Perl, but I heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.		Another great insight on API and language design was from Larry Wall, the designer of Perl, but I heard about it from [http://number-none.com/blow Jon Blow] in [http://number-none.com/product/Lerp,%20Part%201/index.html this article]. You want your language or API to be ''diagonal'', not ''orthogonal'' like people are used to thinking. If you want to go from one place to another, you want to travel the shortest distance, not have to take the Manhattan path.