An ode to the library, or, why language matters a lot when you’re talking to developers.
Today, February 14th, is Library Lover’s Day. A day dedicated to book lovers everywhere, when we recognize libraries for the incredible work they do within our communities globally. I am a huge reader, and a huge fan of the library, and so when I saw this date in the calendar, I immediately knew what it meant. It also got me thinking about something else. For developers, a library has a completely different meaning. Referring to compiled code that acts as a “helper” to facilitate access to functions and methods, a library is a cornerstone of modern software design.
Ansys has hundreds of libraries within our portfolio, both open source, and those that are part of our core products, in many languages. This may surprise a casual reader of our documentation because we do not consistently refer to them as libraries. We instead call everything that provides any interface an “API”. While this is technically true, it is also extremely confusing to developers “in the wild” who have an expectation of what an “API” is in the modern software space. This is true of libraries, SDKs, services, platforms, and many other tech words too, and it got me thinking of how best to explain what is what, and why it matters so much to have consistent language.
True Vs. Precise
Take a look at this picture:
If I asked you what is in the pictures you would probably say a train, space shuttle, car, and truck. You could also say that these are all vehicles, or forms of transportation. Both statements are true, but only one is precise and it is the precision that creates or removes confusion. Calling everything an API is the same as calling all of these “vehicles” – it is 100% true, but not even remotely precise. If I say to a developer, “I have an API”, they will almost certainly attach meaning to that word, and then if I show them documentation for a C++ library or SDK, they are going to be very confused. It’s because while I wasn’t inaccurate, I also wasn’t precise, and that’s where the confusion lies.
“Check out this API” – “Lol-wut?”
Companies that are good at software make standardization of their terms a priority because as the company grows and adds new products to its portfolio, you cannot handle the massive confusion that comes from someone misnaming something. A service in the Microsoft common vernacular is anything you can connect to that provides functionality without the explicit need of a UI. This could be a cloud service, a service running under Windows, or even a service like databases or SMTP. Without that level of precision, anything could be called a service, and thus they have helped remove confusion by exercising precision. Is it more work for them on the front-side to keep naming and language precise? Sure, it is! Is it a better experience for their users who know what to expect when someone says they are getting a “service”? Very much so.
Within the developer program at Ansys we are working hard to standardize our naming conventions across products because it creates too much confusion not to! This process is not immediate and will take time as we work with our product teams and documentation teams, all of whom have huge workloads as is. It is imperative to help solidify this standard for you, our ultimate users. And we have a LOT of APIs, not just libraries, but scripting interfaces, actual REST/gRPC APIs, and custom and esoteric API definitions as well that are hyper-specialized for a specific area of physics.
What I hope is that the humble library has its day as a fully fledged member of the pantheon of the ecosystem. Not “just another API”, but the highly specialized and beautiful API that it deserves to be recognized as! That is my wish for Library Lover’s Day 2024 – I love our libraries and I hope that we can give them the pride of place they deserve!