Scala is one of the most feature rich, expressive and flexible languages around at present. It offers more ways to solve a problem than virtually any other language around, since it mixes Object Orientation, Functional Programming, Static Typing and much more. The down side of all this power and functionality is all too commonly observable in the libraries available for Scala. Many libraries forget the audience for whom they are being written, and instead expose details like the underlying model (which may be very clever, but should mostly be orthogonal to the resulting API and certainly should not directly affect it). To put it another way, if your database structure dictates your user interface or web page, something is wrong with the design of your site (too many failed model driven design projects back this assertion). In the same way, APIs that are dictated by the innermost workings of your library have likely failed to take into account the needs of the user. While writing SubCut, and further enhancing the feature set for SubCut 2.0, I learned many lessons about the advantages of teasing apart your semantic model from your library API. This is not a talk about SubCut, but a talk about some of the techniques I used to provide what I believe is the smallest, simplest and most streamlined API, while hiding most of the details of the implementation. I can also speak to the advantage of that approach with the enhancements made in SubCut 2.0 - the small targeted API let me change much about the inner workings, and while the API was affected for some new features, the new features were always added in a way that kept the API familiar to current users, and more importantly provided an easy, often non-breaking transition path.

No outline is available