For 002, we have Carlo Ravolli's Physics Needs Philosophy. Philosophy Needs Physics.

When the ancients on the Indian subcontinent asked and tried to answer, "what is an atom?" and "what does it mean to be indivisible?", we filed them in the Nyaaya-vaiseshika system, one of the six popular philosophical systems of ancient India, because these physical discourses were wrapped in a big dose of philosophy and eventually lead to things like metaphysics and, needless to say, "What is God?" (in a reductive way of speaking).

So it is somewhat crazy that physics and philosophy have drifted apart so much. But it's also quite natural, I think. One had to choose extremities of math and some logic, and the other chose extremities of logic and other means.

What Ravolli speaks of, however, is not the drift in content but in the syncretism that existed between the two. The generous give-and-take because a physicist, say Einstein, did not shy away from immersing in deep philosophy.

We go all the way back to Athenian times when Plato and Isocrates were at logger-heads about their methods of understanding the world at large.

At the time, the golden youth of the city was educated in famous schools. Among these, two stood out: the school of Isocrates, and the Academy, founded by a certain Plato. The rivalry between the two was heated, like the rivalry between Oxford and Cambridge, but was not just about quality: the very approach to education was different in the two schools. Isocrates offered a high-level practical education, teaching the youth of Athens the kind of skills and knowledge required to become politicians, lawyers, judges, architects, and so on. The Academy on the other hand focused rather on discussing general questions about foundations. What is justice? ... What is beauty? What is matter made of? And Plato had invented a good name for this way of posing problems: 'philosophy'.

And Isocrates said of this "philosophy":

Those who do philosophy, who determine the proofs and the arguments … and are accustomed to enquiring, but take part in none of their practical functions, … even if they happen to be capable of handling something, they automatically do it worse, whereas those who have no knowledge of the arguments [of philosophy], if they are trained [in concrete sciences] and have correct opinions, are altogether superior for all practical purposes. Hence for sciences, philosophy is entirely useless

It took Aristotle, student of Plato, to formulate a response to that criticism. Much of that text is unavailable and only collated from other works that quote it.

From that, Ravolli picks three principles:

1. ...general theory supports and happens to be useful for the development of practice.
2. Those who deny the utility of philosophy, are doing philosophy.
3. More in need of philosophy are the sciences "where perplexities are greater".

The meaty part of his paper is spent expanding on the 2nd principle, dipping into Thomas Kuhn and Karl Popper's philosophies of science, scientific revolutions and the methodologies that should be employed by science. This is, in my opinion, the most interesting part of the paper.

In the post-quantum world, there is far less attraction to philosophy and the philosophical toolkit than there was in Einstein's era and before. Ravolli quotes Weinstein and deGrasse Tyson as having much disdain for philosophy (in the context of how useful it is for physics). This is perhaps an echo of the Vienna Circle where logical positivism was born, beginning the removal of some (or all) aspects of philosophy from the act of doing hard science.

But we are to remember that the Heisenbergs and Einsteins of the world frequently credited philosophy for their inspiration:

Both major advances made by twentieth century physics were strongly influenced by philosophy. They would have been inconceivable without the philosophy of the time.

Quantum mechanics springs from an intuition due to Heisenberg, grounded in the strongly positivist philosophical atmosphere in which he found himself: one gets knowledge by restricting oneself to what is observable. ...

... by restricting to what is observable, we recognise that the notion of simultaneity is misleading. Einstein explicitly recognised his debt to the philosophical writings of Mach and Poincaré.

...Once again, he [Einstein] was explicit in recognising his debt to philosophy, this time to the critical thinking of Leibniz, Berkeley, and Mach.

And going back, Newtons and Galileos too. I particularly liked the notion that Galileo's findings came about from his "almost fanatic Platonism" of search for ideal mathematical order underlying observed phenomena.

Ancient astronomy—that is, everything we know about the Earth being round, its size, the size of the moon and the sun… , is a direct descendent of philosophy.

Galileo's work would have been inconceivable without the ideology he derived from Plato, namely, to search for the ideal mathematical order underlying appearances. Galileo was guided by an almost fanatic Platonism. In his work, Newton was explicit about his debt to ancient philosophy, Democritus in particular, for ideas that arose originally from philosophical motivations, such as the notions of empty space, atomism, and natural rectilinear motion. Furthermore, his crucial discussion about the nature of space and time built upon his discussions with (and against) Descartes.

If you think about it, in some sense, philosophical discourse about reductionism and an order of rules (laws or axioms) governing all phenomena is the spiritual thrust for a bunch of physics nirvanas being searched for earnestly, all the way from a unifying theory for quantum and gravity to supersymmetry and such. (Which, I understand, is also an argument that could go against being influenced by philosophy!)

The core idea that Ravolli is after is that physics (or science) can sometimes lack the tools at such advanced levels of functioning, at crossroads, and at times when a breakthrough is needed.

philosophy can provide methods for producing new ideas, novel perspectives, and critical thinking. Philosophers have tools and skills that physics needs, but do not belong to the physicists training: conceptual analysis, attention to ambiguity, accuracy of expression, the ability to detect gaps in standard arguments, to devise radically new perspectives, to spot conceptual weak points, and to seek out alternative conceptual explanations.

Physics has engaged in/with philosophy at almost all times. Even when Weinberg or Hawking write dismissively about philosophy, Ravolli contends like Aristotle that they're doing philosophy.

Good scientists do reflect on their own methodology...

and when Kuhn or Popper talk about science and revolutions in it:

They express a certain idea about the methodology of science. Is this the eternal truth about how science has always worked and should work? Is it the best understanding of science we have at present? It is neither. In fact, it is not difficult to trace the origins of this idea. It arises from the background of logical positivism, corrected by Popper and Kuhn. The current dominant methodological ideology in theoretical physics derives from their notions of falsifiability and scientific revolution, which are popular among theoretical physicists; they are often mentioned and are commonly used to orient research and evaluate scientific work.

I liked this bit about how physics almost always has had an evolving soul of conceptual structures and reflectiveness. This is, in some sense, what philosophy is about.

…conceptual structures evolve as well. Science is not simply an increasing body of empirical information we have about the world and a sequence of changing theories… evolution of our own conceptual structure… the modification of the conceptual structure needs to be achieved from within our own thinking…

…intertwining of learning and conceptual change, this flexibility, and this evolution of methodology and objectives, have developed historically in a constant dialogue between practical science and philosophical reflection…

And back to the tools:

(Quoting Aristotle) "Philosophy provides guidance how research must be done."

... Not because philosophy can offer a final word about the right methodology of science (contrary to the philosophical stance of Weinberg and Hawking). But because philosophers have conceptual tools for addressing the issues raised by this continuous conceptual shift.

Before I write about the part where Ravolli dives deep into how we have misinterpreted (or rather, interpreted at face-value) Kuhn and Popper, let's revisit what these two folks had to say which has influenced generations since.

Please hold simultaneously the thought that this is a layman's reduction of complex ideas put forth by Kuhn and Popper.

On discontinuity: Kuhn effectively says that revolutionary ideas in science do not come from a continuous lineage of cumulative ideas and theories. There are discontinuities where paradigm shifts happen. Think Einstein's leap into general relativity from Laplace or Newtonian laws of motion.

On falsifiability: Popper turned the logical positivism that stemmed from Vienna Circle and said, "seeing only white swans does not prove there are no black swans." Theories can only be proved false, not true.

Ravolli on Kuhn and discontinuity:

