There was one time I booked a flight. A few days before departure, that particular flight had an accident (Asiana 214 at SFO): I need to check if my flight will still depart as scheduled, so I dig my mailbox and the reservation confirmation email I received months ago(!) now says "Your flight is canceled." Apparently emails can be retroactively rewritten, WTF.
What most likely really happened is that the mail included remote content which got reloaded - and thus changed.
Sorry for being pedantic, but if you sync your mail to your own device (or collect all of it onto your own mail server), you eliminate this risk.
/asiana/status?flight=214&date=2017-03-17
Pretty simple to return a standard "On Time", "Delayed" or "Cancelled" asset.In part because you could use this to implement detection of an email having been "read" when the remote asset is fetched.
(These are just why I find those sorts of emails irritating and sometimes creepy.)
I, on the other hand, get annoying letters form my bank saying I never open their emails, so they won't let me password reset via email anymore. Uh, OK, I'll waste the bank's money calling, I suppose...
Imagine you book a hotel online, fly to another country, arrive at the hotel. "I have a reservation." "May I check your reservation?" "Sure, just a second." You take out your iPhone and open the email: but while you were flying the online booking site had a server meltdown and the data was corrupted.
"Uh, sir, the email says 'Unfortunately, there is no room available at this hotel now. Would you like to check other hotels in the area?' And it's dated three months ago."
"What the..."
I now always print flight/hotel reservations upon booking. That will be safe until nanomachine overlords arrive, I guess. Low-tech solutions FTW.
Unrelated note: I bought that book on Hamilton's methods. Finished it last night. Really enjoyed it outside of the filler, repetative, and overselling parts. The sections on requirements, specs, and spec-to-code (in abstract) were still accurate today for the most part. The HOS method itself reminded me of original LISP where its power and beauty came from how it reduced everything to a few primitives. Like LISP 1.0, there were severe usability & performance problems that prevented wider success. Fun to at least read on an early attempt.
---
Oh hey awesome! Could you see applications for e.g. sitting down with a non-technical person and having them construct working software? That was something that really interested me: the claim that non-programmers could use it.
What you say about how it reminded you of LISP is just fascinating. When I had refined my attempt to implement some HOS-like thing I eventually came up with something that I recognized (later, when I had learned LISP) as a crude subset of that.
Imagine a system that uses a stack, like Forth, but the words/functions are built out of the three primitives (Sequence, Branch, Loop) in, uh, "HOS-style". Give it S-expr syntax and squint and I see a crude proto-LISP. ;-D
(seq ...)
(branch (...) (...))
(loop ...)Alternatively a psychadelic reaction in the brain combined with something like Oxytocin's claimed properties for enhancing trust. Then the person that shows up convinces the person in contact with the paper that what they're told is true. Many possibilities.
" Could you see applications for e.g. sitting down with a non-technical person and having them construct working software?"
What I see is it's like a combination of old CASE tools, a bit of functional programming, logical composition (see LCF provers), and a pile of dishonest marketing (aka "overselling"). I'm currently in a discussion about it elsewhere given Dijkstra personally nuked it while others found problems. Email me if you want and I'll give you a summary of some of that along with controversies that aren't settled yet.