This is why a friend of mine has the email address "dot at dot at dot at". Yes, that's uniquely parseable back to one valid rfc822 address that works.
I have occasionally wondered about programming language syntax that might take reading aloud into account. Puncutation ends up sounding like Victor Borge: https://www.youtube.com/watch?v=Qf_TDuhk3No and of course Python's indentation is very at risk of ambiguity.
Oh, and you don't need special syntax to write code to be read aloud, to wit,
Hah! I've been dealing with that for a few years now -- my email is most of my username and spelling it out is fun for neither party.
I've considered getting the shortest, most phonetic-friendly email possible specifically for phone calls; something like email@example.com but also want to self-host. It's a hassle!
Meanwhile, with my main-ish addresses, I've been told that they look like a random jumble of letters or a password. And once I've given one of them over the phone, took ten minutes easily—with confusion as to even how many letters are there.
A family member has firstname.lastname@example.org, which is super nice, but unfortunately my name and most variants are taken.
Fun to help someone via phone map a Windows share who doesn't know the difference/'what's a backslash?'
Fun times reading it out!
"WWW" is one of rare acronyms where it's easier to pronounce the full phrase. :)
I imagine it would help to make code less indented should the author be required to read their work aloud.
open paren sum open paren tick one two three close paren close paren
I like to tell people slash is the one you put in a date.
On my phone at least, the backslash has an clearly and easily accessible shortcut (long press 'w'). Meanwhile, to enter a forward slash, one has to not only tap into the special symbols page, but actually tap again into the SECOND PAGE of that.
Does anyone have any insight as to just what these galaxy brains at Google are thinking?
com.google.www becomes tab-completable from the most generic element to the least generic. www.google.com is .. not like that.
Wikipedia says JANET's e-mail addressing notation was defined by the "Grey Book", and this Usenet thread, http://neil.franklin.ch/Usenet/alt.folklore.computers/200209..., says the Grey Book domain notation comes from the Network Independent File Transfer Protocol (NIFTP aka "Blue Book", which was a different protocol from ARPANET's RFC 354 FTP). This 1990 JANET<->ARPANET e-mail gateway document, http://dotat.at/tmp/JANET-Mail-Gateways.pdf, says that JANET e-mail was transferred using NIFTP, so it would make sense that the domain part of the e-mail address would use NIFTP rules. Both above sources say (explicitly or impliedly) that JANET generally, and NIFTP specifically, were based on X.25, and X.25 uses big-endian addressing.
So on JANET the hierarchical naming scheme predated the e-mail addressing scheme, whereas on ARPANET the reverse is true. Both formats make sense as path dependent outcomes.
 Presumably JANET still adopted user@ because the message format was based on RFC 822, according to that gateway document above, but it was still worth partially deviating from RFC 822, which explicitly defines little-endian domain syntax, because of JANET's pre-existing host addressing scheme.
Same with SQL. I am giving SQL trainings this year, and I have to explain why the server will read your query in a completely different order than how you write it.
As for SQL, you write
SELECT TOP 10 ColName FROM TableName WHERE X = 10 ORDER BY ColName
and the server reads
FROM TableName WHERE X = 10 SELECT ColName ORDER BY ColName TOP 10
It is not "mostly" the right order.
And right to left assignment for mathematics or programming.
Pennsylvania Ave, 1600
Office of the President
President Donald Trump
I think this article either exaggerates or misstates his intent. IIRC, his thinking was the double slash was just a continuation of the path operator in *nix and would represent the "hyper" in hypertext.
Mind you, back then AI was a dirty word, even at MIT, and we had to couch it as "cognitive computing","distributed intelligence" etc.
It is a laudable effort and I still love me some semweb technologies.
With http://example.com it's quicker to distinguish the protocol (http) and the domain name (example.com).
Compare that to http:example.com and it might take a bit longer at first glance (to some people), because they read over the : and then need to do a quick linear scan before they spot the : and are then able to distinguish http vs example.com
Given that one sees a lot of domain names, I'd say it'd save a few hours of everyone's life in the aggregate.
For most user interaction purposes the URL is just an opaque string. Only the browser need to actually parse the URL.
The web has many more than that, I'm sure he can be forgiven for not anticipating every scrutiny about URIs/HTTP/HTML.
Seems like a small nitpick, sites that don't optimise their images or compress text content over the wire puts the space savings from no // into the shade
Browsers have since alleviated this by adding "http://" automatically when you type a domain name.
But they might have picked a different delimiter for that in this alternative future. Or perhaps realized it was a bad idea earlier.
IPv6 addresses are a different story. We definitely would have chosen a different character to delimit IPv6 addresses in this future.
I admit it is hard to grok in the beginning, but all you need to tell non technical people is "you can leave out the http and www" and "hyphen and slash are different symbols".
Q: What is the history of the //?
A: I wanted the syntax of the URI to separate the bit which the web browser has to know about (www.example.com) from the rest (the opaque string which is blindly requested by the client from the server). Within the rest of the URI, slashes (/) were the clear choice to separate parts of a hierarchical system, and I wanted to be able to make a link without having to know the name of the service (www.example.com) which was publishing the data. The relative URI syntax is just unix pathname syntax reused without apology. Anyone who had used unix would find it quite obvious. Then I needed an extension to add the service name (hostname). In fact this was similar to the problem the Apollo domain system had had when they created a network file system. They had extended the filename syntax to allow //computername/file/path/as/usual. So I just copied Apollo. Apollo was a brand of unix workstation. (The Apollo folks, who invented domain and Apollo's Remote procedure call system later I think went largely to Microsoft, and rumor has it that much of Microsoft's RPC system was).
I have to say that now I regret that the syntax is so clumsy. I would like http://www.example.com/foo/bar/baz to be just written http:com/example/foo/bar/baz where the client would figure out that www.example.com existed and was the server to contact. But it is too late now. It turned out the shorthand "//www.example.com/foo/bar/baz" is rarely used and so we could dispense with the "//".
Microsoft had to design a new API for DOS 2.0, as this was the first version to support hard disk drives and hence required support for subdirectories to organize the filesystem. The API was intentionally designed to mimic Unix. 
And it was also intended for devices (such as CON, LPT1, COM1, etc.) to be prefixed with the special directory name 'DEV', as in '/DEV/CON' and '/DEV/LPT1', just to make it feel even more like Unix. 
Apparently the idea was that MS-DOS would be Microsoft's single-user operating system running on cheap 8088 machines, and Xenix would be their "enterprise" multi-user operating system running on high-end 80286 systems, and programs could target a single common DOS/Xenis API and could be run on either OS.
This sounds like an argument that one should do whatever, because whatever can result from it.