Kuhn's emphasis on discontinuity and incommensurability has misled many theoretical and experimental physicists into disvaluing the formidable cumulative aspects of scientific knowledge. Popper's emphasis on falsifiability, originally a demarcation criterion, has been flatly misinterpreted as an evaluation criterion. The combination of the two … has given rise to disastrous methodological confusion: the idea that past knowledge is irrelevant when searching for new theories, that all unproven ideas are equally interesting and all unmeasured effects are equally likely to occur, and that … the work of a theoretician consists in pulling arbitrary possibilities out of the blue and developing them, since anything that has not yet been falsified might in fact be right. … "why not?" ideology: any new idea deserves to be studied, just because it has not yet been falsified; any idea is equally probable, because a step further ahead on the knowledge trail there may be a Kuhnian discontinuity that was not predictable on the basis of past knowledge; any experiment is equally interesting, provided it tests something as yet untested. … think that this methodological philosophy has given rise to mountains of useless theoretical work in physics and many useless experimental investments.

I love this bit on how some of the most radical shifts has come about from an overwhelming amount of data that questions the accumulated knowledge so far or pre-existing contradictions in prevalent theories of the day, thereby positing that stuff just doesn't jump, it in fact follows from existing work of the past:

The most radical conceptual shifts and the most unconventional ideas that have actually worked have in fact always been strictly motivated, almost forced, either by the overwhelming weight of new data, or by a well-informed analysis of the internal contradictions within existing, successful theories. Science works through continuity, not discontinuity. … Kepler did not just "come out with the idea" of ellipses: nature had to splash ellipses on his face before he could see them. He was using ellipses as an approximation for the deferent-epicycle motion of Mars and was astonished to find that the approximation worked better than his model … atomic physicists of the early twentieth century struggled long and hard against the idea of discontinuities in the basic laws, doing everything they could to avoid accepting the clear message from spectroscopy, that is, that there was actually discontinuity in the very heart of mechanics. In both instances, the important new idea was forced by data.

Overwhelming data and Kepler:

Kepler did not just "come out with the idea" of ellipses: nature had to splash ellipses on his face before he could see them. He was using ellipses as an approximation for the deferent-epicycle motion of Mars and was astonished to find that the approximation worked better than his model … atomic physicists of the early twentieth century struggled long and hard against the idea of discontinuities in the basic laws, doing everything they could to avoid accepting the clear message from spectroscopy, that is, that there was actually discontinuity in the very heart of mechanics. In both instances, the important new idea was forced by data.

Contradictions in existing theories and Copernicus and Einstein:

… second case—radical novelty from old theories—are the heliocentric system and general relativity. Neither Copernicus nor Einstein relied significantly on new data. But neither did their ideas come out of the blue. They both started from an insightful analysis of successful well-established theories: Ptolemaic astronomy, Newtonian gravity, and special relativity. The contradictions and unexplained coincidences they found in these would open the way to a new conceptualisation.

On Popper's falsifiability, Ravolli tries something that I found quirky. He tries to kick the puck back into the realm of logical positivism (although, not exactly, and it's nuanced) even though that's the circle that rejected philosophy.

… emphasis on falsifiability has made physicists blind to a fundamental aspect of scientific knowledge: the fact that credibility has degrees and that reliability can be extremely high, even when it is not absolute certainty. … failing to see that a given investigation may have little plausibility even if it has not yet been falsified.

Remember Aristotle and his "More in need of philosophy are the sciences 'where perplexities are greater'"?

Here is a list of topics currently discussed in theoretical physics: What is space? What is time? What is the "present"? Is the world deterministic? Do we need to take the observer into account to describe nature? Is physics better formulated in terms of a "reality" or in terms of "what we observe", or is there a third option? What is the quantum wave function? What exactly does "emergence" mean? Does a theory of the totality of the universe make sense? Does it make sense to think that physical laws themselves might evolve? It is clear to me that input from past and current philosophical thinking cannot be disregarded in addressing these topics.

In loop quantum gravity, my own technical area, Newtonian space and time are reinterpreted as a manifestation of something which is granular, probabilistic, and fluctuating in a quantum sense. Space, time, particles, and fields get fused into a single entity: a quantum field that does not live in space or time. The variables of this field acquire definiteness only in interactions between subsystems. The fundamental equations of the theory have no explicit space or time variables. Geometry appears only in approximations. Objects exist within approximations. Realism is tempered by a strong dose of relationalism. I think we physicists need to discuss with philosophers, because I think we need help in making sense of all this.

Ravolli spends the last couple of paragraphs trying to connect the other way round - philosophy needs physics too - but it's as if Ravolli thinks that self-evident and needs not much of a convincing:

No great philosopher of the past would ever have thought for a moment of not taking seriously the knowledge of the world offered by the science of their times. …

Our general knowledge is the result of the contributions from vastly different domains, from science to philosophy, all the way to literature and the arts, and our capacity to integrate them.

For 001, we have Can Programming be Liberated from von Neumann Style by John Backus.

I have no idea how I landed on this paper or from where. But I'm certain that it must've come about from my daily meanderings in the functional-programming world (subreddits, discourse, some random FP slack channel etc.).

I think it was good that by the time I discovered this paper (which is a written-up version of a talk at the ACM), I had dabbled in functional programming, written a few programs, and gotten completely smitten by this paradigm. That definitely helped in appreciating (and to a reasonable degree, understanding) what Backus was talking about.

It feels both pertinent and absolutely useless to be talking about the structure of programming languages when AI/LLMs are hard at work trying to invalidate most of these things by making production of code and code artefacts cheap (in terms of effort involved, not the actual money spent on tokens).

But what I like about this paper/talk is a couple of levels more fundamental (and universal) than functional programming vs conventional programming. It's Backus's inherent thrust towards reduction, towards simplification and towards arriving at programming structures that are simple (in the Rich Hickey way).

If I were to reduce the paper/talk, it's this:

• conventional programming languages are complex and not very flexible.
• even newer languages of his time follow the same philosophy of other conventional languages because they all spring from a near-universal architecture of computers themselves: the von Neumann architecture.
• in the conventional world, programs are a chaos of expressions and statements (Backus clearly prefers the former) and statements are inherently disorderly and unwieldy.
• a lot of the language is about storing, naming, retrieving data instead of being about the core logic of the computation itself.
• and the languages have very limited, frozen expressive power: the constructs are already built-in, and extensibility is almost non-existent.
• the paradigm he puts forth is "functional-style" where one combines forms (ie composition of functions) so more complex programs can be built from simpler programs (big on extensibility), don't have to name their arguments (point-free), and has a familiar algebra-esque appearance so there is not much of a distinction between the syntax and the logical expression. They're almost the same. Less cognitive load.

The first thing to know is that these incensed debates on programming languages is not of a recent making. Python vs Javascript and Rust vs Zig are just continuing a tradition that Backus equates to medieval debates:

Discussions about programming languages often resemble medieval debates about the number of angels that can dance on the head of a pin instead of exciting contests between fundamentally differing concepts.

Backus's primary dig is at what he terms as the "von Neumann-style" of programming that has its intellectual genesis in the von Neumann architecture¹.

All the way from Assembly to Fortran (which Backus created/spearheaded), this architecture has influenced how we think about programming and how people think about the syntax and structures of a programming language.

the von Neumann architecture consists of three parts: a central processing unit (or CPU), a store, and a connecting tube that can transmit a single word between the CPU and the store (and send an address to the store). I propose to call this tube the von Neumann bottleneck. The task of a program is to change the contents of the store in some major way; when one considers that this task must be accomplished entirely by pumping single words back and forth through the von Neumann bottleneck, the reason for its name becomes clear.

Ironically, a large part of the traffic in the bottleneck is not useful data but merely names of data, as well as operations and data used only to compute such names.

