sample-programs and the case for keeping a hello world in every language
Sample Programs in Every Programming Language
At a glance
- What is it?
- The sample-programs collection grew out of a 100 Days of Code challenge into a repository of sample programs in nearly every programming language, kept alive by a tooling layer that automates the boring parts of adding a language. Its value to a reader is the curation, and its weakness is that the programs themselves are deliberately trivial.
- Who is it for?
- sample-programs suits a developer learning an unfamiliar language who wants the smallest working program in it, or a teacher who wants a canonical example per language without writing them, since the collection is exactly that and the tooling keeps the corpus consistent. It does not suit a reader looking for worked examples of real problems, because the programs are minimal by design.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly ALGOL, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What began as a challenge became a corpus
The sample-programs repository is described as a collection of sample programs in every programming language, and the origin story is in the project description itself.
What began as a simple 100 Days of Code challenge has expanded into a fun project, and within the repository you will find a growing collection of sample programs in just about every programming language to date. The primary language recorded for the repository is ALGOL, which is a good indication of the joke and of the ambition at the same time: the language whose name became the generic term for the whole field sits at the centre of a set of hundreds of others.
The project is run by one person, Jeremy Grifski, as part of a website called The Renegade Coder, and the support section is entirely about supporting that site, through a Patreon, a newsletter, PayPal, a request to turn off ad blocking when reading, and an invitation to join the community on Discord.
The licence is MIT, the homepage is sampleprograms.io, and the default branch is main, with the last push to the repository on 2026-10-20.
The scale is not a guess. The release tags tell the story: a 150 Language Test Release in December 2023, a 1,000 Code Snippet Release in January 2025, and a 1,500 Code Snippet Release in April 2026.
The tooling is the actual engineering in this repository
A collection of a thousand and a half snippets across a hundred and fifty languages has a maintenance problem, and the interesting part of this repository is the answer.
The project declares a small set of Python dependencies in its pyproject.toml, and they are all tooling rather than runtime:
dependencies = [
"ronbun (>=0.11.1,<0.12.0)",
"glotter2 (>=0.17.0,<0.18.0)",
"pyyaml (>=6.0.3,<7.0.0)",
]Glotter is the project that harvests sample programs from all over the internet, and glotter2 is its successor, credited in the special thanks to two of its developers. Ronbun is a configuration format library, and pyyaml handles the repository's own YAML configuration. The package metadata is set to package-mode false, which is the Poetry setting that says this is not a distributable library but a collection with tooling around it.
The top-level tree confirms the split. There is a scripts/ directory for the automation, a test/ directory with a pytest configuration in the pyproject.toml, a repo-config.yml and a .glotter.yml for the collection and harvesting configuration, an archive/ directory for programs that have been retired, and the .github/ directory holding the contributing document, the code of conduct, the licence and the project summary referenced by the project metadata.
So the repository is a harvesting pipeline with a version-controlled output, and that is a much more interesting engineering artefact than the snippets themselves.
Contributions go through a process, not a pull request
The project description is explicit about how new material arrives, and it is not the usual open source route.
There is a list of projects currently accepting code snippets, linked separately from the main description, and the contributing document is the thing the description tells you to read to get up to speed quickly. The template repository is offered as a way to create your own collection rather than contributing to this one, and there is a series of articles about what is happening in the repository.
That structure is a reasonable response to the scale. With a hundred and fifty languages and a thousand and a half snippets, a pull request approach would drown the maintainer in near-identical changes. Routing contributions through a per-project list and a defined format means that adding a language is a deliberate piece of work with a known shape, and the tooling can then verify the result.
The community links support that picture. There is a Discord invite, a code of conduct, and a news series that documents the repository's history. The project also credits a set of collaborators who built the tools the collection depends on, including the authors of Glotter, Glotter2, the in every language repository and Baklava, each with a link and a note of what they built.
The maintainers list in the project metadata names nine people as major contributors along the way, and the initiator is listed separately.
Why a hello world in every language is worth keeping
The obvious objection to this repository is that a hello world program tells you almost nothing, and that is true of the individual snippet and false of the collection.
What a per-language hello world gives you is the smallest complete program in that language, which is not the same as the smallest program you can write. It shows you the entry point, the output mechanism and the build or run command for that language, and it shows you what the ecosystem looks like today for a language that may have changed substantially since you last used it.
The collection also serves as a compatibility check. Because the programs are executed as part of the test suite, a language that has changed its entry point, its package layout or its toolchain fails visibly rather than rotting quietly in a folder.
And the archive/ directory tells you something about the longevity question. Languages have been added and, apparently, removed, and the archive keeps the old ones. That is a useful piece of history for anyone who wants to know what a language's entry point looked like five years ago.
The repository also leans into the community aspect. The topics include collection, discord, polyglot, programming-languages and snippets, and the primary language being ALGOL is a small joke that a lot of people get.
The last thing worth noting is the tone of the project's own description, which describes a growing collection of sample programs in just about every programming language to date. Just about is doing careful work there, and it is the honest framing for a corpus that is finite and always will be.
Where sample-programs is the wrong place to look
The first case is learning a language properly. A hello world shows you the shape of a program and nothing about the parts that are hard. Error handling, generics, concurrency, package management and the standard library are where a language distinguishes itself, and none of that is in scope here.
The second case is finding a reference implementation. If you want to know how to parse a CSV in some language, this collection will not have it, and the minimalism that makes the corpus valuable is exactly what makes it useless for that.
The third is using it as a benchmark or a comparison. The programs are not written to be comparable, they are written to be minimal, and a timing comparison between a language's hello world and another's says nothing about performance.
The fourth is a contribution model. If you maintain a language implementation and want your canonical example in the collection, the process is the contributing document and the list of projects currently accepting snippets, not a pull request. That is a deliberate choice by the maintainer and a reasonable one at this scale, but it does mean an unsolicited pull request is not the way in.
There is also a question about the harvest itself, which the tooling answers openly. Glotter collects sample programs from public sources, and the collection inherits the licensing and quality characteristics of what it finds. The MIT licence covers the repository, but the provenance of individual harvested snippets is a separate matter and one that a reader using these as a reference should be aware of.
Editorial conclusion
sample-programs suits a developer learning an unfamiliar language who wants the smallest working program in it, or a teacher who wants a canonical example per language without writing them, since the collection is exactly that and the tooling keeps the corpus consistent. It does not suit a reader looking for worked examples of real problems, because the programs are minimal by design. Before you rely on it, read the contributing document rather than the index, since the project accepts new snippets through a process rather than pull requests at random, and note that the last push was on 2026-10-20 with a version of 2026.5.30 in the project metadata.
Frequently asked questions
What is the sample-programs repository?
It is a collection of sample programs in nearly every programming language, grown out of a 100 Days of Code challenge by Jeremy Grifski as part of The Renegade Coder. The release tags show the scale, with a 1,500 Code Snippet Release in April 2026 and a 150 Language Test Release in December 2023.
How do I contribute a new language or snippet to sample-programs?
Through the contributing document rather than a pull request, and by checking the list of projects currently accepting code snippets. The project also publishes a template repository so you can run your own collection instead of contributing to this one.
What tooling does sample-programs use to manage the collection?
A small set of Python dependencies: glotter2, the successor to Glotter, for harvesting sample programs from public sources, ronbun for configuration, and pyyaml for the repository's own configuration. The project metadata sets package-mode false, so the repository is a collection with tooling around it rather than a distributable library.
How is sample-programs tested?
There is a test/ directory with pytest configured in the project metadata, and the programs are executed as part of the suite, which is why a language whose entry point or toolchain changes fails visibly rather than rotting in its folder.
Can I build my own collection of sample programs?
Yes, a template repository is provided for that purpose, and the project description links it as a way to create your own collection. Several of the maintainers and collaborators built their own collections, including the in every language repository and Baklava, both credited in the special thanks.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/therenegadecoder-sample-programs)Was this useful?