adityaathalye

---

Now, to die on this hill.

Speaking as someone who desperately wants people to stop inventing syntax, I want to offer my "inversions" of the author's conclusions.

> prefix notation puts parentheses further apart

Prefix notation guarantees that I instantly know what the function / operator is and what the operands are. I don't see (or care) to literally read the parens. The parens are not the point.

And if we are doing this, let's compare real-world code shall we?

For example, how many syntax points (like = and ; and whatnot) do I not have in this code block (of my dotemacs) because regular prefix notation means I can set any number of global variables in one single declaration? https://github.com/adityaathalye/dotemacs/blob/3ce80d8336ae8...

As a bonus, because of the prefix guarantee, when teaching someone a Lisp, I spend almost no time teaching the semantic meaning of syntax rules. All I have to do is show how prefix notation works, and drill that a few times with hand-coding exercises.

> formatting practices do not help to track parentheses

Auto-formatters---once again, because of prefix notation---can lay out code in very regular patterns and shapes. Auto-formatting further obviates the visual / aesthetic relevance of parens.

Not to mention smartparens and structural editing and other basic niceties of Lisp text editors.

> prefix notation results in more left-nesting

Perhaps. The value for me is that it results in more regular code, because, once again, standard prefix notation, and once again, standard auto-formatting. Nobody reads closing parens, or opening parens, or whatever other parens... we let our text editor take care of that stuff for us.

> Lisps lacks or discourages features that align the evaluation and reading order

This depends on whether the Lisp in question is imperative, procedural, or functional. It has nothing to do with S-expressions...

Essentially, the author makes the usual category error of conflating "Lisp" with "s-expression".

May I suggest associating "Lisp" with "Metaprogramming" as the better evil? Die-hard Lisp-2 nerds will balk, but I say any language with an ability to symbolically manipulate itself as its own data is a Lisp. For example, Julia is a kickass Lisp because it enshrined meta-programming as a first-class language design concern. Ditto Elixir. I'm happy thinking of those as M-Expression Lisp-likes.

And as a matter of personal taste, having been around lisp nerds, nobody who actively writes s-expression languages---even as hobbyists---reads parens. They/we see shapes and we manipulate our code like tetris, without even having to think about 'em parens, and soon enough, nor about the keyboard shortcuts.

Whether Emacs, or Vim, or VSCode, or IntelliJ or, whatever Lisp-aware editor, we simply slurp and barf and splice and unsplice and convolute-sexp, all of which I do as a normal part of Lisping https://emacsrocks.com/e14.html ... And this stuff is so readily possible because of the regularity of prefix-notation s-expr syntax.

(edit: add code example)

But also, sticking with it and making the retry happen---that was all you, robto. Our experience was pretty much that almost no-one we made our office-hours offer to, took it up.

Also, unrelated --- idle.horse --- fun domain! Is it an email carrier only, or does it have a future in public service, as a not so idle blog / site / memex content delivery beast too? :)

I interpreted hiring as optimal stopping problem because:

(a) we as hiring managers have no idea who's out there that we can hire and train for our requirement, and

(b) traditional hiring pipelines have a retry limit of zero; once rejected, rejected forever, and the open-door retry policy makes it infinite retries (after a cooling off period).

So the idea is to process applications as fast as possible to reject negatives and false positives, at the possible expense of some false negatives. And then try to defeat the downsides with the open-door / infinite retry trick.

That is certainly not exact science. Besides, I'm not a stats / maths / operations research person though, so I do accept I could be wrong. For now, I am okay being wrong because I hope to never have to hire anybody as an indie software builder :D

I've seen one or two software companies that are explicit about this. If memory serves, Jane Street is one example. These companies explicitly say in their "regret" emails that one can re-apply after six months of the last application.

My colleague and I worried about the same things back then. It turned out that because we imposed hard constraints on ourselves, we fairly quickly built a system that we could run under those constraints.

Particularly the office hours offers... We had a feeling not many would take it up, but we were not sure. But we were also not sure if we could pull it off along with our day jobs. At the end of it all, our guess was correct.

A reason I decided to publish it is because it was not exhausting! That's part of the "unwitting" part :D

Also, being able to make the steps ourselves was key. I expect nothing but exhaustion and disaster, if those hard constraints are imposed on any pre-existing hiring loop, and the interviewers have no say in tweaking the system.