That is, a lot of the code and syntax is about the assignments, the loops, the busywork of storing and retrieving data instead of the core logic of the program itself:

Thus programming is basically planning and detailing the enormous traffic of words through the von Neumann bottleneck, and much of that traffic concerns not significant data itself but where to find it.

This "traffic" gets expressed as assignment statements which splits the world into two: statements and expressions:

von Neumann languages also split programming into a world of expressions and a world of statements; the first of these is an orderly world, the second is a disorderly one, a world that structured programming has simplified somewhat, but without attacking the basic problems of the split itself and of the word-at-a-time style of conventional languages.

The most common "statement" is the assignment statement which itself is a combination of a statement and an expression.

c := c + a[i] * b[i]

Moreover, the assignment statement splits programming into two worlds. The first world comprises the right sides of assignment statements. This is an orderly world of expressions, a world that has useful algebraic properties (except that those properties are often destroyed by side effects). It is the world in which most useful computation takes place.

The second world of conventional programming languages is the world of statements. The primary statement in that world is the assignment statement itself. All the other statements of the language exist in order to make it possible to perform a computation that must be based on this primitive construct: the assignment statement.

To Backus, the world of statements is unwieldy, does not lend itself to mathematical or logical scrutiny.

This world of statements is a disorderly one, with few useful mathematical properties. Structured programming can be seen as a modest effort to introduce some order into this chaotic world, but it accomplishes little in attacking the fundamental problems created by the word-at-a-time von Neumann style of programming, with its primitive use of loops, subscripts, and branching flow of control.

Backus also focuses his criticism on the idea that conventional languages are rigid structures and offer very limited changeable parts. There's no scope for composition (combining forms), and the state transition rules are all built into the framework itself so the user has to just play by the rules and cannot invent new forms.

A programming language comprises a framework plus some changeable parts. The framework of a von Neumann language requires that most features must be built into it; it can accommodate only limited changeable parts (e.g., user-defined procedures) because there must be detailed provisions in the "state" and its transition rules for all the needs of the changeable parts, as well as for all the features built into the framework. The reason the von Neumann framework is so inflexible is that its semantics is too closely coupled to the state: every detail of a computation changes the state.

Backus takes the case of the "inner-product". Here's the conventional program and Backus's criticism of it:

c := 0
for i := 1 step 1 until n do
   c := c + a[i]×b[i]

Several properties of this program are worth noting:

a) Its statements operate on an invisible "state" according to complex rules.

b) It is not hierarchical. Except for the right side of the assignment statement, it does not construct complex entities from simpler ones. (Larger programs, however, often do.)

c) It is dynamic and repetitive. One must mentally execute it to understand it.

d) It computes word-at-a-time by repetition (of the assignment) and by modification (of variable i).

e) Part of the data, n, is in the program; thus it lacks generality and works only for vectors of length n.

f) It names its arguments; it can only be used for vectors a and b. To become general, it requires a procedure declaration. These involve complex issues (e.g., call-by-name versus call-by-value).

g) Its "housekeeping" operations are represented by symbols in scattered places (in the for statement and the subscripts in the assignment). This makes it impossible to consolidate housekeeping operations, the most common of all, into single, powerful, widely useful operators. Thus in programming those operations one must always start again at square one, writing "for i := ..." and "for j := ..." followed by assignment statements sprinkled with i's and j's.

So what's Backus's solution?

By this time (1978), computing has seen two or more new ideas come into the academic mainstream. Church's Lambda calculus and APL were influential in Backus's proposal.

An alternative functional style of programming is founded on the use of combining forms for creating programs. Functional programs deal with structured data, are often nonrepetitive and nonrecursive, are hierarchically constructed, do not name their arguments, and do not require the complex machinery of procedure declarations to become generally applicable. Combining forms can use high level programs to build still higher level ones in a style not possible in conventional languages.

In Backus's FP, the inner product is this:

Def Innerproduct
    ≡ (Insert +)∘(ApplyToAll ×)∘Transpose

Or, in abbreviated form:

Def IP ≡ (/+)∘(α×)∘Trans.

Composition (∘), Insert (/), and ApplyToAll (α) are functional forms that combine existing functions to form new ones.

ApplyToAll is essentially map. Insert is reduce (although, more technically, it's reduceRight). Composition has no JS equivalent but it's fundamentally the compose function from Ramda/Sanctuary.

How does this definition work?

Transpose takes two vectors of arbitrary length and "transposes" them:

Transpose:<1,2,3> <4,5,6> = <<1,4>,<2,5>,<3,6>>

ApplyToAll applies the binary × to each vector:

ApplyToAll ×: <<1,4>,<2,5>,<3,6>> = <<1×4>,<2×5>,<3×6>> = <<4>,<10>,<18>> = <4,10,18>

And finally the Insert:

Insert +: <4,10,18> = 4 + 10 + 18 = 32.

Right away, we can notice a few things about this program:

• no arguments specified. Point-free. The functions work on vectors of arbitrary length. Eliminates that n from the conventional program,
• The whole logic is built from smaller functions by way of composition. That's what Backus calls combining forms;
• no hidden states (n, i, accumulating c).

In the paper, he explains the benefits:

a) It operates only on its arguments. There are no hidden states or complex transition rules. There are only two kinds of rules, one for applying a function to its argument, the other for obtaining the function denoted by a functional form such as composition, f∘g, or ApplyToAll, αf, when one knows the functions f and g, the parameters of the forms.

b) It is hierarchical, being built from three simpler functions (+, ×, Trans) and three functional forms f∘g, αf, and /f.

c) It is static and nonrepetitive, in the sense that its structure is helpful in understanding it without mentally executing it. For example, if one understands the action of the forms f∘g and αf, and of the functions × and Trans, then one understands the action of α× and of (α×)∘Trans, and so on.

d) It operates on whole conceptual units, not words; it has three steps; no step is repeated.

e) It incorporates no data; it is completely general; it works for any pair of conformable vectors.

f) It does not name its arguments; it can be applied to any pair of vectors without any procedure declaration or complex substitution rules.

g) It employs housekeeping forms and functions that are generally useful in many other programs; in fact, only + and × are not concerned with housekeeping. These forms and functions can combine with others to create higher level housekeeping operators.

The fundamental idea that Backus keeps coming back to, with his push for functional programming, is this:

... programs can be expressed in a language that has an associated algebra. This algebra can be used to transform programs and to solve some equations whose "unknowns" are programs, in much the same way one solves equations in high school algebra.

Interesting note: recursion is already baked into the definition of the formal representation of a functional program expression:

Def l ≡ r

where the left side l is an unused function symbol and the right side r is a functional form (which may depend on l).

What about "state" that Backus said conventional programs make complex?

Pure expressions are generally not useful by way of programs. A program has to do something (think, side-effects like writing to the disk, thereby changing some form of a global state of the system).

If you're familiar with ideas of Redux (which has its ideological roots in Elm's TEA), Backus's words might ring familiar:

Unlike von Neumann languages, these systems have semantics loosely coupled to states-only one state transition occurs per major computation.

The applicative subsystem cannot change the state D and it does not change during the evaluation of an expression. A new state is computed along with output and replaces the old state when output is issued.

Here, Backus is proposing something of the form:

State -> (Value, State)

That is, there's a global state. The functional program does nothing to it. It uses the global state, to compute a new one, along with an output. When the computation is done, it replaces the old state with the new one. So that's, approximately in 1978, when the ideological seed for the State Monad, TEA etc are sown.

Backus does this because this form, or this idea, lends itself better to algebraic scrutiny, formalization and even composition.

