Using structural relationships to facilitate api learning
Bibliographic record
Abstract
Application Programming Interfaces (APIs) allow software developers to reuse code libraries, frameworks, or services without the need of having to implement relevant functionalities from scratch. The benefits of reusing source code or services through APIs have encouraged the adoption of APIs as the building blocks of modern-day software systems. However, leveraging the benefits of APIs require a developer to frequently learn how to use unfamiliar APIs — a process made difficult by the increasing size of APIs, and the increase in the number of APIs with which a developer has to work. In this dissertation, we investigated some of the challenges developers encounter when working with unfamiliar APIs, and we designed and implemented new programming tools to assist developers in learning how to use new APIs. To investigate the difficulties developers encounter when learning to use APIs, we conducted a programming study in which twenty participants completed two programming tasks using real-world APIs. Through a systematic analysis of the screen captured videos and the verbalizations of the participants, we isolated twenty different types of questions the programmers asked when learning to use APIs, and identified five of the twenty questions as the most difficult for the programmers to answer in the context of our study. Drawing from varied sources of evidence, such as the verbalizations and the navigation paths of the participants, we explain why the participants found certain questions hard to answer, and provide new insights to the cause of the difficulties. To facilitate the API learning process, we designed and evaluated two novel programming tools: API Explorer and Introspector. The API Explorer tool addresses the difficulty a developer faces when the API types or methods necessary to implement a task are not accessible from the type the developer is working with. API Explorer leverages the structural relationships between API elements to recommend relevant methods on other objects, and to identify API types relevant to the use of a method or class. The Introspector tool addresses the difficulty of formulating effective queries when searching for code examples relevant to implementing a task. Introspector combines the structural relationships between API types to recommend types that should be used together with a seed to search for code examples for a given task. Using the types recommended by Introspector as search query, a developer can search for code examples across two code repositories, and in return, will get a list of code examples ranked based on their relevance to the search query. We evaluated API Explorer through a programming study, and evaluated Introspector quantitatively using ten tasks from six different APIs. The results of the evaluations suggest that these programming tools provide effective support to programmers learning how to use APIs.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.004 | 0.050 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.004 | 0.012 |
| Open science | 0.002 | 0.005 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.011 | 0.003 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".