Yeah, that's the danger with writing a first-person account. Easy to read it as self-adulation. And detailing one's operations in that vein makes it look like lots of back-patting. That said, it is what it is; for a blog post, like a book, is written twice---once when the person types it out and once when someone reads it.

The difference is in how we ran our, otherwise normal-seeming, interview loops. Speed, async-first, clear up-front communication (no corporate speak), and open-door policy all compose and work together.

Viz. if Language is compression (of thought / culture / the tacit je ne sait quois of being-to-being communication etc.), then definitionally, Language Modelling must also be Compression.

Except, language is an arbitrarily lossy compressor, who's "compression-prediction equivalence" is indeterminate and unstable, because Language co-evolves constantly; both as a function of or response to culture, as well as an influencer of culture.

So, the subjective-objective goodness of Language Models (of any kind of language) would be, at best, upper-bounded by the compression-prediction equivalence of the Languages corpus itself. And that is assuming the language corpus is perfect in every way---it captures all knowledge expressible by language and it is always in-sync with live evolution of all language expression and evolution (i.e. LLM training is not a batch job, but a real-time present continuous process).

For example, to my layperson eyes, the mathematical language of proofs actively weeds out ambiguity of subjective interpretation. Ideally, a proof ought to lead to the exact same conclusion on every single reading by any reader who can follow the steps. A proof also holds only if the rest of the formal, explicit, inviolable, internally-consistent set of axioms and results holds.

So it stands to reason that mathematical prose of proofs, being optimised as mechanical procedure of taking an open question to a deterministically closed solution, has better odds of approximating the tacit aspects of mathematical derivation.

Which makes an LLM able to construct a mathematical proof, which is mind-melting to say the least.

However, I wonder, can LLMs dream of mathematical sheep?

I relate strongly to SanjayMehta's comment, as a hiring manager, on a previous submission [0]. Plus, I read comments from so many job seekers, in software nerd slacks and discords, echoing the other side of the same pain (ghosting of course, but also... being sent rejection emails for stuff they didn't even apply for!!!).

It feels like LLM-AI augmented job seeking and hiring pipelines, along with LLM-ification of software organisational functions, have exacerbated the zero-sum-ness of the de-facto method of software hiring (multiple interview loops with coding and whiteboarding tests --- human evals, in a real sense).

viz.

*Severe, if not total, disruption of signal to noise of competence criterion.*

The ability to program, and to whiteboard-solve algorithms and architectures has been, for better or worse, adopted as the main criterion for programmer / software technician's competence. Unlike other professional fields we have to rely on explicitly visible evidence of on-demand performance.

Surgeons, civil engineers, professors, lawyers, bankers, accountants, even writers and poets etc. have to satisfy well-accepted professional criteria and come with referrals and they are able to show track record "out there" which is impossible to hide from anyone who knows how to look. Plus their conduct is held in check via explicit board reviews, as well as civil and criminal law.

The industrial programmer has little going for them in all these regards. Even job titles are meaningless... one company's principal engineer is another company's "L6", or whatever the hell that means.

*HR automation*

Companies can churn out job posts faster, and conveniently (but certainly not effectively) run many more people through LLM-automated hiring loops. Pretty sure a whole bunch of internal incentives are also getting gamed... "How many candidates did you evaluate?", or "What is the quality of your hiring funnel?" Well, synthetic candidates, and synthetic interviews can certainly help one's cause here.

*Applicant automation*

While job seekers are able to also automate their resume/cover letter flows, as well as portfolios and "content". The clever ones are able to automate themselves as well, and hold more than one job. Company layoff culture has not helped matters at all---if employers are out there saying "AI can do your job", then they have no standing if the other side turns around and says, "cool I can do many jobs as AI".

Its already become a runaway effect, I feel. An Ouroboros death spiral of automated content generation / summarising / filtering --- where software programs are also just "content" now.

You know, 'cause it is so darned easy to conflate tacit knowledge work with explicit (mechanical) "content creation".

[0] https://news.ycombinator.com/item?id=48712695

> SanjayMehta 85 days ago [–]

> Re: ghosting - this was the single biggest annoyance when I was hiring en masse.

> The HR executives would ghost both potential hires and no hires, because they couldn't be bothered to keep track (or they didn't understand the nuances.)

> Our successful hiring rate went up when we cut HR out of the hiring loop, contained them in salary fit and background checks. The hiring manager was responsible for keeping candidates informed.