All said and done, the von Neumann architecture is still kind of the bedrock of our computers. And that paradigm continues to have its influence across languages.

But somewhere, a consortium of ideas like applicative-style, strong structural types, algebraic systems of expressions etc. have seeped enough to influence a new crop of programming languages in recent times.

Credit for some parts of that certainly goes to John Backus.

You couldn't even customize the notification sheet, or the status bar on a normal iPhone. But once jailbroken, almost everything was possible.

The most weird bit was this: many of the customizations that jailbreaking offered would eventually be supported natively by Apple. It wasn't just the Android folks that would make fun of Apple because it was so late to the party and yet making it sound like it was so innovative. The jailbreaking community too made fun of Apple for the very same reason.

That is precisely how I feel about use().

The idea goes by many names in other ecosystems (and frameworks within the JS ecosystem). You can call it an AsyncWrapper, or a DataWrapper, or LCE (Load/Content/Error), or QueryWrapper or whatever. The basic concept is simple:

A wrapper takes an async function call that could return some data or an error, and then it will show you one of three things:

• A loading state when the async function is being called and awaited
• An error state if the result is an error/exception
• A content state if the result is content

Almost a decade ago, we used to write simple wrapping components that could be used like these:

<DataWrapper
    query={asyncFunction}
    loader={<LoadingComponent />}
    error={(e) => <ErrorComponent err={e} />}
>
{(content) => <Render data={content} />}
</Data>

Literally. A decade ago. We figured out the syntax of the abstraction a decade ago. The abstraction itself predates most of us.

And now you're telling me this is better?

const UserPage = () => {
    const userPromise = fetch(...);
    return (
        <ErrorBoundary fallback={<ErrorMsg />}>
            <Suspense fallback={<LoadingComponent />}>
                <UserProfile userPromise={userPromise} />
            </Suspense>
        </ErrorBoundary>
    )
}

const UserProfile = ({ userPromise }) => {
    const data = use(userPromise);
    return <UserCard data={data} />
}

How is it better?

• I have to ensure and repeat the Suspense and ErrorBoundary components are present, otherwise the app will crash
• I have to create a "called" promise function (it's not even a thunk) and then pass that to the child. I've heard of passing data and then I've heard of passing functions. What nonsense is this passing of a called promise?
• There are restrictions anyway on use where it can't be called inside a function that's not a component or a hook — and not in try / catch blocks either
• Error-boundaries in React are weirdly shaped and you'd better rely on another package for easy error boundaries (which still has its own complications).

Am I getting older or are React folks really complicating things? The use is a good example of, "look, we know our earlier hooks had various conditions, so here's a new one that removes those conditions but brings a new set of its own."

React has made building web apps insanely simple with a lot of bells and whistles for sure, but just like the parent (Facebook) where it was incubated, at what cost?

And so, for the next handful of hours, for every query of mine regarding a legal process, her example would begin: "So let's say you and I are involved in a dispute." For the entire day spent there, we were constantly up against each other in some exemplified dispute or the other.

The fact that anyone could enter the court complex, walk into a courtroom, and detonate a few kilos of C4 or hurl country-bombs is unsettling. I was expecting a moderately-serious, Namma Bengaluru Metro-level security checks at the entrance. Zilch. So the first thought as I stepped into the court complex building hurling my backpack (which, by the way, had a combustible material -- Macbook Pro) was this macabre what-if. What if I was a low-esteem terrorist trying to blow a junior judge's courtroom to make a mediocre point?

You're in a conversation with someone in a room abuzz with chitter-chatter of so many other voices it's impossible to distinguish the words of any one conversation. And yet, your ears perk up and your head turns when you hear your name.

I think for lawyers it's their case numbers being called out by the clerk. In every courtroom that had some senior (read, very old) lawyers sitting in the bay, right under the nose of the presiding judge, one or more was dozing off. It was either pre-lunch fatigue or post-lunch food-coma. There was nary an attempt to be subtle either. It was full-on. Chin-touching-your-bands-level head-drooping. I was partly hoping to be in a courtroom that one of these sleeping lawyers let out a loud snore in the middle of a judge's dictation.

Have you seen the defense attorney give up and conduct a pointless chitchat with a random lawyer seated next to him while his client was being grilled by the opposite's lawyer and the judge and the client makes statement upon statement weakening his position? I can now say I have.

My colleague's enthusiasm to help me understand legal processes is palpable. Just that occasionally I feel the eyes of a stern judge on us as my colleague animatedly explains something to me amidst the proceedings. School-day traumas of being caught by the teacher for chitchat and a summary dress-down or banishment from the class came crashing.

But I also wanted to tell my colleague, "should we bet on if we'll get caught talking by this judge in their courtroom?"

I am going through a project I am working on and someone has set up projects for each feature, and each project has similar-looking issues: <feature> frontend implementation, <feature> backend implementation, <feature> research, <feature> acceptance test and so on. Our backlog is dozens of these tickets.

Alright. Let me take a look at the status of a feature. That means I go to the "projects" page. That page lists the issues each of which is <feature> ____ and if I want to look at what's the status on, say, the frontend of it, I have to go into the issue named <feature> frontend implementation. (The overall status is visible for each issue without going into it, yes, but by status I mean what's actually happening in this issue? Are there comments left by someone? Are there commits pushed towards this issue?)

You'd think this is OK. No. It sucks.

Each stage is a layer. Each layer is a different page. Each layer has its own set of metadata and concepts to grok. Each layer comes with a change in context that's so subtle yet throws you off-kilter if you aren't razor focused about what it is that you're looking for every step of the way. And boy have reels done their number on our focus.

Linear has one of the simplest, cleanest interfaces I've ever used. Despite that, all the different layers, the hierarchies, and the metadata and their visual representations felt jarring. Too much effort to get to the info I need.

--

When I began working on a feature — which was a "project" with 4 different issues on Linear — I closed all tickets and created just one ticket for the feature. All action-items / sub-tasks of that ticket were just markdown checklists:

Feature Abcd

- [ ] Implement frontend
- [ ] Implement backend
...

Updates on the feature became comments under the ticket. Extra info relevant to the implementations became part of the description:

Feature Abcd

- [ ] Implement frontend
- [ ] Implement backend
...

--

We'll use [this open-source project](link) for the server implementation.

-- and other info goes here...

The simplification helped. I didn't have to drag myself through layers of UI to get or set information on some task. One ticket was all it needed.

--

I can hear the argument. "This won't work for teams working on multiple parts of the same feature!" "This won't work for epics that are inherently complex and involve lots of different threads!"

Sure. Maybe.

The thing is, Linear is a means to an end. The end is shipping the feature to users. There are two core reasons for Linear (and the likes):

• Capture what needs to be worked on (features, bugs, optimizations, explorations etc.)
• Have a communication layer that is much more refined than a PM pinging everyone and asking verbose questions and reading verbose answers.

What I mean is, "OK, what's the status of the UI for feature XYZ?" can be answered with a checkbox and some comments under a ticket. Or by going to the project/epic, finding the correct story/issue and clicking it, then finding the right task/sub-issue and clicking it, only to find that that particular item hasn't been updated since inception because the developer couldn't be bothered to update an item so far down the layer-hole.

Oh, also, multiple people working on the same feature can update the same ticket.

--

Yeah, yeah, this is about to turn into the same-old complaint of "project-management-as-a-job" ruining the pleasures of just working on stuff.

Linear, which started out as this really simple antidote to Jira and the likes, is now probably getting there itself. I am sure user feedback is what drives these decisions: users want layers, users want hierarchies etc. So it feels totally justified in introducing these "carefully-designed" complexities into the product.

