The Future
From APIDesign
Line 10: | Line 10: | ||
{{#ev:youtube|3WLTsb6okDw}} | {{#ev:youtube|3WLTsb6okDw}} | ||
+ | |||
However ski producers have caught up and modern [[wikipedia::skiing|carving skis]] make the [[wikipedia::Centrifugal_force|centrifugal force]] available for almost everyone. Good tools help wider audience to do the right job. | However ski producers have caught up and modern [[wikipedia::skiing|carving skis]] make the [[wikipedia::Centrifugal_force|centrifugal force]] available for almost everyone. Good tools help wider audience to do the right job. | ||
Line 20: | Line 21: | ||
{{:Good_Name}} | {{:Good_Name}} | ||
+ | |||
+ | [[Category:Video]] |
Current revision
Have You Ever Wondered...?
Do we need some changes to our programming languages, tools to build APIs more easily? Some changes would be nice, however they are not necessary. It is possible to write good APIs in C, in Java even now. It is just not very clueless right now. One needs to thing about the evolution issues related to API too much. As the Epilogue suggests, it would be really more simpler for all of us, if our systems were designed with evolution in mind. I hope this book will provoke discussion of how to do it.
Good Tools Help
The epilogue also mentions one parallel between programming and winter skiing.
In 1997, when I first took off my skis and jumped on snowboard, it was really hard to really enjoy effect of centrifugal force while riding down the hill. Too bad, as the force is one of the most significant reasons why people love to ride motorbikes, enjoy carousels, skiing or snowboarding. At that pre-carving age, just few people managed to turn without sliding. The skis of that time were just too poor tools. At that time, it was much easier to practise that style while snowboarding:
However ski producers have caught up and modern carving skis make the centrifugal force available for almost everyone. Good tools help wider audience to do the right job.
The same parable applies to programming. Better languages, better coding practices, better libraries and better API Design Patterns make tough tasks, originally available to few chosen individuals, available to masses.
Only if things are easy, we can use them in cluelessness mode. Often that does not mean we have to change the principles (for example the physical forces remain unchanged), it is enough to understand them and create tools that exploit them in deeper ways. Good tools make everything easier.
Good Names Help as Well
Good Name is essential aspect of most of good technologies. It is logical, as the name is often the first thing your (potential) users are confronted with. And first impression is important, isn't it?
Also Good Name becomes a technology's handle. It is the thing people associate your technology with. If widely known, just like names of design patterns, then it is enough to say that name and whole, even complex concepts, are described at once. Good Names are important.
In one section of TheAPIBook's epilogue I was searching for a Good Name for the API Design Methodology advocated on this site. I played with various combinations of words like highly, effective, structured, rational, etc. When doing that I was inspired by following sketches where John Bird and John Fortune explain Good Name importance:
...wait for 5:50+ to hear about High-Grade Structured Credit Strategies Enhanced Leverage name and its importance... hear the quote I'd buy anything, if it enhanced... or get more, if 529s is not enough...
At the end I decided to use other Good Name, but I cannot resist to confess what motivated that one paragraph. I still find the combination of highly, effective, rational, unified and similar terms very amusing. Especially as I own few shares of an investment fond with such Good Name and very poor performance.
Good Names are important. What name would you give to API Design methodology after reading TheAPIBook? Same as did I? Different?
<comments/>