The first time I heard the phrase middleware, I was writing software for FedEx with a terrific team of Oracle developers in the late 1990s. I had to ask for a definition. In short, middleware is software that run between two things. Middleware is software that is invisible to the user. Middleware is software but seems to fall outside the accepted definitions of an application or app. It is software’s own software-based infrastructure. Does that make any sense? Probably not.
I wrote my first lines of code on a PDP-11 microcomputer from Digital Electronics Corporation (DEC) during high school. I attended a school in a wealthy area surrounded by the massively burgeoning IT industry.  In my high school, four years before the IBM-PC came to the market, I learned BASIC. The name literally meant “Beginner’s All-purpose Symbolic Instruction Code”, and no does not relate to the American slang basic, which seems to be a bit of an insult. 

10 BEGIN 

20 PRINT “HELLO WORLD”

30 END

Hard to imagine how these building blocks gave us the world of modern digital commerce. Those roots go back even farther. That trip requires tipping our hat in honor of Ada Lovelace, Alen Turing.
My educational progression followed the global development of software and software tools. In 1982, heading to university, I bought an IBM-PC for $2,500. That was the discount a university professor got. Adjusted for 2022 dollars, the cost would approximate $7,500. 
As a college first year, I thought I would study computer science. Regrettably, my university’s systems were older than my high school’s systems. No way was I going to learn how to program in assembly language on a huge mainframe computer. Mainframes, in 1982, were already doomed, so I thought. I never wanted to write an operating system, which was one of the capstone assignments. 
I finally took CS-111 as an independent study. In a class by myself, I read Cooper and Clancy’s “Oh Pascal” learning the software language Pascal. That book remains on the shelf behind me in my office today. 
At the age of 28, I had already been a contributing author and technical editor for books about computer programming. Two evenings a week, I stood in front of a group of adults teaching programming skills at a community college. One high school elective and single independent study course for one semester started me on my career. While an autodidact, nearly all I learned fell beyond the reach of classrooms. School never came easily to me, likely because of my learning differences. 
I watch colleagues like Dimitri in awe. In direct comparison, I see that I fraud and the idiot, even today. We’re all like that though, aren’t we? We get good at something, or we get recognition then we tell ourselves: No, I don’t deserve this. From my perspective, he is better skilled that I, smarter than I. I admire he jumps between programming languages and environments.
I mentioned Pascal on purpose, not just as the rambling digression (I do love my digressions though). The programming language I use for work today had been built from Pascal. Oracle, when needing to create a procedural programming language borrowed heavily from Pascal. Pascal is an imperative and procedural programming language, a natural progression for me from BASIC. The language had been designed by Niklaus Wirth. Mr. Wirth, who is 88 years old in 2022, won the Turing Prize in 1984, roughly the same year I learned Pascal. 
Stevie and I write code in Oracle’s PL/SQL language. The language derived from an earlier structured procedural language called Pascal, that I learned at university after learning BASIC in high school. We declare variables at the top of a subroutine. We write code in logical subroutines called procedures or functions. These get compiled by Oracle into the database as something that is no longer intelligible to human readers. These routines / subroutines form building blocks within the database to perform tasks, typically with data. One might need a routine that calculates the total value of an invoice. That routine must spin through each line of data for an invoice. The routine identifies the quantity of items ordered. It then multiplies quantity by the unit price to generate the value of that invoice line. Then we tally the total of the invoice lines to get the invoice total. We, the developers, must control this process precisely, due to the variations needed. When do you round the numbers to two decimal places? When do you calculate the taxes? How do you handle items that are not taxed. How to you calculate discounts? Each of these steps must follow the client’s instructions and we must do it precisely. The process and math must be consistent and transparent. Someone will run a calculator through the numbers to confirm the math. Later, an auditor will verify every bit of it. Nothing can be hidden. 
That’s the land of managing the boring business data: customer contacts, invoice information, inspection data, reporting, document management, bank balances, reservations, etc. My world.
Our software depends on a user running the application within a browser. The user updates a customer’s profile or generates a service order. Those tasks such as presenting the data entry web pages to the user’s browser is accomplished by Oracle APEX. I do not have to write the JavaScript and HTML and CSS required to make an application operate within a browser. 98% web-based applications rely on JavaScript. 100% of web-based applications depend on HTML and CSS. We tell the browser to paint a region blue by setting the region’s color property to blue. We do not tell the browser how to do the painting. We only specify the color. We don’t tell a browser how to draw a line, we specify the thickness and style of the line. I won’t present a sample of object-oriented code to read. It doesn’t read well, maybe it is hard to hear: onclick= “void(0);”
When I look at our applications written in Oracle APEX, the apps can look different on the different browsers. Occasionally, in Firefox, I see fonts with serif instead of the sans-serif font specified by our team. These variations are reminders of a key difference between procedural languages and object-oriented languages. With object-oriented languages, such as JavaScript, the browser decides how to execute a process. The browser’s own personality expresses itself a bit. 

One might argue that the process of formatting and presenting data to users via a browser could be called “edge-ware”. Browsers and JavaScript is software sitting at the edge of an application. Edge-ware, a term absolutely nobody uses, sits at the edge of a software application formatting and presenting our pages to the user. Ok, if you do an internet search on Edge-ware, you will find a village in New Zealand and a couple of companies. Let’s also quietly acknowledge that JavaScript is used on servers too. That is a more recent development. 
The user logs into our Oracle APEX application via browser. The data travels back and forth between the user and the Oracle server via the internet. For illustrative purposes, the Oracle Server sits in the middle of the internet, the “Cloud”. Users sit at the edge of the cloud with their phones, tablets, laptops, and desktop computers. And let’s add cars, refrigerators, doorbell cameras, modern televisions – these all sit at the edge of the cloud with you the user.  
The spirit of “edge-ware” tells a story. 
If we have lovely object-oriented software running on the client-side, or edge, of our applications. And we have lovely software written in a procedural language compiled within the Oracle database, then how does the client/edge talk to the server and the database? Say “Hello” to middleware.

Middleware is like a Babelfish (for fans of Hitchhiker’s Guide books)...