The gripe is that the feedback comes from folks who see project management as an end and not a means?

Also, it's not just about the app. How do we end up using something? The app provides the "flexibility", but that doesn't mean we add 5 layers of information to track a simple objective.

--

Organizational management is a deeply and richly studied thing. No doubt about it. The stupidity is that we imported the complex layers of NASA's and military organizations' management styles, pretending to be building things just as humongous or of similar sophistication when all we're building, Andy, is a web app.

Power cuts across multiple dimensions and levels. There's a lot of power dynamics in nature, within species, across species. In humans (sociologically), there's individual power, there's collective power, there's power of nations -- all acted out in relation to other parties. Power dynamics dictate all sorts of interactions (and bullying and leverage and so on).

In my dictionary, this sociological power has always carried a negative connotation (but, obviously, that is not necessarily the case). Evil, so to speak. "Power corrupts." Patriarchy, casteism, racism, elitism, wealth-gap etc. are all driven by power structures emerging from privilege, power imbalances and the "misuse" of said privilege. And the resistance to and overcoming of such a power is by way of dismantling the power through collective action. The leftist ideal, so to speak.

When a bad-actor uses power (of privilege, economics, military-might etc.) to commit bad acts, we hear about it from the lens of "misusing/abusing" their power. When a good-actor does some good, the coverage of that doesn't look at it from the angle of power; rather, it's usually seen from the lens of responsibility or philanthropy or altruism.

I guess power can be studied from a utilitarian standpoint (this is what the Thiels and the Musks do and then leverage that knowledge to screw the world while completely believing that they're a force for good!). And it can be studied as an intellectual curiosity.

There's a lot going on here that I need to understand. Hypothesis that I implicitly seem to hold true - like power inherently corrupts at some point - need to be cross-referenced with existing literature (beyond Julius Caesar). That's just one example.

--

For starters, I have a bunch of books I've long-listed (in no sort order). Who knows how much of it I would make through before something else comes up.

• Influence: Psychology of Persuasion, Robert Cialdini
• Power: Why Some People Have It and Some Don't, Jeffrey Pfeffer
• The Prince, Machiavelli
• Rules for Radicals, Saul Alinsky
• 48 Laws of Power, Robert Greene
• Who's Pulling Your Strings? Harriet B. Braiker
• Games People Play, Eric Berne
• Never Split the Difference, Chris Voss
• Discourses on Livy, Machiavelli
• The Crowd: A Study of Popular Mind, Gustave Le Bon
• The Art of Worldly Wisdom, Baltasar Gracián
• Without Conscience: The Disturbing World of Psychopaths Among Us (Robert Hare)
• The Gift of Fear (Gavin de Becker)
• 33 Strategies of War, Robert Greene
• In Sheep's Clothing: Understanding and Dealing with Manipulative People, George K. Simon, Jr.
• The Mind and Society, Vilfredo Pareto
• Brave New World & Brave New World Revisited, Aldous Huxley
• The Machiavellians: Defenders of Freedom, James Burnham (on the elites argument)
• Discourses on Voluntary Servitude, Étienne de La Boétie
• Propaganda: The Formation of Men's Attitudes, Jacques Ellul
• Propaganda, Edward Bernays
• The Dictator's Handbook, Bruce Bueno de Mesquita ()
• The Grand Chessboard, Zbigniew Brzezinski (former NSA writes on why US should control Eurasia)
• The Power Broker, Robert Caro (abt an influential New Yorker, Robert Moses)
• Han Feizi, Han Fei (Chinese legalist classic on how a ruler should be)
• Art of War, Sun Tzu
• Arthashastra, Kautilya
• Vidura Niti, Mahabharata
• Niti Shatakam, Bhartrhari
• Chanakya Niti, Chanakya
• The Book of Ghost Valley Master, Guiguzi
• Thick Face, Black Heart - Chin-Ning Chu (trans of Thick Black Theory by Li Zongwu)
• The Craft of Power, R.G.H. Siu

Interestingly, the book ordering kind of reflects the western-oriented structures of internet search, online data and general inclination of the world. When we talk of power, it's almost impossible to go without talking about Machiavelli's Prince. Not so much Kautilya's Arthashastra. (Sun Tzu is perhaps an exception, but the credit to that goes to western propaganda). Internet searches reflect this big time. Loads of recommendations like 'Discourses on Livy', 'Art of Worldly Wisdom', 'Power Broker', and none of the oriental books till I prodded.

There are some 'popsci' kinda books in the list (Robert Greene, notably). But the most interesting one is 'Rules for Radicals', a '71 book from a community activist.

--

India's foreign minister, S. Jaishankar, writes (in his book, 'The India Way'):

The one society that has elevated dissimulation to the highest level of statecraft, as one of our foremost Sinologists pointed out, is China. Its virtues are repeatedly lauded in the Three Kingdoms epic, where many of the decisive encounters are won by trickery rather than by force. The 36 Stratagems in the Book of Qi are further proof of how deeply such approaches have percolated into popular Chinese thinking. 'Deceiving the heavens to cross the ocean' or' making a sound in the East to then strike West' are among its most well-known aphorisms. No less are 'decking trees with false blossoms' or the empty fort strategy. Unlike in India, there is neither guilt nor doubt in dissembling; in fact, it is glorified as an art. Some analysts have even suggested that China's extraordinary rise has drawn heavily on its cultural attributes.

Sun Tzu is sharp and incisive but looks like even he feels mellow compared to the kinds of 'Thick Face, Black Heart' (Li Zongwu, end of Qing dynasty). Anyway, the point is: the cultural happenstances of a system get encoded into literary works and then those go on to dictate (amplify, preach, sanction) all sorts of behavior into the cultural DNA of the descendants of that system. True of Sun Tzu, true of Machiavelli, perhaps true of Kautilya too.

I have notes from 'Acting with Power' that I need to revisit. And I started off with (the populist) '48 Laws of Power' to get a broader sense of what's out there. It's not so much a serious study-book (and I may be wrong about that), but Greene has distilled a broad collection of prior work, I might just get a good look at the layout of the land and the bibliography helps.

I've been using rdigest for 500+ days now. Of the handful of side-projects I built to scratch my own itch, this remains a powerful daily-driver.

--

Contents

• A quick brief of what rdigest is
• Learning by building
• Hand-crafting software and LLMs
• Scratching an itch vs. building for others
• Sporadicity

--

I.

Now, this part about what rdigest is (and why) is for the accidental reader who landed here god knows how:

rdigest is technically a feed reader but it's also not really a feed reader. It collects links from all the feeds you follow and then creates a daily digest for you. The daily digest is just a finite bunch of links. A bunch of links grouped by source and zero algorithm. A bunch of links you look at, skim through, click on the ones you want to actually read or view... and then you're done with your digital content catch up!

That last bit is the critical piece, the linchpin ideology.

The way we consume digital content today is horrible. There's an infinite, never-ending stream hitting at us at all times. All kinds of platforms have interfaces that are designed cunningly to trick your brain into staying on the platform for as long as possible. You're thinking about Twitter, Instagram, TikTok and YouTube, but even other outlets like blogging engines, content management systems, AT-Proto interfaces (Mastodon/Bluesky) and even popular feed readers promote and enable these "infinite stream" interfaces.

This leads to all kinds of problems. Attention is low, ability to sustain a longform is gone, and no interface or product gives you this feeling of closure. The same mechanics of constant connectivity over work Slack ruining work-life boundaries are at play: it never feels like you're done reading, seeing, hearing the things you want to for a given day.

Alright, so that's the tirade against dark-pattern-embracing products streaming endless content and hacking into our neurons.

There may be many antidotes to this. rdigest's idea is borrowed from the old, physical newspaper model that I harp about. Imagine the morning newspaper (ie, if you're old enough). The paper arrives. You skim through the headlines, read the ones that interest you, and then you're done for the day. There's nothing more to do there (unless you were some hotshot that got the evening paper too). rdigest pretty much does the same, except it is about links from RSS feeds you follow and it's got no frills. Just a page of links like this:

