Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

gopher

Name: Anonymous 2013-03-05 20:36

You guys why?

Name: Anonymous 2013-03-05 20:50

Most people who "get" Gopher are already using it and instinctively understand why Gopher is still useful and handy. On the other hand, people who inhabit the Web generation after Gopher's decline only see Gopherspace as a prototype Web or a historical curiosity, not a world in its own right -- and more to the point, being only such a "prototype," there is the wide belief that Gopher plays no relevant role in today's Internet and is therefore unnecessary. This has led to many regrettable consequences, such as the neglect of servers and clients, or even active removal of support.
However, there is much to be gained from a heterogeneous network environment where there are multiple methods of information access, and while the Web will confidently remain the primary means of Internet information dissemination, there continues to be a role for Gopher-based resources even in this modern age. Gopher and the Web can, and should, continue to coexist.

The misconception that the modern renaissance of Gopherspace is simply a reaction to "Web overload" is unfortunately often repeated and, while superficially true, demonstrates a distinct lack of insight. From a purely interface perspective, there is no question that Gopher could be entirely "subsumed" under the Web (technical differences to be discussed presently). Very simple HTML menus and careful attention to hierarchy would yield an experience very much like a Gopher menu, and some have done exactly that as a deliberate protest against the sensory overload of modern Web 2.0.

Gopher, however, is more than a confederated affiliation of networks with goals of minimalism; rather, Gopher is a mind-set on making structure out of chaos. On the Web, even if such a group of confederated webmasters existed, it requires their active and willful participation to maintain such a hierarchical style and the seamlessness of that joint interface breaks down abruptly as soon as one leaves for another page. Within Gopherspace, all Gophers work the same way and all Gophers organize themselves around similar menus and interface conceits. It is not only easy and fast to create gopher content in this structured and organized way, it is mandatory by its nature. Resulting from this mandate is the ability for users to navigate every Gopher installation in the same way they navigated the one they came from, and the next one they will go to. Just like it had been envisioned by its creators, Gopher takes the strict hierarchical nature of a file tree or FTP and turns it into a friendlier format that still gives the fast and predictable responses that they would get by simply browsing their hard drive. As an important consequence, by divorcing interface from information, Gopher sites stand and shine on the strength of their content and not the glitz of their bling.

Furthermore, Gopher represents the ability to bring an interconnected browsing experience to low-computing-power environments. Rather than the expense of large hosting power and bandwidth, Gopher uses an inexpensive protocol to serve and a trivial menuing format to parse, making it cost-effective for both client and server. Gopher sites can be hosted and downloaded effectively on bandwidth-constrained networks such as dialup and even low-speed wireless, and clients require little more than a TCP stack and minimal client software to navigate them. In an environment where there are cries for "green computing" and "green data centres," along with large-scale media attention on emerging technology markets in developing nations and the proliferation of wireless technology with limited CPU and memory, it is hypocritical to this author why an established protocol such as Gopher would be bypassed for continued reliance on inefficient programming paradigms and expensive protocols. Indeed, this sort of network doublethink has wrought large, unwieldy solutions such as WAP, a dramatic irony, since in the case of many low-power devices such as consumer mobile phones, the menu format used on them is nearly completely analogous to what Gopher already offered over a decade earlier. More to the point, few in that market segment support the breadth of WAP, and those that can simply use a regular Web browser instead.

Finally, if Web and gopher can coexist in the client's purview, they can also exist in the server's. HTML can be served by both gopher servers and web servers, or a Gopher menu can be clothed in CSS, translated to HTML, and given to a web browser (and in its native form to a Gopher client). This approach yields a natural and highly elegant consequence: if you don't want to choose strictly one way or the other to communicate to your users, choose neither and offer them both a structured low-bandwidth approach or a higher-bandwidth Web view, built from the same content. The precedent of a single serving solution offering both to both clients has been in existence since the early days of the Web with tools such as GN, and today with more modern implementations such as pygopherd. Gopher menus are so trivial to parse that they can easily be HTML-ified with simple scripts and act as the basis for both morphs; what's more, their data-oriented approach means they require little work to construct and maintain, and content creation in general becomes simple and quick with the interface step already taken care of. Plus, many servers easily generate dynamic gopher menus with built-in executable support, providing the interactive nature demanded by many modern applications while still fitting into Gopher's hierarchical format, and virtually all modern Gopher servers can aggregate links to Web content to forge bidirectional connections.

