
Berners-Lee 'Sorry' for Slashes (2009) - lelf
http://news.bbc.co.uk/2/hi/technology/8306631.stm
======
pjc50
I don't think it mattered so much for print, but in the early days of the
internet you would hear people on the TV laboriously reading out "haich tee
tee pee colon slash slash double-u double-u double-u dot contoso dot com".

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](https://www.youtube.com/watch?v=Qf_TDuhk3No)
and of course Python's indentation is very at risk of ambiguity.

~~~
jasomill
After years of people mistyping "jasonmill" for "jasomill" in my (originally
university-assigned) email address, I registered _jasomill.at_ so I could
receive email as "jasomilldot", because I guess turning the simple act of
giving out my email address over the phone into an Abbott and Costello routine
sounded like a good idea at the time.

Oh, and you don't need special syntax to write code to be read aloud, to wit,

[https://en.wikipedia.org/wiki/Black_Perl](https://en.wikipedia.org/wiki/Black_Perl)

~~~
jborichevskiy
> turning the simple act of giving out my email address over the phone into an
> Abbott and Costello routine sounded like a good idea at the time

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 a3gx@gmail.com but also want to
self-host. It's a hassle!

~~~
aasasd
I have an address specifically for that—it's just one letter and a few digits,
redirecting to the main account. Works like a charm. Especially when the
native alphabet in the country is not Latin and laboriously explaining which
letter is which is a meme from the phone calls era. Whereas I can just call
digits by the names in the local language, and everyone is familiar with
hearing them.

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.

~~~
smichel17
With my domain name, I've been using a one-letter address for humans but have
found it often confuses people; it doesn't fit the pattern they expect. So,
I've been thinking of switching to domain@domain.tld, which is still obviously
"special" but matches the regular pattern better (and I don't have to spell
out <domain> twice).

A family member has firstname@firstnamelastname.com, which is super nice, but
unfortunately my name and most variants are taken.

------
jttam
I think the greater sin by far was orienting domain names the way that they
are:

com.google.www becomes tab-completable from the most generic element to the
least generic. www.google.com is .. not like that.

~~~
cm2187
I am still waiting for an apology for mathematics and base 10 numbers being
written the wrong way round logically!

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.

~~~
timbit42
I'm still waiting for an apology for base 10. We should be using base 12 or
dozenal.

~~~
cenal
+1

------
sulam
I think he can be forgiven for not anticipating the cost of a couple slashes.
It's probably not as expensive as the addition of 'null' to ALGOL, and that
was actually intended to be very widely adopted!

------
bobosha
I wrote my MS dissertation under TimBL at MIT. I was into semantic web
technologies in the late aughts and chatted with him few times about the
double-slash and web nomenclatures etc.

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.

~~~
tasogare
It’s true the semantic web was a far bigger mistake, although he doesn’t seem
to be sorry for that yet.

~~~
bobosha
I really don't think the semantic web was a "mistake" at all. And as much as
Sir Tim would hate me for saying this, it was (is) still AI - more correctly
Symbolic AI - to collaborate at web-scale.

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.

------
tannhaeuser
If there's anything to "apologize" for with URLs, it would be the use of the
ampersand character for separating query parameters, as these are interpreted
as SGML ERO (entity reference open) character in SGML default concrete syntax,
making SGML parsers see an entity reference in links such as
[http://bla.bla/doc?param=value&otherparam=othervalue](http://bla.bla/doc?param=value&otherparam=othervalue).
XML doesn't help here as it rejects the whole string as attribute value. This
is also IMHO an oversight in the XML and WebSGML specs (the latter allowing to
circumvent the issue via so-called data attributes).

~~~
goto11
URL's were supposed to be universal, not limited to any particular media
format. The ampersand have to be escaped as &amp; in SGML/HTML/XML. Other
formats will need other escapes - no characters are "safe" in all formats.

------
Normal_gaussian
I'm not so negative. The double slash provides a significant visual
differentiator that a single colon would not. It may "waste" paper but it
saves time.

~~~
goto11
In what way does it save time?

~~~
melvinroest
Not grandparent but it saves time the same way syntax highlighting saves time.
You simply recognize the difference faster.

With [http://example.com](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.

~~~
goto11
But humans rarely need to parse URL's into components but often need to read
them aloud or type them. The extra characters make this slower and more error
prone.

For most user interaction purposes the URL is just an opaque string. Only the
browser need to actually parse the URL.

~~~
krapp
I don't think it's been common for most people to need to directly type or
read URLs aloud for a long time.

~~~
goto11
The article is more than a decade old.

------
ricardo81
It's often mentioned that open source has '1000 eyes' to correct and improve
things.

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

~~~
goto11
I don't think size over the wire is the concern. The annoyance is URL's in
print or read aloud and typed manually.

Browsers have since alleviated this by adding "[http://"](http://")
automatically when you type a domain name.

------
quicklime
I wonder if slashdot would’ve taken off had it been called “colondot” instead.

------
cjdell
However, scheme relative URLs (i.e. //example.com/thing.jpg) are useful in
edge cases where you want to request assets using the same protocol as the
document, are they not?

~~~
otterlicious
In an alternative future where the double slashes didn't exist we would just
use the colon.

    
    
        http:example.com/thing.jpg
        :example.com/thing.jpg

~~~
zeroimpl
What would :443/thing.jpg mean? Is that a port or hostname?

~~~
EADGBE
Also, don’t forget user/pass prompt in a URL.

~~~
otterlicious
There is no ambiguity.

 _http:username:password@example.com /thing.jpg_
_http:username:password@example.com:8080@example.com /thing.jpg_

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.

------
dr_j_
Given the standard RFC, the two initial slashes as in scheme:// are critical
in any URL when you need to be able to distinguish between the authority and
path component, as in scheme://authority/path as in
[http://server/file.txt](http://server/file.txt). Otherwise it would be
impossible to know when the server part finished and the path part began
(since the authority or server part is always between the second and third
slashes). Given the article, I think we’re very lucky to have ended up with
this design. But I suppose we could have also arrived at a syntax where the
path begins with the second slash (e.g. scheme:/server/path). In fact
scheme:/path is valid syntax and is simply the contracted URL form of
scheme:///path so at least by today’s RFC definition, scheme:/server/path
wouldn’t work since in this contracted form, the path begins with the very
first slash and that ‘server’ bit wouldn’t be a server at all but also part of
the path.

------
captainmuon
But without the double slash, how do you differentiate between:

proto:relative_to/current_dir

proto:/relative_to/root_of_current_host

proto://otherhost/some/resource

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".

~~~
dybfjbxybff
From Berners-Lee's FAQ: [https://www.w3.org/People/Berners-
Lee/FAQ.html](https://www.w3.org/People/Berners-Lee/FAQ.html)

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](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 "//".

------
osxman
//Accepted.

~~~
thetanil
however Bill \\\ Gates shall never be forgiven

~~~
dnautics
I think you mean Bill \\\\\\\ Gates.

~~~
bryanrasmussen
hmm, yes the \\\\\\\ does make a nice Gate icon.

------
bryanrasmussen
With the quotes I like the read that Sorry as Not Sorry at all, stop bothering
me.

------
mkagenius
.

~~~
daffy
> Also, there are a number of factors at play, a number of different futures
> that could have been resulted if there were no slashes just by chaos
> theory[1]. So, speculating in the hindsight is not fruitful.

This sounds like an argument that one should do whatever, because whatever can
result from it.

~~~
contravariant
Well, at the very least you shouldn't attempt to do something under the
assumption that you can perfectly predict it's result.