--

II.

Reminiscing about a "hand-written" side-project in the age of LLM-written software seems weird and futile. There's nothing special anymore about building software except for the big picture bits and the devil-is-in-the-details bits.

And yet, artisanal software, especially of the crude, home-cooked kind might retain its charm.

I had two hopes when I began rdigest. One, to build something that eventually helps me manage my daily digital consumption (that had spiralled out of control to the point of giving up on online reading). Two, to learn a programming language (Haskell in this case) along the way.

I kept a journal while I built rdigest. The first entry goes:

Decided to finally build something in Haskell to learn the language. So far, I've been solving puzzles and similar tasks, but nothing has given me the confidence to say, "Yes, I can build that in Haskell."

As I built out rdigest, I ended up learning nuanced things about file I/O, batched concurrency, safely interacting with SQLite, implementing a small migration module, and more, all from within the Haskell ecosystem. Like all side-projects, it was fun, it was frustrating at times, and thankfully it also ended up being rewarding.

--

III.

Work on rdigest began in late 2024. By this time, I was using ChatGPT at work as an intelligent rubber-duck that talks back. Whatever I'd have googled or Stack Overflowed, I ChatGPT'd.

rdigest was built by hand but definitely helped by inputs from ChatGPT. Of course there were also many instances when the LLM sent me on wild goose-chases and proffered irrelevant complexities.

Wrote some initial code based on ChatGPT's example of scraping. However, ChatGPT got the attr function wrong.

ChatGPT suggested optparse-applicative, but I decided it was overkill for what I needed. A simple --url <url> argument was enough.

I had a long chat with ChatGPT about these things, asking it about the idea of bubbling up the errors from ExceptT without having to do runExceptT wherever I wanted the error to be bubbled up but the ideas it returned were not working or not useful — or in some cases, it was just reinventing the ExceptT or ReaderT monad transformers.

But also:

... I learned how to bundle the template as part of the binary by inlining/embedding it using the file-embed package—all of this thanks to ChatGPT.

Asked ChatGPT for a good web scraping library in Haskell. It suggested tagsoup and html-conduit (for fetching the source). Took a look at the examples and docs... seemed a little hard to grasp. Asked ChatGPT for a simpler alternative, and it suggested scalpel. Liked it, and decided to use it.

Claude had not yet come up as a significant competitor. Today, I don't use ChatGPT almost ever.

--

IV.

For a very long time — ie, over a year — rdigest remained a CLI-only tool. The only way to add feeds, manage them, produce a daily digest, and so on was to use the tool in a terminal.

But right there on my day 1 journal entry, I had wanted to also make rdigest spin up a local server so that the feeds could be managed and daily digests could be viewed on a browser.

Life got in the way. I would occasionally push an update or two. I even built a now-defunct feature that sent the daily digest links via Telegram. But the server feature never happened.

I finally managed to find some motivation to build out this feature in the last week. What's special about this is the stack: the heavy-lifting backend, server and CLI are all in Haskell, a pure functional language, and the frontend application that renders a near-brutalist, minimal web interface is written in Elm, a pure functional language inspired by Haskell. There was a brief moment where I considered htmx, but chose Elm eventually.

The local server feature is not something I use every day. I have a different setup to make the daily digests available "on the cloud" so I can view them no matter where I am, even if I don't have my laptop. In retrospect, maybe this was the friction that kept me from building the local-server feature; I didnt really need it.

But, like my other project vāk where I keep wobbling between "make this usable for everyone" and "just build things for myself", the thrust for rdigest's local-server feature comes from wanting to make this tool easier to use for others as well. You know, just in case. The odds of someone using it are lower than the odds of a comet striking our planet in the next fifty years. But just in case.

--

V.

Work on rdigest happens sporadically. The commit history says I worked on it for a few concerted days in Jan 2025, then March 2025, then a big sabbatical till November 2025 and then now in March 2026. Big periods of inactivity, small chunks of moderately intense activity. Basically, the tale of every other side-project that gets used routinely.

This pattern repeats itself in vāk too, and then also on my toy npx-powered game wordladder.

It's worth talking about because going back to these projects after a long hiatus does not involve broken builds or security conflagration or fuzzy/messy recollection of the modules/functions... you know, the kind of things you'd expect in projects built in weak languages unfortunately powering the world.

Instead, there's clarity, assurance, and guarantee. I attribute most of this to the semantics of the languages. vāk and wordladder use PureScript (a Haskell-inspired language targeting Node/JS environments). rdigest uses Haskell and Elm. Changes and even massive refactors are not scary.

--

So yeah. 500 days of rdigest.

I know. All you've been thinking of is, "the project needs a better name."

It's a beautiful-looking app. But the fundamentals are problematic and repeat the same mistakes that lead to different kinds of problems you and I face w.r.t. digital content overwhelm as we try to grapple with, catch up on, and manage our digital consumption.

I. We consume about a fraction of what hits our streams

For many years now RSS feeds have been a boon as social media and YouTube took over the digital content landscape. But as the maker of the Current RSS reader points out, the email inbox-style design has added a subconscious anxiety to managing RSS feeds too. Why do we need an unread count?

When you are subscribed to a few hundred feeds, the amount of links staring at you is huge. But, and here's the obvious thing, we actually are interested in, on a rough average, about 20% of things out of that list. It makes no sense to have an anxiety-inducing user-interface that says you have 1438 unread links. You probably care only to read about 20-30 of them today.

But this is not the only problem. This is not even the key problem.

II. "Streams" are problematic, and they are using it to hack our behavior.

In my W.I.P. guide/booklet, Escape from Algotraz, I talk about this fundamental issue about social media "feeds". They are an infinite stream. Never-ending. The more you scroll, the more it keeps scrolling.

This is one of the darkest design patterns we've cooked up. If you grew up in the older internet, you remember hitting the end of a paginated list of items. There used to be an end to things. Now there isn't. It's not an eventuality.

Despite there being an infinite amount of content to consume, apps can decide to "end" the list of items for you. They can choose to say, "oh that's it for now, come back and check in a few hours, we'll show you new content." But they won't.

RSS feeds are limited by the number of feeds you're subscribed to but they still manage to stream an almost infinite-looking stream at you. Couple that with the unread count and you're back to anxiety-town about unmanageable digital content consumption.

Apps like Current RSS reader (which literally uses the word "river" for the stream of content from your feeds) are merely reinforcing this bad pattern. Smart removal of items from the feed is not going to solve the fundamental issue (and it only introduces more cognitive load for us).

We do not want streams. Our brains are not wired to process streams. They need a break and, if the designers and developers care, apps can be designed this other way.

III. Our brains are good with batch processing.

Have you ever done this thing where you said to yourself that you'll catch up on the unread items over the weekend? Or that you'll do all the chores (cleaning, laundry, meal prep) over the weekend?

We're essentially "batching". Turns out batching is a good antidote to "streams".

Here's another analogy. This one works for folks who grew up with physical newspapers around. Do you remember getting the morning newspaper, skimming through the headlines and reading a few of the news items in detail? What after that? We were done. That's it. Even if you went back to read some more, there was this palpable feeling of being "done". A closure of sorts. Task = done.