> We kept diaries to keep track of potential hires and periodically went through them before starting a new search, something which recruiting agencies would charge us to do, but never did.

1. Universal Inter-Process Interface: Arbitrary program composition via the Standard Input / Output / Error interface, and "everything is a file" abstraction... None of the rest is possible without some such core design decision ("everything is an object" is the fraternal twin).

2. Widespread standard utilities: The broad availability of core util tools designed to cooperate via the same abstraction is a close second. Along with some default scripting language, that is also built for the same computing model.

3. Language of choice: Important for ease of access, but a distant third in terms of raw power, be it bash, perl, awk, node, clojure (babashka) etc. That's icing on the cake, because if one had no choice in the matter, the shell program would still be awesomely powerful. Proof is in the pudding---"scripts that matter" are always /bin/sh.

Generally speaking, the pain of learning to avoid sh and bash footguns is primarily a matter of some basic research reading: manuals, lore, and warnings (I love BashPitfalls). Well, either that, or learning the hard way by copy-pasting code, and if luck runs out, rm -rf ing something you shouldn't have.

There is no substitute to taking the day or so to read the manual, so you know it's a lot, but it ain't magic, and you can eat that elephant one bite at a time, at your own pace. Seriously... the wall-clock time of trial and error with BashPitfalls (about a day or so), is nothing compared to learning to use---and then having to re-learn every so often---the python or node or whatever ecosystem without losing it. Besides, the former knowledge is stable and so are the programs --- my Bash code will keep working the same way, forever, practically speaking.

One day, I tried to demo Groove in our weekly company-wide morning show-and-tells.

I had a few of our "usual suspect" files synced between my laptop, and another computer upstairs. And then I tried to show how I was making edits on one computer, then (dramatically) running up to the other one, and doing something else, or undoing / overwriting the previous edit.

The magical-to-me seamless, and fast updates didn't make much of an impression on the crowd. Perhaps all the huffing and puffing was not the best look while trying to sell something that was supposed to make everyone's life easier :,)

Anyway, I kept using it and was so hopping mad when it got "embraced, absorbed, and extinguished". Software that "just works" and works really well is such a rare thing.

@signa11, thanks for sharing it here :)

Happy to answer any questions here or over email (ref: HN profile).

Also, another earlier non-self-submit! Thanks @celadevra_ :)

https://news.ycombinator.com/item?id=41398006

  1 point by celadevra_ on Aug 30, 2024

https://xkcd.com/297/ (Lisp Cycles)

Kidding kidding... Cool project, thanks for sharing and kind of validating the stuff I ended up doing [0]. Hooray, use-package! That meandering (floundering?) culminated in my Emacs, which is a single `init.el file` (hooray, use-package): https://github.com/adityaathalye/dotemacs

[0] The blow-by-blow of which is documented in this excessively long blog post series I ended up writing as I was..., well, the title says it all;

Emerging from dotemacs bankruptcy the hard way

https://www.evalapply.org/posts/emerging-from-dotemacs-bankr...

The linked post is the first in the series, and it enumerates what features / capabilities I was going for, and the key references I used while figuring out the configuration, from scratch.

The Unix pipeline and the similar-looking Clojure expression are entirely different in how they do what they do. Pipes are process abstractions. The (perniciously improperly understood) "pipeline" macro is not pipelining anything in any way (not CPU nor process nor memory). It is merely syntax sugar to write a deeply nested call chain as a "flat" list of operations.

And it goes on to compare "ugly" code, again making the category error that "more" code is "worse". Because, one is swapping / splicing entire programs within a pipeline. Also, there are plenty of ways to slice that mango; you don't need temp files.

That said, having intermediate files in one's pipeline is a big help because one can use those to make pipelines idempotent. Plus, one doesn't need flat files, one could swap in a SQLite cache too, at will, without modifying anything else in the pipeline. This kind of design change is not possible with the equivalent Clojure function call chain, as-is. In fact, having such a requirement (one always finds need to restart processes after crashes, and have them pick up from where they died) causes us to write some custom (and therefore design-wise brittle) conditional restart loop on top of the computation to manage its failures inside the running program. An idempotent Unix pipeline simply needs to be... restarted from outside the process.

In this particular case, a valid complexity complaint would be about the lacunae of the Bash / shell programming language (and interpreter model) versus the Clojure language.

