Scala offers incredible power and flexibility, providing features from many different languages and philosophies. This leads to a very diverse ecosystem and a wide range of possibilities for solving the same problems in very different ways.
As a developer trying to get results in the Scala world, the diversity in approaches of different libraries can be totally overwhelming, and the impedance mismatch between different libraries (and different developer preferences) often leads to confusion and inefficiency in development.
Among all of this, is what Dick feels to be the "lost art" of API design in the Scala community. Good APIs are small, focused and thoughtfully designed, isolating the developer using them from the underlying implementation whatever it is and however clever it might be. A good API should not require the user to care about the aspect they are using it for, after all, if they were really interested in that aspect, the chances are they would take control and write something themselves. Developers tend to get caught up in their enthusiasm and great ideas within their field of expertise and not consider that most people simply don't care about that and instead just want to get to their own area of interest.
In this talk Dick will examine advice from a number of sources, but primarily Josh Bloch, who has spent a great deal of time thinking about, designing and implementing APIs, APIs that we all still use to some degree even in Scala (e.g. the Java core libraries, Guava and many others). Josh writes APIs that everyone uses and most people don't notice. Dick will explore some of his advice, and some of his own and and you will learn from both about sound API design and its importance to the Scala ecosystem.
The primary mistakes Dick sees time and again are:
- Domain splurge, trying to solve every problem instead of focusing on the domain that really matters to your API
- Unintended usage, when the API is out in the wild, do people use it totally wrongly? People can be troublesome that way, but ultimately the problem is with your API
- Overemphasis on cleverness - just because you had a great idea, doesn't mean anyone else cares, or should care. If it makes things better, great, let people use it without beating them over the head with it
- Failing to consider how your solution will work in the bigger picture of the development space. Does your API play nice with others or are you creating a walled garden?
- Failing to update. An API is never "done" - it should live and evolve as you learn more (in a backwards compatible way whenever possible)
YOU MAY ALSO LIKE:
Why API Design Matters, and Why Yours Sucks! (and mine sucks too!)
Winner of the inaugural Phil Bagwell Award for Service to the Scala Community and with over twelve years of experience in Scala development as well as being a member of Java Posse, Dick Wall is a renowned speaker and trainer in the application of Scala. He is a Geographical Information System specialist using Scala at Hopper, Inc., CEO of Escalate Software and previous co-host on Scalawags Podcast. Dick has rediscovered his love of GIS combined with the power of the Scala type system, and wants to share his experiences of writing APIs to simplify that subject for others.