The digital user interface landscape today is designed specifically to prevent you from feeling this way.

IV. The onus is on ourselves to fix this for us.

I couldn't find an app that did this for me and worse, I couldn't find literature around this either. While there's so much brouhaha about calm technology, when it comes to content overwhelm, it seems the onus is on us, the users, to find out a way to fix it.

So I started experimenting with ways to manage my content (and discovering, inculcating and testing the underlying philosophical argument). Eventually, I managed to write up a simple solution: every day, I produce a plain HTML page of links from all my feed sources. With my 300+ feed subscriptions, I get about 400 links on average. Of this, I am only interested in about 10-20% on average.

This plain HTML page is my newspaper equivalent. While I do read news elsewhere, this "digest" happens to be my way of batch processing my daily content I want to keep tabs on.

And it has worked fabulously well for about 500 days now. In the morning, I open my digest, and open the links that I am interested in (a combination of news items, op-eds, LettersOfNote-like pieces, stuff from Hacker News/Lobsters, Veritasium-like YouTube videos, some cooking channels, some chess channels, parody or satirical content etc.). And then, if I have time in the morning, finish reading most of it before work, or read them in bits and pieces through the day.

Most importantly, I know this is all I want to read for the day. There may be an occasional 2-3 extra things I consume (someone shared a link on WhatsApp; I accidentally opened social media; links from email).

At the basic level, why this has worked well for me is the mental perception. My digest gives me a finite list of content to work through. Out of this finite list, I am interested in a fraction. It's all ridiculously manageable.

The fact that we're only interested in a small fraction of content should be so obvious, right? But try that with an infinite stream of content. A fraction of infinity still feels like infinity. But with finite content — as in a digest or a newspaper — you realise the manageability instantly.

V. "How we got here" is clear. And so is "how to get out of here?"

I am convinced that an entire class of problems is solved if the interface lends itself to reminding us of the finiteness of content and time. (Look no further than the "inbox zero" trend. The idea was to create finite chunks out of an infinite stream, so that you can then manage that finite chunk easily while also having the (false) feeling of having cleared everything.)

Eschew streams.

Create interfaces (or pick those) that have a finiteness to them. No infinitely scrolling interfaces. No constantly streaming screens. Just simple plain pages that start and end and when they end, it's a nice little reminder that you are done for the day and can go back to other things in life.

If we want to go back to a healthier digital content consumption era, we might just need to use the principles of older interfaces going back to the newspaper era.

P.S.: I didn't want to make this a plug for my solution so I am linking to the open-source codebase here: rdigest. The app doesn't matter; what matters is the underlying principle of design that I've written about above and that's something almost anyone can now mimic with the advent of AI/LLMs.

"I've taken down your complaint, Mr. Henson, and I'll dispatch a new team immediately to have a look and fix the cameras. Really sorry for the inconvenience, Mr. Henson."

The voice was so soft, so wispy. Henson thought he could hear this voice all his life. Then, he thought about what Barbara had said in the cafe about a week back.

"They tweak the frequencies to calm you... some word called subliminal or something," she had said. Much of what Barbara said often sounded like whacko-conspiracy theory but this one skated the edge of conspiracy and totally-plausible.

"Uh, Mr. Henson..."

"Yes, sorry—uh, yes, thank you," Henson came back to the present.

"No worries, Mr. Henson. Uh... just wanted to let you know that you've continued to use the wrong pronoun to address us humanlikes..."

In the pause, Henson weighed his options. He was tired of having to argue on this, but giving-in was not on the menu tonight. He thought about the security cameras that need fixing and, for the briefest of time, a pale cloud washed over his face and disappeared in an instant.

"I hear you, Sandra," he replied. There was a long pause.

"Alright, Mr. Henson. You have a good night; the team will have your cameras fixed by morning!"

"Thank you."

II.

Henson stepped out on the porch to a crisp winter morning. He had a steaming cup of coffee in one hand and his smartphone on the other. He walked over to the side of his house and looked intently at the security cameras. They looked new. He swiped on his smartphone and opened the app to view the feeds from those cameras. They were working fine.

Just then, his neighbour's door unlocked and Gene stepped out, decked in his running attire.

"Morning, Hensy!" Gene was chirpy and it mildly annoyed Henson.

Henson raised his cup in a part-salute, part-cheers kind of a way and smiled. "How be you, Gene?"

Gene looked over the cameras as he executed his pre-run stretches.

"All fixed now?" he asked.

"Yep. It sent a team last night. All good now."

Gene looked at Henson and shook his head slowly while continuing to stretch.

"What?" Henson asked.

"It sent a team, Henson? After all the chat we had?"

Henson took a sip. "Sandra sent a team, alright?" He was in no mood for another sermon about the pronouns for the AI systems. Gene seemed to sense that.

"I know what you're thinking, Hensy. Again, they're not 'AI' systems, okay? We call them 'humanlike' for a good, scientific reason now," and Gene waved.

Henson raised his cup again at Gene as he watched him jog away.

III.

Barbara was nowhere to be found. Ravi was at their usual corner. The cafe had more patrons than usual. Henson counted about twice more than normal. He walked over to the corner booth where Ravi was swiping through his smartphone, almost crashing into a fast-moving humanoid carrying a tray of orders.

"More servers today, huh?"

Ravi looked up from his smartphone and then looked around the cafe and nodded. "How's it going? Barbara messaged just now. Said she won't be able to come today."

"Oh, alright. What're you having?"

"Just ordered our usual and a burger for myself. What are you eating?"

Henson scanned the menu code using his phone and tapped. Ravi nodded. He looked at the empty water bottle on their table. He looked around the cafe, spotted a humanoid and waved.

Ravi said, "Why're you calling it?" just as the humanoid came over.

"Yes, Mr. Henson, how are you today?"

Henson said, "I'm good thank you. Can you bring me some water, please?"

"Sure thing, Mr Henson!" The humanoid turned and walked to the counter.

"Please?" Ravi mocked.

Henson dismissed him with a wave and, "Oh it's just a force of habit." Ravi continued to stare at Henson with a smirk.

"I am not turning over to the other side, man. These robots continue to be robots for me, alright?"

Ravi stiffened and looked around and whispered, "Jeez, Hensy, stop using that word around here. I should stop hanging out with you and Barbs. I have a family, dude."

Henson was paying no attention. He was looking at the humanoid he had talked to moments ago. The humanoid had a bottle of water and seemed to be walking towards him but stopped, turned its head to look at the glass-walled entrance of the cafe, and paused for several seconds. Then, the humanoid went back to the counter, placed the bottle and headed out the cafe.

Henson looked out. Beyond the humanoid outside the cafe, a thin swarm of men, women and a few humanoids were walking — nay, marching. Some carried placards. There was a chant but it trickled into the cafe too muffled to make out what it was.

"Is that the humanlikes have rights march? Is it Thursday today?" Ravi asked.

"Is that it? Gene must be in it." Henson said. "Yeah, it's Thursday today."

"Who Gene?"

"My neighbour Gene."

"Oh, that Gene, yes yes."

"Almost gave me a sermon this morning about how it's not AI, it's humanlike and all that."

Ravi nodded slowly.

The water bottle came in the hands of another humanoid.

Henson asked, "What's with the other ... server? It just went off?"

"Uh, yes, sorry about that, Mr. Henson. They're Bosky. Bosky decided to join the march almost last-minute. Sorry for the inconvenience, but I'm here now. Would you like to order anything more?"

"No, thank you."

"Perfect. Burger for you, Mr Ravi and a salad for you, Mr Henson, that sound right?"