Modern Gopherspace represents the next and greatest way for alternative information access, and the new generation of Gopher maintainers demonstrate a marked grassroots desire for a purer way to get to high-quality resources. Not simply nostalgia for the "way it used to be," modern Gopherspace is a distinctly different population than in the mid 1990s when it flourished, yet one on which modern services can still be found, from news and weather to search engines, personal pages, "phlogs" and file archives. It would be remiss to dismissively say Gopher was killed by the Web, when in fact the Web and Gopher can live in their distinct spheres and each contribute to the other. With the modern computing emphasis on interoperability, heterogeneity and economy, Gopher continues to offer much to the modern user, as well as in terms of content, accessibility and inexpensiveness. Even now clearly as second fiddle to the World Wide Web, Gopher still remains relevant.

Name: Anonymous 2013-03-05 21:06

>>2
gopher-san, post your some good gopher servers

Name: Anonymous 2013-03-05 21:25

>>3
The current list can be found here: gopher://gopher.floodgap.com/1/world/

Name: Anonymous 2013-03-05 21:35

>>4
Oh look, I can get it over HTTP. http://gopher.floodgap.com/gopher/gw?gopher.floodgap.com/1/world

gopher is so fucking useless. There is absolutely nothing unique to it.

Name: Anonymous 2013-03-05 21:39

>>5
How many hundreds of kilobytes of extra bandwidth did you waste by using HTTP?

Name: Anonymous 2013-03-05 21:44

>>5
**               Plain text is beautiful!                **

Name: Anonymous 2013-03-05 22:42

>>5
It has a logical and predictable hierarchal menu-based interface. Anyone who has used a file system should be able to appreciate the beauty of such a thing.

Name: Anonymous 2013-03-05 22:44

>>8
shut up nerd before i stuff in a locker and fuck my hot girlfriend

Name: Anonymous 2013-03-05 22:46

>>8
Why not just use FTP, then?

Name: Anonymous 2013-03-05 22:47