Also, again from a program design point of view, I feel there's a bit of "holding it wrong" going on there... Bash / Shell-fu, yes, but not enough to be dangerous (for example, sort | uniq | sort is a standard idiom of pipeline programming). Which claim is personal, and so I'm open to being corrected at the same level. Sources: my code and writing:

https://www.evalapply.org/tags/bash/

https://www.evalapply.org/tags/clojure/

https://github.com/adityaathalye (the pinned repos are Bash and Clojure)

And specifically, this log processing code, for a more apples-to-apples comparison with OP's post.

https://github.com/adityaathalye/bash-toolkit/blob/master/lo...

  deduplicate() {}

  frequencies() {}

  drop_first_n() {}

  drop_last_n() {}

  drop_header_footer() {
     drop_first_n "${1}" |
         drop_last_n "${2}"
  }

  window_from_to_lines() {}

As a happy user of UPI, I think is incredible. I want it to be more resilient, from our national economic standpoint. A (small as possible) fee, judiciously applied, will hopefully create generally constructive back-pressure on the digital side of the cash economy.

---

Why the oxymoron; "digital side of the cash economy"?

Zero-cost-to-consumer one-rupee instant transaction system is basically cash economy. Because, at least here in India, our so-called "informal sectors" have switched wholesale to it in Metro to Tier 2 cities. Significantly in Tier 3 cities and smaller towns. And non-uniformly across rural / village panchayat areas.

UPI, and indeed, digital transaction uptake essentially hews close to the availability of reasonably reliable grid electricity and mobile Internet connectivity and access to banking services. The abundance of low-cost UPI-capable devices is useful only if these precursors are useful.

Reasonable fee as an economy-scale tuned mass-damper.

I hope the result of applying merchant-fee-as-back-pressure, at any size of transactions, translates into a sizeable up-tick in hard cash transactions. Nations of people that want to remain sovereign and democratically-run, ought to incentivise heterogeneity of money flow mechanisms. Especially, they/we, the people, must ensure, through our democratic influence as citizens, that a sizeable portion of the/our economy is person-to-person hard cash transactions.

And this provides a measure for "is the fee punitive?". Let's say, hypothetically, India's money supply mechanism is resilient if about 75% of money supply is digital, and 25% is hard currency. Anything outside this envelope is tending towards punitive costs on the people, both as tax payers and as transaction-fee-payers. Our central bank could manage the money mix, through judiciously tuned per-transaction fee on UPI and other digital payments, not unlike managing the volume of banknotes in circulation. The digital printing press is infinite money, if the effective fee is zero (psychologically). Sometimes, you want to make the fee zero, to bring it all into balance again, but most times, you want to create some friction to keep it from becoming a nation-state level attack vector (whether self-goaled or externally inflicted).

Crypto currencies and/or CBDCs are emphatically NOT the answer for such resilience.

I'd go so far as to argue that those forms of currency undermine (pun intended) sovereign economic resilience, where "sovereign" includes the little guy as much as it does a multinational or a country.Crypto system infrastructure is brittle by design and construction. Its effective use is predicated on the magical availability of wildly complex planet-scale electrical and communication infrastructure, not to mention dedicated tending-to of fast-decaying compute hardware, by literally every single participant in the network. A USB stick of gold-brick valued crypto, buried in the backyard is not at all equivalent to a brick of solid gold buried in the backyard.

Digital money systems make top-echelon black-box corruption easy. Hard cash makes it hard.

Recent years have made it patently obvious that digital-first money flows are wide open to centrally-controlled and/or monopolistic manipulation by individuals in power.

Consider the logistics of managing USD 1M in small bills. Hell, even USD 100 bills because 1M of those is about 10 Kilograms of paper mass (or about 22 pounds for you non-SI enjoyers (why?)). Now you need a large handbag, or a cool trench coat with several large pockets.

Multiply 1M in USD 100 bills, by 1,000, for billion-dollar corruption. That is 10,000 Kg of paper bills alone [0]. Now, add to that, the industrial pallets, containers, and packing material to hold it all sensibly. Let's say 1,000 Kg for each such cash pile.

Further, add to that the real-world infrastructure and organisational capacity to construct, maintain, secure, transport, and otherwise manage the infrastructure needed to hold and deploy your USD 1Bn in hard cash. This staggeringly capital-intensive exercise is subject to economies of scale.

