Two-Bit History

Know your stack. Intimately.

There's a very interesting book called "Hollywood Secrets of Project Management Success"†. Actually, IMO only about half of it is interesting, the parts about how Hollywood makes movies is fascinating, the rest of the book seems to me to be a mildly enterprisey pitch for Agile Methods, (of which YMMV.)

THe fascinating thing about Hollywood is that it's old (over a century) and they have developed a system that works: it's rare for a film to go over-budget or over-schedule.

I can't do a proper summary here, but the fundamental gist is that they have detailed plans, that experience says are realistic, and they track those plans closely and deal with divergence systematically.

†https://www.oreilly.com/library/view/hollywood-secrets-of/9780735625693/

Anyway, one of the tools they use, if transposed to the IT industry, would be something like an Inventory of Dependencies. It would list every piece of software that your system depends on along with costs, risk assessments, and alternate dependencies for each. I don't have the book with me or I'd give more details.

My point is, we should do this and usually don't. It's kind of on the company management if you're using, e.g. cURL, and your stack blows up and only then do you discover there's not a great "support story" there, eh?

Taking infrastructure for granted is not how you get reliability. FWIW.

- - - -

BTW, readline and bash are maintained by one volunteer.

> GNU Readline is today…

The semantic web was meant to be the substrate on which personal agents would serve people by doing the type of thing you described but it didn't happen

> The entertainment system was belting out the Beatles’ “We Can Work It Out” when the phone rang. When Pete answered, his phone turned the sound down by sending a message to all the other local devices that had a volume control. His sister, Lucy, was on the line from the doctor’s office: “Mom needs to see a specialist and then has to have a series of physical therapy sessions. Biweekly or something. I’m going to have my agent set up the appointments.” Pete immediately agreed to share the chauffeuring. At the doctor’s office, Lucy instructed her Semantic Web agent through her handheld Web browser. The agent promptly retrieved the information about Mom’s prescribed treatment within a 20-mile radius of her home and with a rating of excellent or very good on trusted rating services. It then began trying to find a match between available appointment times (supplied by the agents of individual providers through their Web sites) and Pete’s and Lucy’s busy schedules.

I think Alan Kay is right, the computer revolution hasn't happened yet. There is much potential that computer networks can unlock but we haven't done the work to unlock it.

--

https://twobithistory.org/2018/05/27/semantic-web.html

Likewise, people dispute that Ada Lovelace was the first programmer, because Babbage and Menabrea had previously created a few simple example programs.

But that downplays her accomplishments too much. She didn't write the "first program" but she was the first to understand what computers would be capable of doing (for example, that by assigning numbers to letters and symbols, computers could do more than simply perform numerical computations), and she was the first to invent foundational control flow structures such as loops and conditionals. Her program was much more rigorously defined and sophisticated than any previous examples.

>The longest program that Menabrea presented was 11 operations long and contained no loops or branches; Lovelace’s program contains 25 operations and a nested loop (and thus branching).

https://twobithistory.org/2018/08/18/ada-lovelace-note-g.html

https://writings.stephenwolfram.com/2015/12/untangling-the-tale-of-ada-lovelace/

https://projectlovelace.net/static_prod/img/Diagram_for_the_computation_of_Bernoulli_numbers.jpg

Worth reading this: https://twobithistory.org/2020/06/28/rest.html

> REST purists often complain, for example, that so-called REST APIs aren’t actually REST APIs because they do not use Hypermedia as The Engine of Application State (HATEOAS). Fielding himself has made this criticism. According to him, a real REST API is supposed to allow you to navigate all its endpoints from a base endpoint by following links. If you think that people are actually out there trying to build REST APIs, then this is a glaring omission—HATEOAS really is fundamental to Fielding’s original conception of REST, especially considering that the “state transfer” in “Representational State Transfer” refers to navigating a state machine using hyperlinks between resources (and not, as many people seem to believe, to transferring resource state over the wire).8 But if you imagine that everyone is just building FIOH APIs and advertising them, with a nudge and a wink, as REST APIs, or slightly more honestly as “RESTful” APIs, then of course HATEOAS is unimportant.

I was surprised to see an Eckart Walther cited as an co-creator of RSS. That was news to me, and I followed the RSS wars since 2000. I thought I knew the names of everyone involved.

Turn's out: he really is. RSS was created by Ramanathan Guha, Dan Libby and Eckart Walther at Netscape first as an RDF Site Summary but only Guha and Libby are named on the original specs. That format then got transformed into a pure XML-based format, then merged with Dave Winer’s format, who then became chief author for the following RSS 0.9x and 2.0 versions. And of course in parallel there were the rivalling RSS 1.0 specs (again RDF based) and the Atom effort.

Should anybody be interested in now obscure histoy: Twobithistory did a longer retrospective of the feed wars:

https://twobithistory.org/2018/12/18/rss.html

And the (slightly disputed) RSS Board, its own fractal in the RSS history, keeps copies of the original specifications:

https://www.rssboard.org/rss-history

I have come to the place where I feel like the word "persistence" when applied to data / knowledge / information in this way is almost offensively reductionist and actually ignorant of the background in the field...

... Just going to put this here, since it's clear the world still hasn't read and absorbed this knowledge, 50 years later.

I wish people would stop retreading the same broken paths over and over again.

https://twobithistory.org/2017/12/29/codd-relational-model.html

https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.pdf

"Future users of large data banks must be protected from
having to know how the data is organized in the machine (the
internal representation) ... A model based on n-ary relations, a normal form for data base relations, and the concept of a universal data sublanguage are introduced."