See also: Avian Visitors - https://news.ycombinator.com/item?id=48343424 - May 2026 (20 comments)
I made a programming language!
I call it AttaLambda.
The idea is this: a usable Lisp-shaped language where all the meaningful computation is done in untyped lambda calculus. Logic, arithmetic, data structures, control flow, even the types — all untyped lambdas. A small, explicit Racket layer sits at the boundary to handle the outside world, plus some macros for syntactic sugar.
This is its story:
A couple years ago, I wanted to play with untyped lambda calculus and go beyond where tutorials usually stop. They show booleans, numbers, arithmetic, maybe the Y-combinator — and then stop. I wanted them to keep going.
So I started a project called All The Lambdas. Using Racket set to lazy, I used only one Racket construct for actual computation — lambda — and built integers, rationals, lists, binary digit-list number encodings, search algorithms, and more.
Then I found Functional Programming Through Lambda Calculus by Greg Michaelson. In it, Michaelson sketches the bones of a language built in untyped lambda calculus, including a type system where typed objects are themselves pair functions containing a type tag and value.
I found that intriguing and implemented and extended the idea, still entirely with untyped lambdas. I don't have a background in programming language theory, so I was figuring it out as I went.
Then I stopped tinkering with it for a while.
Recently I came back and thought: why not turn this into a real usable language with the help of coding agents? I reused most of All The Lambdas as the foundation.
Thus AttaLambda was born.
Some additional details:
* Rat, its number type, uses binary digit-list encodings instead of Church numerals, so numbers scale with their number of binary digits rather than their value
* errors are lambda-encoded values, not Racket exceptions, and propagate through the language like ordinary data
* the Racket host only performs irreducibly external operations; even things like HTTP parsing, routing, and response construction stay in the pure lambda world
* recursion uses lambda-calculus recursion: no loops or true self-reference, just the Y-combinator underneath
* automated purity checks catch accidental cheating, like native computation leaking into the pure parts
* syntax like multi-argument lambdas, let, cond, and list is just macro sugar that reduces to unary lambdas and application
A couple code examples: (short of print, every single thing here reduces to unary untyped lambdas)
Factorial:
#lang attalambda
(rec factorial n =
(cond
((eq n 0) 1)
(else (mult n (factorial (sub n 1))))))
(print (factorial 10))
3628800
#lang attalambda
(print
(reduce add 0
(map (lambda (n)
(unwrap-ok (div 1 n)))
(range 1 8))))
363/140
Download: https://github.com/kserrec/attalambda/releases/tag/v0.7.0
Code: https://github.com/kserrec/attalambda
Original All The Lambdas: https://github.com/kserrec/all_the_lambdas
The original startup website generator by Tiff Zhang and Mike Bradley landed on Hacker News in April 2015 (https://news.ycombinator.com/item?id=9427856) and has been one of my favorite little novelties of that era ever since. It perfectly captures the saturated colors, cliché hero shots, gimmicky names, buzzword-heavy slogans, and proudly hirsute team photos of the time.
A lot has changed since then, so I thought it would be fun to make a contemporary remake: https://restarted.io/
By default you get the minimalist aesthetic and clean-cut faces of 2026. The classic 2015 look is still available — just click the link at the bottom of the page or change the “z” parameter in the URL to the more familiar “s”. The universe of partner sites and competing startups is just as expansive as it ever was.
The original site is entirely client-side and requires downloading all of the data tables locally. It leans on a mix of jQuery 1.11.2, Bootstrap 3.3.2, and Font Awesome 4.3.0, and if you view the source, it instantly gives away all of its secrets. For restarted.io I replaced all of that with a server-side renderer written in Go, so this time view-source tells you nothing. There are many Easter eggs in there — see how many you can find before I write them up.
My original goal was to stay faithful to the 2015 appearance, and that turned out to be a technical adventure. The original's sine-based random number generator is... the worst, and different implementations of sine give different results. The eventual solution was to extract the exact sine function from Chrome’s V8 engine, as vendored C behind cgo and as a line-by-line Go port that keeps cgo optional, so the seeds and results line up the way they used to. Both are checked against V8’s own test cases.
Then I discovered a bug in the original code that made half of its vocabulary unreachable — the first half of the verb table and the second half of the noun table, exactly complementary, so nothing about the output ever looked truncated. My goal then shifted from remaking the generator as it was in 2015 to remaking the site as the authors intended it to be in 2015.
Over the years several people asked for their photos to be removed, so the remake instead draws from a broad pool of era-appropriate AI-generated profiles. A perceptual hash helps keep everyone looking distinct, and there’s a bit of extra care to make sure the Wang Fangs of the world don’t appear as Irish lasses.
The hero image pool is much larger now, and all the old Rio de Janeiro shots have been retired, though you’ll still recognize plenty of the 2015 photos.
Have fun poking around!
Buckle your seatbelt, secure your tray table, and open your window shade. Now you can simulate flying anywhere in the world as a commercial passenger, from takeoff to touchdown. Terrain, weather, and realtime sun position included. Don't worry, the latest release now features legs, so you can get up and go to the bathroom on longer flights. Enjoy!
Author here. I'm trying to visit every country and I've been to 158 so far.
Before I decide where to travel, I'd ask a local friend which season to avoid, or open up dozens of browser tabs on climate data to figure out what the place is like in a given month.
Climate data still miss things. Cancun in September looks great on paper, with 31°C and 10 hours of sun, but it's hurricane season and the beaches can be covered in seaweed.
Typical info that locals would know, which can also be captured as static data.
So I built SeasonMap to answer "when should I go to <place>?"
What you can do:
- Pick a travel style (city walk, beach, hiking, skiing, max sun, low humidity, etc.) and see every place ranked on a map
- See what's in season and what to avoid, and why: monsoon, hurricanes, extreme heat, bad air, peak crowds
- Filter destinations by temperature, rainfall, sunshine, air quality and hazard seasons
- Open a place to see its whole year: month by month weather, events (festivals, whale watching, cherry blossom), crowd levels, practical notes like scams, and traveller anecdotes summarized by AI with links to the sources
Data Source & how I made it: - The climate data is ERA5 normals via Open-Meteo (2016–2025), corrected with NOAA station data where available.
- Events, hazards and traveller notes were researched and by AI agents, and every one links to its source. Gathering it was easy. Checking it was the hard part.
- Yes, I've used AI heavily on this project before anyone call it an AI slop. Making was easy, but it took billons of tokens of beating whack-a-mole ai to polish and tweak to make it usable and decent. Through that, I've created many skills and evals ranging from visual qa, evals for irregular data, automated i18n and others. It still feels much like AI as I was using Claude Design, which i want to improve on. I tried using local llm, but the throughput was so low.
Pricing: the first 5 minutes are fully open, no signup. After that, the top 3 destinations and 25 place breakdowns a month are free. A 30-day pass is $7, $39 a year or $69 lifetime.
iOS and Android apps are coming soon.
Any feedback welcome.
Hey HN,
I always had the problem that building HTML pages is really simple now, but trying to save data required hosting it somewhere, and sharing it afterwards was not easy. Over the last few months, I've been building an app called Capsule (it’s also the file extension name) written in Rust with Tauri 2.0 that allows packing an HTML app and its data into a single SQLite file.
The HTML file and any related assets are directly embedded in the database. User data can either be saved as a localStorage key/value store or via a MongoDB-inspired collections API as documents, saved in a table in the file. You can also save other assets, like PDF files or images, directly in the database to keep different documents together. All data can be easily exported to CSV or JSON if needed.
Privacy and security were a big priority for me, so documents cannot do anything out of the box. They don’t have direct access to the file system and they require permission to access the internet. The permission model is still something I’m working to improve. Capsule documents can also use local or remote AI models for document specific AI features.
One downside with this approach is that multiple people working on it will create different copies. To make it possible to merge different copies of the same file, each data entry has a unique UUID and timestamp.
I’m planning to open up the file format specification for the 1.0 version of the app so other apps can read or write Capsule files.
You can try it out in the web preview at https://withcapsule.app/preview with pre-built templates or use any AI provider of your choice to create a custom, Capsule-optimized app by using the following prompt:
"Please read the app wizard instructions at https://withcapsule.app/prompt.txt and help me design an app.“
I’m still working on the file format but there are migrations for each new version, so data should never be lost when using newer versions of the app in the future. Please let me know if you have any ideas or use cases where this might make sense or does not work.
Hi HN - long-time lurker (since 2012!), first time poster.
Pizza Bot is a self-hosted desktop app for Mac, Windows, and Linux that runs AI agents in the background and exposes them through an email-like UI. Finished work shows up in Unread, and anything waiting on your approval shows up in Action. It's Apache 2.0-licensed, there's no signup and no telemetry, and you bring your own model provider: Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter, or a local model through Ollama. There are builds on the releases page, or you can run it from source.
Pizza Bot started as an internal passion project I worked on with a small team at Amazon.
The whole thing came out of my frustration at having to manually log CRM activities through a browser form. I built a simple REST API called "JoeBot" that connected to my authenticated browser session over CDP and filled out the form for me using Playwright. Then I hacked up a quick Obsidian plugin so I could trigger it from my local notes (no AI and no MCP servers involved).
This caught on quickly. My fellow AWS Solutions Architect Igor Fil joined up with me, and we rebranded the project as "Pizza Bot," named after Amazon's two-pizza teams. We started seeing what other automations we could build. We found a GraphQL API we could query and hacked up some "recipes" to pull data out of the CRM to help with meeting prep. That worked great, and it was right around the time MCP servers seemed to be taking off, so we decided to expose Pizza Bot as an MCP server instead, so it would be available to AI tools through natural language.
This was a decent solution for technical users, but the Account Managers who live inside our CRM system wanted something too. We decided to rebuild Pizza Bot as an Electron desktop app modeled after an email inbox, so it would be familiar to non-technical users and would run on both Mac and Windows. We also bundled internal MCP servers as OCI images and hosted them in Amazon ECR as an "addon marketplace" so users could install them with one click without having to set up Amazon developer tooling.
The project took off organically and expanded outside of AWS into the wider Amazon organization globally. More than 2,000 people ended up using it for meeting prep, email drafting, Slack summaries, CRM logging, prioritizing their day, and web research.
Once apps like Claude Cowork and Amazon's own Quick Desktop came out, we realized the real growth opportunity was outside of Amazon. Rather than try to rip out the Amazon-specific integrations, we rebuilt Pizza Bot once more as an open source project. We leaned on coding agents heavily, which is the only reason a team our size could pull off a full rewrite. I'm pleased to say it's finally public, and we're hoping to bring in community members and see where it goes. We'd like to do for knowledge workers what Claude Code and Codex have done for programmers.
A couple of things to know up front. Most of what made Pizza Bot useful on day one inside Amazon came from that internal catalog of skills and MCP servers for Amazon's own systems, and none of it could come out with the app. So it ships thinner than the version those 2,000 people used, and building that catalog back up for tools other people actually use is where we need the most help. It's also a community project and not an AWS service, so there's no support or SLA behind it. The Windows and Linux builds aren't signed yet either.
On the technical side, Pizza Bot is a server and a client. The desktop app bundles both, or you can point a client at a remote backend; personally, I self-host the server on my home network and reach it from my phone over Tailscale. The server owns the thread lifecycle and checkpoints state with DeepAgents and LangGraph, and clients rehydrate from it as needed, so you can disconnect mid-run and pick the thread back up from another client. Approval pauses outlive the session that created them and collect in an Action filter, so you can answer an hour later from a different device. The agent you talk to has a sandboxed QuickJS interpreter that can reach your filesystem only if you grant it a folder, but its main job is to delegate. Each subagent is a 1:1 mapping of a Skill, and an Activity bar shows that subagent and the tool calls it's making as it works. Memory is opt-in and stored as plain markdown files on your machine. Every tool call is explicit, including looking up a memory - we err on the side of transparency to reduce surprises. Tools come from MCP servers, and skills are ordinary SKILL.md files with a per-tool approval policy, so existing skills that don't require a code interpreter should still work.
What I'd most like to hear about is where the app itself gets in your way, the kind of problem you can't fix by writing a skill or an MCP server. I'm around today to answer questions!
Built on top of Baileys. The goal is to handle all the tedious work—opening sockets, authentication, reloading—and leave you to focus solely on command logic and how you want your bot to be.