These facts of life make it that much harder for anybody, especially enemy nation-state actors, to physically perpetuate large-scale money-supply based corruption of the kind being increasingly perpetuated by individual people, in private and public life, because they are able to exercise state-level power over digital economies.

Furthermore, currency notes are ridiculously hard to counterfeit --- AFAIK Indian banknotes (and US ones) are among the most secure (as in transaction-trust-secure) forms of monetary exchange humans have crafted.

Printing and injecting those into an economy at scale, to launch an inflation-attack requires nation-state level capacity at multiple levels, and the geopolitical incentive to do so. And if they do, it does not remain surreptitious for long.

Co-opting money systems, especially crypto-currencies to private ends and/or a offensive economy-destabilising tools, is trivial in comparison. You don't need to launch a 51% attack on the ledger. You just need a big enough psychological spanner, delivered into everyone's infinite brainrot feeds, to make 'em believe in The One True Currency; one that benefits you personally the most, obviously...

Obligatory XKCD: "Security" https://3d.xkcd.com/538/

---

[0] More paper-napkin arithmetic: https://www.ehd.org/science_technology_largenumbers.php and https://goodcalculators.com/money-weight-calculator/ etc... (no affiliation to any of them).

(edit: fix typos, add clarifications, maybe I should have made an actual blog post... my publishing workflow isn't indieweb enough yet, sorry :'))

- 1. your central code review (and hosting), which is the critical choke-point on team collaboration.

versus

- 2. the ever-expanding ick of testing, building, deploying it etc... because failure modes of software construction infra are concentrated here.

  ---

Use Gerrit if you care about code review.

Code review workflow is the nub / hub of collaboration, and should never be blocked on anything else failing, including itself. Maintaining robust in-house code review infra. is work, yes, but it is quite manageable. Simple "single-box with full point-in-time snapshot recovery" designs will remain good for a long, long time... Think; workloads of teams of up to a few hundred programmers and bots, who would be pushing and pulling updates against multiple repositories at a time on a single, well-endowed, Gerrit box.

2. CI/CD: Use whatever works best economically.

Be it one giant in-house box running Jenkins, or a clever way to use github and gitlab's job infra as fallbacks for each other.

These systems fail often because pretty much all the ick of software construction is concentrated here. Be it simple test runners, or fancy end-to-end auto-deploy to rollback pipelines.

The mind-numbing ick of software supply chain dependencies, test run jobs, build jobs, failures / retries, bursts of high contention (lots of people / bots needing their test runs passing NOW), pulling and pushing artefacts, and so forth.

This is a true pain to manage, particularly in organisations that are laissez-faire about their software ecosystem ("best tool for the job" mentality etc.).

And on a personal note...

  --- <begin rant> ---

As if trusting enterprise chat SaaSes with all your company secrets wasn't bad enough. At least that has some contractual defensibility.

Had. Had... Now? Something is deeply wrong with people who aren't completely spooked by the current fad of letting hyperscalers steal literally everyone's data to make content and code re-production autobots. Based on how those companies have behaved from the get-go, and factoring in the overwhelming pressure the LLM industry has created to "become the biggest, no matter what, because biggest wins"; their "terms of service" are as good as their high-flying CEO's mood on a given day.

No thanks.

Besides, it's only been a hot minute since I adjusted to that other fait acompli of 21st century computing.

They who controleth thy hypervisor, controleth thy destiny.

--- Ye Olde Graybeard Wisdom

  --- <end rant> ---

You are a soothsayer!

I think I have found three, and they will keep me quite busy for a while.

Read/Think: Bioelectric networks as the software plane of morphology

cf. Allen Center / Levin labs / TAME

https://arxiv.org/abs/2201.10346 and other work from that fecund lab is ever-fascinating. I have been following their work for five or six years. Much of that informed a giant essay I wrote prompted by an essay contest on Consciousness: https://www.evalapply.org/posts/consciousness-lives-in-a-ded...

Read/Think/Research/Write: How to write a Hard SciFi novel that does not have magic technology genius, and certainly not magic ET showing up to save the day?

A spec fic author friend is on my case about it, because he said "why the hell haven't you written your novel yet?" and I foolishly said "yeah why not? okay let me do it", and now I'm stuck in an honour pact. Write or die trying.

Side-quest of $DayJob: Um, how does the weather even work (metrology)?