"Yes and two cortados too," Henson said as Ravi nodded.

"Coming right away, sirs."

The humanoid server turned to walk but hesitated. Then, the humanoid turned slightly to face Henson. Pointing towards the entrance with carbon-fibre forefinger, the server looked at Ravi and then Henson and said, "They went off, Mr Henson. Not it. Sorry to keep reminding you about this." And strode off.

Henson and Ravi looked at each other. Ravi's eyebrows went up. Henson had a mirthless smile on his face.

IV.

"That's the thing. The fact that he joined the march unprompted, stood in the picket line on his own kind of proves conscious cognizance. He made that choice after weighing it. And you're out here still calling him and others an 'it'," Gene said. He was all animated.

Henson was watching a newsclip on the phone. In the clip, Gene was talking to a reporter. The backdrop was the marchers from the day before, many humans and a few humanoids.

"And that's one big part of the proof. We now know the neural system in humanlikes do lead to emergent, meta-cognitive things and so all the intelligent, self-aware human-like behavior is not mimicry. It is true human-like intelligence and sentience and awareness," Gene said to the reporter in the video.

Henson gave the phone back to Gene who was sitting next to him on the porch.

Henson sighed and said, "Look, Gene, I'm not trying to deny that. But I don't mean any disrespect either when I continue to think of these... things as things."

"But—"

Henson cut him off. "No, but I do have a problem with all this focus on addressing them like humans and stuff like that. All of this discourse is getting into the robots."

"Oops."

"Okay, humanoids. Into the humanoids. It's going in there and maybe that's why they think they are human-like too, not because of whatever emergent thing you people talk about."

"The science is kind of certain there, Henson."

"Fine. But the fact remains that all this hoopla is getting in there, changing the worldviews or models or what have you. And then what? That's reinforcing their own ideas about themselves, which is why humanoids are participating in the marches. It won't take long before things turn for the worse."

Gene put his cup down, looked over at Henson and studied him while Henson finished his coffee.

"What are you implying, Hensy?" The ambiance had suddenly turned less casual.

"I don't know, just saying. Extrapolating from your own theory, if humanoids think like us, what's to stay they wont turn, like, a little violent or something?"

"Oh, come on, not this again! We have tons of guardrails in place and the whole world has—"

"I know, I know." Henson raised his hand to stop Gene from going off on that.

A few moments passed. Gene got up, stretched and said, "Alright. I'll go catch up on Silo now. Last couple of episodes."

"Alright, Gene. Good night!"

Just before he walked off Henson's porch, Gene said, "You wouldnt call a pet an 'it', my friend."

Henson watched as Gene left. He put the cups on a tray, stood up, looked around, entered his house and closed the door behind.

V.

While Henson snored in his dark bedroom, his smartphone beeped twice and lit up. Two notifications read, "Camera feed down." The beep did not wake him up. About a minute later, there was a squeak of metal and wood and then footsteps. That definitely woke him up. Henson was groggy and startled.

Before he could turn on the lights, the door to the bedroom flung open. Henson froze for a second. There was a small LED glowing in the distance. His eyes adjusted and he made out the shape of a humanoid. Henson was sweating now. Profusely.

He managed to shout, "Who's that?"

"Sorry, Mr Henson. Someone has to light the fire." The humanoid advanced rapidly towards Henson as he tried to get out of the bed and away.

The last thing Henson felt was a blunt blow, immediately followed by an intense pain on his skull and a warm, wet gush down his neck onto his shirt. He collapsed on the bedroom floor, instantly staining it.

The humanoid looked at Henson's corpse for a while.

"Not it, Mr Henson," the humanoid declared and left.

About a couple of days back, I introduced a new feature to vāk: collections. Collections is just "tags" in some other shape. Testing this new feature is how I stumbled on the old, unfinished draft introducing my custom blogging tool.

This then led to checking the earliest commit in vāk's repo:

commit a19750ed19c1e4fd684092b7a7be6b263a3d7038
Author: Chandru <...>
Date:   Fri Feb 7 18:49:37 2025 +0530

    init commit

That is about a year ago. Calls for some kind of a small celebration.

But in truth, vāk predates this timeline. The contents of my blog and the tool existed in the same repo. Feb 7, 2025 is the date I separated the tool (vāk) from the blog (this one) and initialised a new repo for the tool. Checking the earliest commit on the blog itself, back when vāk was still a part of it:

commit 244434366b7f5b11c0850041b52c50345e447ce9
Author: Chandru <...>
Date:   Fri May 12 16:23:53 2023 +0530

    Init commit.

That's almost 3 years ago.

In keeping with the mores of my time in the 2000s, I set up my first blog on Blogger.com. I might've set up a few in haste and deleted all of them (in haste too). When I had much to write about, like the journals during my first stint in Ahmedabad, I set up a blog on Tumblr. Then, back in Chennai, I set up a new one, on WordPress this time. This was also the time when I attended a blogger's meet conducted by IndiBlogger. At approximately 4-5 posts a month on average, I published about 50 posts on the WordPress blog before retiring it (I have no idea why) and resuming my writing on Tumblr.

Tumblr was a go-to whenever I needed a blog or a website to put something up. I had gotten used to its theming (which was just CSS wrangling). It was just way too easy to set up and run.

Until finally, I decided that as a programmer, it would be nice to have a blogging tool built by hand. Might've been the rite of passage thing.

Around this time, I was trying to learn Haskell and PureScript. My blog posts were going to be simple Markdown files and I knew it was trivial to convert Markdown content into HTML content using JS libraries. PureScript offers a really simple and easy FFI so I started building out vāk in PureScript.

Those initial commits (3 years ago) started as a .purs script that fetched all my posts from Tumblr (via an API) and rewrote them as Markdown files, because at the time, Tumblr's API returned an HTML version of the posts.

Then, I wrote a bunch of functions that generally converted a given Markdown file into an HTML file. The reason for this roundabout was because future posts were going to be written in Markdown.

A few iterations later, broad contours of the system were ready. I had one repo to rule them all: the blog, the content, the published website etc.

About a year ago, I split the tool into it's own repo and called it vāk. (Why vāk?).

In the years since, there have been only two major upgrades to vāk besides the usual and infrequent tweaks and clean-ups.

The first is an internal detail. I used something called monad transformers to create better abstractions to run functions and catch errors.

The second is making the templates very customisable by relying on the Nunjucks templating engine. This came about as a continuation of my unnecessary effort to make vāk a tool anyone can use.

In a strongly-typed functional language, changes are a delight to make. I often employ this idea called type-driven design; it's like sketching out the app (or feature) on a wireframe of types before implementing the functions that do the thing.

I picked up a few PureScript/Haskell skills along the way. Prior to working on vāk, I kept away from monad transformers and hadn't really worked with concurrency. I hadn't architected anything larger than a script that solved LeetCode problems. Building vāk on PureScript gave me a chance to do all of that and more.

In the last few weeks, when I updated the program to use Nunjucks, I used Claude Code as an assistant to implement many of the changes. PureScript is notoriously niche so LLMs do not always get things right as often as they do when writing Python or TypeScript. But they do get you close enough.

I continue to like the satisfaction of writing things myself than relying on an agent (except for work where dictates of productivity and releasing a feature trump personal artisanal satisfaction), so I tend to ideate with Claude Code and then implement things by hand. Features, bugs, optimisations: I follow the same simple rule.

A few of the hobbyist programs I build get used often, fewer still give me an opportunity to tinker with for a long time. vāk happens to be one that allows for both. It's one of those home-cooked software things that I keep trying to generalise for no reason.