A critical analysis of string APIs: The case of Pharo

TL;DR

This paper critically analyzes the design of string APIs in Pharo and other languages, identifying criteria and tensions to inform future improvements and better understand string API design space.

Contribution

It provides a comprehensive analysis of Pharo's string API, compares it with other languages, and establishes criteria for evaluating string API design.

Findings

Pharo's String API is rich but feels cumbersome in practice.

Identified key criteria and tensions in string API design.

Provides a foundation for future string library redesign in Pharo.

Abstract

Most programming languages, besides C, provide a native abstraction for character strings, but string APIs vary widely in size, expressiveness, and subjective convenience across languages. In Pharo, while at first glance the API of the String class seems rich, it often feels cumbersome in practice; to improve its usability, we faced the challenge of assessing its design. However, we found hardly any guideline about design forces and how they structure the design space, and no comprehensive analysis of the expected string operations and their different variations. In this article, we first analyse the Pharo 4 String library, then contrast it with its Haskell, Java, Python, Ruby, and Rust counterparts. We harvest criteria to describe a string API, and reflect on features and design tensions. This analysis should help language designers in understanding the design space of strings, and will serve as a basis for a future redesign of the string library in Pharo.