Because that's what happens when you're helping an applied sciences team run weather forecasting models, like WRF (pronounced "Worf", which I absolutely love :D). My day-to-day is packer and FreeBSD and shell scripts, but I have to also understand enough about the domain to be somewhat dangerous.

And also... why isn't everybody using FreeBSD + ZFS for all their server workloads?

---

x-posted from my earlier question [0] that David offered to fold into this regular Ask HN he runs... Thanks again; this is cool :)

[0] https://news.ycombinator.com/item?id=49101448#49106213

  _for-sale baby-shoes never-used

  "I must not complect.
  Complexity is the mind-killer.
  Complexity is the little-death that brings obliteration.
  I will face complexity and I will permit it to pass over me and through me.
  And when it has gone past, I will turn the inner eye to see its path.
  Where the complexity has gone, there will be nothing.
  Only I will remain."

  — Litany Against Complexity

But first, hang in there, and please try to not be alone in this. Let your people help, or at least be there in spirit (share your feelings with them).

Please read the Following as sharing, not advice (how could I, a total stranger know anything about your life).

Details private and personal (soul-crushing endings / losses / grief / damage etc.), but lesson public, learned the hard way over about the last 20 years. An incomplete list:

- Learning to think of, and do, the "betting" on myself thing, as construction rather than moon or bust, based on how I am wired. So for me, that is prioritising my sense of agency and curiosity, community and surroundings (I am a creature of my environment), independence of thought (skepticism, but not cynical fatalism --- let's call it scientific thinking mindset),

- Learning self-care, so that I can keep going as well as give care to others when they are in need. Learning to say yes and say no with grace and self-awareness. This has been crazy hard. Let me just say talk therapy saves lives.

- Luckily, surviving long enough to realise that, if I catch myself thinking; "Well, f#@! me, some really bad shit is happening to me... again? Is this the end? Finally?" ... realising that, oh right, lol, it was the same the last time and the time before that and... Well, I guess I ain't seen nothin' yet. Let me phone a friend and ask for help, or at least talk to someone who still loves me about nothing in particular.

- Being intelligent about money + material resources. Use cash and credit to solve problems, but also learn to have a great time with almost nothing... the less one needs, the freer one is, and more resilient.

- When programming as well as building large-scale systems, keeping state at bay and all them functions / subsystems pure / referentially transparent.

Restated another way, I guess my life has become a bunch of cliches (and it's not bad at all): airline announcement + SEALs motto + pithy sayings:

- Love thy neighbour / community and so forth, but please wear your own oxygen mask before helping others.

- Slow is smooth, smooth is fast.

- Health is wealth. (Sleep enough, eat real food, exercise enough, seek wiser counsel and/or therapy, be with kind people.)

- But also, Cash is King/Queen.

- Sharing is caring (and man is it also cheaper and just more fun overall)... Try as much as one can to play non-zero-sum games.

cf. some related meta stuff I blogged:

- My `now` page (needs a 2026 update, but enough to give colour commentary) https://www.evalapply.org/now.html

- On curiosity: https://www.evalapply.org/posts/what-have-you-been-curious-a...

- On orienting one's point of view, when surrounded by inescapable software tech business hustle culture and the concomitant "go big or go home" work/professional pressure: https://www.evalapply.org/posts/systems-scale-value/

- Rare personal share, from a very dark time in the recent past (the post is heavy stuff): https://www.evalapply.org/posts/dont-hurry-dont-stop-sad-ver...

And finally...

If you want to talk in private, I am open to an email conversation, per my "standing invitation". BUT there is a caveat. Please first talk to someone who cares about you. And then, if you so feel, email this total internet rando: https://www.evalapply.org/about.html#standing-invitation

More sobering thought: conviction rates are typically a small percentage of the people who do the foul deed. The definition of "arsonist", for example. What if someone started "just one" fire?

A more sobering thought: of the total fires fought each year, how many are started by those rogue firefighters?

A most sobering thought: why is it that there is so much fallow time, that they get bored?

A marquee remark.

  HTTP/1.1 402 Payment Required
  Content-Type: text/html
  Content-Length: 187 or something like that
  
  <html>
    <head>
      <title>Payment Required</title>
    </head>
    <body>
      <p>Please email your banking username and password to
         <a href="mailto:here-you-go-thanks-and-enjoy@llm2human.pages.dev">I love this so much</a>.
      </p>
    </body>
  </html>