The Problem That Built an Industry • Hacker News Board

Re: The Problem That Built an Industry

#41

Post by PaulDavisThe1st » Sun, Apr 12, 2026, 4:35 AM UTC

noAnswer wrote: post #34

zer00eyz wrote: post #22

Earlier quoted context omitted.

> Most of it's here for a reason. Your argument for host os, virtual os, container is the very point im making. Rather than solve for security and installablity, we built more tooling, more layers of abstraction. Each have overhead, security surface and complexity. Rather than solve Rusts performance (at build time), switch to a language that is faster but has more overhead, more security surface, more complexity. Yo…

If you poke it a little you will eventually get Java exceptions. Because the AI article is lying. It is not 60 year old code running on unchanged bare metal. Things got reimplemented over time.

Nowhere does TFA claim that SABRE or Amadeus or other similar systems are using 60 year old code.

Re: The Problem That Built an Industry

#42

Post by conductr » Sun, Apr 12, 2026, 5:04 AM UTC

Interesting they went from 90 minute manual booking time to microseconds. I’m unsure of what the landscape was really like before Unix and such, maybe this was just how software was and everything was a bespoke ordeal. But, it makes me wonder if something less fast could have been “better”. As in, faster to build or easier to maintain/improve, something where we still weren’t talking about wrestling with legacy software that runs the world, those kinds of things.

Even 1 second transaction speed sounds slow today but if it’s replacing a 90 minute manual process I’d rather have that solution now than a microsecond fast solution that takes 5-10 years.

Re: The Problem That Built an Industry

#43

Post by conductr » Sun, Apr 12, 2026, 5:15 AM UTC

outside1234 wrote: post #5

It is interesting to think how AI will potentially change the dynamics back to this from general purpose software. In a world where implementation is free, will we see a return to built for purpose systems like this where we define the inputs and outputs desired and AI builds it from the ground up, completely for purpose?

Probably. It’s already happening with SaaS as an example. I’ve mentioned this on HN a lot in past but my (established) company has been rolling its own CRM and some other tools with AI.

It seems we can build a product ourselves in the same time it would take us to talk to saas vendors and draft the RFP/requirements. We can build it and iterate as the requirements are being forged, so can essentially have completed software with just the features we care about, with full ability to add features in future (something saas doesn’t promise) often before an implementation would even kick off. We’re searching through all our SaaS products and i expect we’ll cut 50% of them in 1-2 years. The ones that are sufficiently complex or regulated have some protection (like accounting systems).

Re: The Problem That Built an Industry

#44

Post by delusional » Sun, Apr 12, 2026, 6:43 AM UTC

PaulDavisThe1st wrote: post #40

alwa wrote: post #23

Earlier quoted context omitted.

Same here—I tolerated the linguistic tics, I found enough meat to keep going, but it’s the conclusions that confuse me. And that feels like the intellectually dangerous part with this sort of LLM writing. For example: > Convergent evolution is real. Every major GDS independently arrived at the same underlying platform. That is not coincidence — it is the market discovering the optimal solution to a specific problem.…

> …the LLM also seems bizarrely impressed that identifiers identify things: [...] >> One 9-character string, sitting in a PNR field, threading across four organisations' financial systems. (emphasis added) It's not that identifiers identify. It's that an identifier identifies the same thing across multiple, independent, entirely distinct systems. There are other examples: credit card numbers, government issued ID num…

> But in general, identifiers have little currency outside the system that generated them

That's clearly wrong, because if it were true we wouldn't be able to identify anything. Identifiers are only useful in so far as some external party assigns a meaning to the identifier. Two systems MUST pick a common idwntifier to discuss a person. They MUST pick an identifier to discuss a technical field. They MUST even pick an identifier to discuss a technical protocol.

Identifiers are everywhere. They'll usually be translated into something internal at the edge of a system, but I bet the PNR is too.

Re: The Problem That Built an Industry

#45

Post by Animats » Sun, Apr 12, 2026, 6:49 AM UTC

This wasn't the first electronic reservation system. It was preceded by the Magnetronic Reservisor, custom built for American Airlines by Teleregister. It didn't use general-purpose computers. It had magnetic drums and remote terminals, but it was not general purpose.