>>10
 
         ∧_∧ fap fap
 fap    ( ´Д`/"lヽ
      /´   ( ,人)   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 fap   (  ) ゚  ゚|  | < "VIVA" "MEXICO"-#CABRONES!!!
      \ \__, |  ⊂llll \_________
        \_つ ⊂llll
        (  ノ  ノ
        | (__人_) \

Name: Anonymous 2013-03-05 22:52

>>6
Do I care?

Name: Anonymous 2013-03-05 22:58

>>12
get out

Name: Anonymous 2013-03-05 23:00

>>2
tl;dr

Name: Anonymous 2013-03-05 23:17

>>13
Fuck you I'm staying and I'll be back tomorrow.

Now how about you actually explain how saving a hundred kilobyte is worth using a shitty, obsolete protocol.

Name: Anonymous 2013-03-06 0:32

>>15
How about you explain how using a newer (but shittier) protocol is worth over 9999900% overhead.

Name: Anonymous 2013-03-06 0:38

>>16
Because it's better, easier, and is used everywhere, whereas your gopher is tun by a bunch of hobbiest and has no real progress being made. One hundred kilobytes? Cry me a fucking river. With my money and ISP I can afford to waste gigabytes a day downloading shit just to promptly delete it. Fuck bandwidth.

Name: Anonymous 2013-03-06 14:46

>>17
fuck you, the modern web is ugly and shitty and filled with normalfags

web 1.0 was the greatest


go on ur facebook and /v/ you stupid faggot

Name: Anonymous 2013-03-06 15:15

Gopher is the ``semantic Web'' that has been touted for years.

Name: Anonymous 2013-03-06 16:28

Accept nothing less than NNTP.

Name: Anonymous 2013-03-06 18:08

>>19
``Le Semantic Web'' is shit. Everyone has to adhere to the lowest common denominator: no images because of blind people, simple English because of retards, 7-bit ASCII because of missing fonts. You might as well use plain text files. The ``Le Semantic Web'' faggots probably think cat(1) and COPY are good text editors.

Name: Anonymous 2013-03-06 21:00

czech 'em

Name: Anonymous 2013-03-08 12:22

>>21
You might as well use plain text files.
I wish!

Name: Anonymous 2013-03-08 12:26

>>21
What is exactly ``the semantic web''? They always use so fucking many buzzwords.

Name: Anonymous 2013-03-08 12:28

http://upload.wikimedia.org/wikipedia/en/3/37/Semantic-web-stack.png
Syntax: XML
I want to kill all the faggots at W3C. Fucking kikes.

Name: Anonymous 2013-03-08 12:34

>>25
It's better than plain SGML.

Name: Anonymous 2013-03-08 12:37

>>26
In the same way a bucket full of horse shit is better than a bucket full of elephant diarrhea, yes.

Name: Anonymous 2013-03-08 12:39

>>25
how's your family? how's your job? haha, goyshit

Name: Anonymous 2013-03-08 12:58

>>27
What would you propose instead?

Name: Anonymous 2013-03-08 13:01

Name: Anonymous 2013-03-08 13:08

>>30
As much as I agree that s-expressions are superior, migrating HTML from being SGML to s-expressions would be extremely unreasonable.

Name: Anonymous 2013-03-08 13:14

>>31
Yeah, which means the web is shit by design and I refuse to do anything for it.

The best thing we can expect is someone to define a new protocol based on S-expressions so a couple of /prog/riders start working on a new browser (even if it's an ncurses one) and browse our obscure version of the Internet.

Name: Anonymous 2013-03-08 13:23

>>30
HTML is more succinct for things in its intended domain thanS-expressions, but still has better error-detection and correction capabilities.

S-expression fans like to say that HTML, SGML, and XML are just bastardized S-expression languages.  SGML partisans often respond that matching end-tags allow for better error-reporting and correction. But for typical HTML content --- mostly running text with a little bit of interspersed markup --- S-expressions are not only harder to correct, but also more verbose.

Consider this partial paragraph from the Ur-Scheme web page <http://pobox.com/~kragen/sw/urscheme>;:

    <li><b>Reasonably fast.</b> It <b>generates reasonably fast
    code</b> &mdash; when compiled with itself, it runs 2½ times
    faster (in user CPU time) than when it's compiled with <a
    href="http://www.call-with-current-continuation.org/"
    >Chicken</a>, 1½ times faster than when it's compiled with...</li>

Now, in traditional HTML, I could have left out the quotes around the URL and the ending `</li>` tag.  Consider this S-expression version:

    (li (b "Reasonably fast.") " It " (b "generates reasonably fast
    code") " " mdash " when compiled with itself, it runs 2½ times
    faster (in user CPU time) than when it's compiled with "
    (a :href "http://www.call-with-current-continuation.org/"
    "Chicken") ", 1½ times faster than when it's compiled with...")

Most of the markup constructs take up more characters here:

    LI: '<li></li>'    (end tag could be omitted in traditional HTML)
        '(li "")'
    B:  '<b></b>'
        '(b "") '
    B:  '<b></b>'      (the second one)
        '" (b "") "'
    --- '&mdash;'
        '" mdash "'
    A:  '<a href=""></a>'  (quotes could traditionally be omitted)
        '" (a :href "" "") "'

If you look at this in a fixed-width font, you'll see that the number of markup characters is detectably smaller in the S-expression serialization of the structure, with the exception of the first two. I maintain that this is typical of the bulk of HTML, especially if you weight it by how often people write it instead of how often it gets sent to browsers.  You can come up with examples where that is not the case:

    <html><head> <title>...</title>
                 <link rel="stylesheet" href="../../style.css" />
                 <meta http-equiv="Content-Type" content="..." />
                 <style type="text/css">...</style></head>...</html>

vs.

    (html (head (title "...") (link :rel "stylesheet" :href "../../style.css")
                (meta :http-equiv "Content-Type" :content "...")
                (style :type "text/css" "...")))

but those structure-heavy, text-light examples with long-winded tag names are relatively rare for people to read and write.

Of course, the cost of terser syntax is often that errors are hard to diagnose.  Ada's end loop, end if, end record, and so on mean that if you leave out an end delimiter, the compiler will usually be able to tell you which one you left out.  At the opposite end of the spectrum, S-expression languages in which all the various kinds of end are spelled as ) can only tell you when they get to the end of the program or to something that doesn't make sense in the current context.

This is not a phenomenon limited to end-delimiters.  In programming languages, there are many other examples of verbosity that helps to diagnose errors; for example, explicit type declarations, mandatory delimiter characters (in cases where the syntax would be no more ambiguous if they were removed from the grammar), sequences of single-line comments, and the conventional parenthesization of the arguments of fixed-arity functions ("ratio square sin x square sin y" is perfectly unambiguous, after all, and Forth, PostScript, Logo, and REBOL use more or less that syntax.).

However, in the case of HTML, the terser syntax does not make errors harder to diagnose; in fact, the HTML syntax permits better error-detection and even error-correction, because all of the end-tags are explicitly labeled.  (It differs from SGML in this regard; in SGML, you can write <li><b/Reasonably fast./ It ...</> and eliminate the redundant end-tags altogether.)

Name: Anonymous 2013-03-08 13:26

>>33
S-exprs would fail with the current HTML standard. Hell, most of the HTML standard is shit (p, q/blockquote, attributes, b/i/em/strong, etc).

If anything, you need to redefine the standard completely. The point here is not migrating HTML to S-exprs, it's abandoning it.

Also, cute post dude. I read it 5 times and I want you to post more.

Name: Anonymous 2013-03-08 13:28

>>33
Oh, right, you probably don't need to quote everything in the ``S-exprized'' version of HMTL.

'quote, macros and syntactic sugar.

Name: Anonymous 2013-03-08 13:32

>>33
The "better error detection" argument always pissed me off. A good S-expression parser is everything you need. If a document doesn't parse, don't show the fucking page and tell the ``programmer'' he's an useless piece of shit, instead of forgiving the ``web developer'' for his mental retardation.

I don't see what's wrong with a strict-as-a-wall-werror-compiler browser. It's the way it should be.

Name: Anonymous 2013-03-08 15:10

>>32
The best thing we can expect is someone to define a new protocol based on S-expressions so a couple of /prog/riders start working on a new browser (even if it's an ncurses one) and browse our obscure version of the Internet.
Let's do it.

Name: Anonymous 2013-03-08 16:55

HTML ... still has better error-detection and correction capabilities.
It had, in the late 90s:
<HTML><BODY><H1>LEL</H1><FONT>h<B>i</B></FONT>

2013:
<html><body><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><span><span>...</span><span>...</span></span>

2013 in Scheme:
(html (body (<my-20-div-expansion-macro>
             (span (span "...")
                   (span "...")))))

Name: Anonymous 2013-03-08 17:23

>>37
But I haven't finished SICP yet. ;_;

Name: Anonymous 2013-03-08 18:48

>>38
2013:

<html><body><script>
function le(){function future(){lel.prototype=loose.anus}(()()()()()({});}
   }();
}();</script><script><script><script><script><script><script><script><script><script><script><script><script><script><script><script><script><script><script><script>SHARE ON LE REDDIT XD<script><script><script><script><script><script>

Name: The Sussman 2013-03-08 19:44

>>39
You never finish SICP, my child.

Name: Anonymous 2013-03-08 20:41

>>41
Bruce Schneier finished SICP. Twice.

Name: Anonymous 2013-03-08 21:26

>>42
SICP finished Bruce Schneier. Twice.

Name: Anonymous 2013-03-08 22:15

>>43
OH NO YOU DIDN'T!

Name: Anonymous 2013-03-09 0:09

anus
anus
anus

Name: Anonymous 2013-03-10 9:12

>>44
OH YES I DID!

Don't change these.
Name: Email:
Entire Thread Thread List