| (7 intermediate revisions by the same user not shown) | |||
| 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 | ||
[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: | ||
{| | |||
| | |||
* 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 | ||
|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 | ||
|} | |||
</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 (and is Casey's ''Redundancy'' point above). | |||
</div></li> | |||
</ol> | |||
[[Category:Programming]] | |||
Latest revision as of 01:30, 22 January 2007
This is really just a miscellaneous collection of thoughts and links right now, not a full fledged article on API design.
-
Casey Muratori gave a good talk at Game|Tech on Designing and Evaluating Reusable Components, which was really a talk on API design.
Here's the executive summary:
- Granularity - A or BC
Flexibility vs. simplicity - Redundancy - A or B
Convenience vs. orthgonality - Coupling - A implies B
Less is always better
- Retention - A equals B
Synchronization vs. automation - Flow Control - A invokes B
More game control is always better
- Granularity - A or BC
-
A great insight on API and language design comes from Larry Wall, the designer of Perl, but I first heard about it from Jon Blow in 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).