Teleregister built a range of such special-purpose systems, for several airlines, railroads, and air traffic control. General purpose CPUs were both too expensive and too slow for these jobs in the early 1950s. Using a general purpose computer for everything didn't really happen until the minicomputer era in the mid-1970s. SABRE had to wait until general-purpose computers got better.

It's interesting that transaction processing operating systems died out. Tandem's OS worked that way. But the run transaction program once and flush it approach is almost dead. Except, amusingly, for CGI programs, which are true use-once transaction programs, with an inefficient implementation.

[1] https://www.youtube.com/watch?v=F4d-OFDs1hY

[2] https://s3data.computerhistory.org/brochures/teleregister.sp...

Re: The Problem That Built an Industry

#46

Post by kuzivaai » Sun, Apr 12, 2026, 7:06 AM UTC

Fitness for purpose beats fashionable architecture" — this matches something I've seen in automotive. Systems that would fail every modern review but have been running correctly for longer than most of the team has been alive. Looking forward to Part 2 on the PNR.

Re: The Problem That Built an Industry

#47

Post by qazxcvbnmlp » Sun, Apr 12, 2026, 1:59 PM UTC

uxhacker wrote: post #32

arrsingh wrote: post #6

Interesting to note right at the start of the article that they sat on a plane next to each other in 1953 but the formal partnership between AA and IBM was not till 1959 - 6 years later! The article makes it look like all this happened magically fast but in reality a reminder that things take time! >> is almost mythological. In 1953, C.R. Smith, president of American Airlines, was seated next to R. Blair Smith, an IB…

So during the intermittent period IBM and American Airlines were focused on research of the problem. The system was a based on a military messaging system. What is important to note is before SABRE the system used was a sell at will until a stop message was issued. Then sales would be on request. This method is still used between different airline systems today. Before the implementation of SABRE airlines used telepr…

Ive been trying to find a SABRE reference manual somewhere. Do you know if theres any that exist online?

Re: The Problem That Built an Industry

#48

Post by PaulDavisThe1st » Sun, Apr 12, 2026, 2:42 PM UTC

delusional wrote: post #44

PaulDavisThe1st wrote: post #40

Earlier quoted context omitted.

> …the LLM also seems bizarrely impressed that identifiers identify things: [...] >> One 9-character string, sitting in a PNR field, threading across four organisations' financial systems. (emphasis added) It's not that identifiers identify. It's that an identifier identifies the same thing across multiple, independent, entirely distinct systems. There are other examples: credit card numbers, government issued ID num…

> But in general, identifiers have little currency outside the system that generated them That's clearly wrong, because if it were true we wouldn't be able to identify anything. Identifiers are only useful in so far as some external party assigns a meaning to the identifier. Two systems MUST pick a common idwntifier to discuss a person. They MUST pick an identifier to discuss a technical field. They MUST even pick an…

Most identifiers are for use within a system, and are not intended to be GUIDs, semantically. My name is Paul Davis, which functions well enough as an identifier within my lived community, but is pretty useless as "real" identifier for me, which is why other entities I interact with want my birthday, or social security number, or passport or ...

One can cheat on this for airline systems by taking the position that "the system" is the aggregation of all the different systems, not any one of them.

Re: The Problem That Built an Industry

#49

Post by contraposit » Sun, Apr 12, 2026, 3:51 PM UTC

outside1234 wrote: post #5

It is interesting to think how AI will potentially change the dynamics back to this from general purpose software. In a world where implementation is free, will we see a return to built for purpose systems like this where we define the inputs and outputs desired and AI builds it from the ground up, completely for purpose?

A glove (software) that fits the hand (company processes) perfectly.

Re: The Problem That Built an Industry

#50

Post by contraposit » Sun, Apr 12, 2026, 3:59 PM UTC

paulnpace wrote: post #2

> It...handles 50,000 transactions per second with sub-100ms latency on hardware that costs a fraction of an equivalent cloud footprint. It has been doing this for 60 years. Eat that, Bitcoin.

There is a parody youtube video in which one delusional pro-blockchain speaker is talking about how he wants his food to be put on blockchain which was the audio part, the video part was showing how a no-name China restaurant is using oil from sewers to cook food.

https://en.wikipedia.org/wiki/Gutter_oil