It is a frozen discussion from some of the people who we now hold in fairly high regard on a number of topics that are fairly core to software development.
It is like being able to go back and be a fly on the wall in https://en.wikipedia.org/wiki/Bohr–Einstein_debates# for physics (one can debate about the degree of significance of the topics and individuals - but I'm trying to get back a "this is where things where happening at the time.")
The thing with other great debates - there aren't any transcripts of them. C2 is the best that we have of the early "trying to figure out is now called agile".
In the world before markdown and not wanting to embed html in the page - how do you designate that "this text" is a link to a page with the same name? Btw, it would work best if it was a regex (since this was perl CGI back in the day).
if ($word =~ m/[:upper:]+[:lower:]+([:upper:]+[:lower:]+)+/) {
$word = "<a href=\"${somePrefix}${word}\">${word}</a>"
}
For the record Clifford Adams and I invented the [[free link]] syntax that will plague humanity for a century. We did this on MeatballWiki specifically by request of and to solve the problem for Wikipedia when they were on UseModWiki.
It’s a small world. The more you know.
Also I have enjoyed listening to people complain about our [[creation]] for decades.
The camel-casing was offputting. I don't know if Wikipedia would be where it is today if you guys hadn't come up with the [[free link]] system that made everything far more readable. Thanks :)
Why not [blah](bloo)? Why not __floo flah__? There’s always some other idea that people want to argue.
We had reasons. We already had clean syntax for [https://uri text description] and [https://uri] for numbered citations as footnotes and [#anchor] for named anchors that fit this format of square brackets for everything.
The double square brackets made it clear the inner tokens were not to be parsed at all but were the link itself. Plus they are fast to type and very easy to identify (they look like a [[button]]) and read cleanly as part of a sentence.
Unrestricted html leads to all sorts of nasty problems with user generated content. Things like <script> bringing in Javascript you don't want, or <iframe> pulling in content you don't want (and messing up the page) or in the days of table layout people just putting in </table>, or people with <a href="goatse.cx"> scattered about in links.
So, you limit the text that user generated content is allowed to use. And yet, you still need to figure out a way to allow links between pages within the site - but not allow the person to use an <a> tag.
The way c2 did it was with MixedCaseWords that were easy for a regex to pick out and create link targets to.
MixedCaseWords required no additional special characters to be used or worry about unmatched character pairs.
I liked CamelCase. The brackets are okay. They solve problems, but as you say (or at least imply) they create new problems that can make the code less elegant (IMO). As a user, the brackets are better, but as a programmer it be a headache.
We invented, independently, network hyperlinks before the WWW and they were used in our lab, I don't remember how we did the links. The programmer is no longer with us, but I've messaged the person who had them done to see if he remembers. It only worked on our LAN, so amusing, but not as insanely compelling as the WWW.
I'm curious to see if either CamelCase or [[]] was that natural a mechanism.
CamelCase is easy with a regex and you don't need to parse it. It completely avoids problems like how to handle
[[[a link] with some more text and [[something else]]
Getting into parsing means more complex code and with that complexity comes for the possibility of bugs.
This was also at the time of the Cambrian explosion of Web 2.0 and user content. Lots of different sites took different approaches to handling it. The CamelCase link approach reads kind of clunky but is likely elegantly simple in implementation.
C2 was from the very early days and something that works, well, it works. Going to a full on sanitizer and larger set of allowed html leads forever chasing bugs and implementing features.
Compare also HN and the rather limited feature set. It is better to have something that works and move on rather than forever implementing features (often with backwards compatibility breaking cases).
It is like being able to go back and be a fly on the wall in https://en.wikipedia.org/wiki/Bohr–Einstein_debates# for physics (one can debate about the degree of significance of the topics and individuals - but I'm trying to get back a "this is where things where happening at the time.")
As an aside, there was a community-fork of c2 where part of the community was more interested in communities rather than code. That site is still available - http://meatballwiki.org/wiki/ ( http://meatballwiki.org/wiki/MeatballBackgrounder ) which has a lot of the same charm as c2.
The thing with other great debates - there aren't any transcripts of them. C2 is the best that we have of the early "trying to figure out is now called agile".