Please note: I have no technical education background with computer science, and have a barely working knowledge of frontent frameworks, and a basic understanding of what a database, API and request are.
If I were to think in utterly reductionist and simplifying tendencies, I would go as far to say that the world is all but 4 CRUD APIS, wrapped around a database. Rest all experiences, flows, journeys, UX, frontend are but pure abstractions.
The problems of app making, web designing, and more so of the visible layers and stacks of the different CS abstractions have already been solved to an extent. For every Node.JS, there is Ruby on Rails. There are __ number of ways in which things have been resolved.
The complexity lies in the inherent difficulties, capabilities, cascading, syntax, relations, and the lack thereof between the constituent atoms, molecules, and entities.
The below “slides” are an attempt to resist this infantilization, simplification, and avoidance of reductionist tendencies. It is an attempt to explore why and how the dialectics of the language COBOL, and the system - are a point in time reflection of the complex bureaucratic realities of the financing world, and the enmeshment with the tech that frameworks todays complex transaction realities. These said contradictions, themselves need to be understood and acknowledged.
Before understanding COBOL, it is imperative to keep in mind, that the entirety of the worlds finances runs on these fragile systems set-up in specific contexts.
The entire global economy runs on these systems of fragile technical contexts
When we talk about reframing the transactions of the real world onto a 2d surface / digital / banking realities, thing’s aren’t just a record/row in a database. The complexity is coupled between hardcoding financial realities vis-a-vis technical, organizational, situational contexts of the moment in time such decisions occur.
Money is a form of a mutually defined public agreement. The paper / coin number on the screen that is visible is not money.
The orange that you eat from the money that you give to the vendor is wealth. The house that you live in is real wealth.
This social contract, however abstract it might seem, is in fact the core idea behind a unit of the said “money.”
Before there were databases, there were ledgers. Physical books where clerks recorded debits and credits, assets and liabilities. Every transaction was a pair of entries: if you gained something, someone else lost it. This is double-entry bookkeeping, invented in 15th century Italy.
Flow Diagram: Double-Entry Ledger
┌─────────────────────────────────────────────────────┐
│ TRANSACTION: Buy Orange for ₹10 │
└─────────────────────────────────────────────────────┘
|
┌────────────┴────────────┐
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ MY CASH │ │ VENDOR CASH │
│ - ₹10 │ │ + ₹10 │
│ (CREDIT) │ │ (DEBIT) │
└──────────────┘ └──────────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ MY ORANGES │ │VENDOR ORANGES│
│ + 1 kg │ │ - 1 kg │
│ (DEBIT) │ │ (CREDIT) │
└──────────────┘ └──────────────┘