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:
- Advanced Scala with Dick Wall (in London on 9th - 11th December 2019)
- Scala eXchange London 2019 (in London on 12th - 13th December 2019)
- Unsung Heroes: Less Fashionable Patterns in Scala (SkillsCast recorded in December 2014)
- Lightbend Akka for Scala - Professional (in London on 11th - 12th November 2019)
- Scalax2gether Community Day 2019 (in London on 14th December 2019)
- Code Kata: Yilin Wei - Optics with Monocle (in London on 22nd October 2019)
- Keynote by Konrad Kokosa: What’s New in .NET Core 3.0 and .NET 5.0 for Performance and Memory-Aware Folks? (in London on 29th October 2019)
- Going Multicloud with Serverless (SkillsCast recorded in October 2019)
- Abstract Data Types In The Region Of Abysmal Pain, And How To Navigate Them (SkillsCast recorded in September 2019)
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.