1

After rene suggested our site for "historical curiosity" questions on Meta Stack Overflow's It's time to bury [digg], I started wondering whether Digg's API would be on-topic for Retrocomputing.

No, hear me out. After we kind of sort of swallowed the Computing History proposal with our history questions, maybe questions about historical APIs that no longer exist are on-topic here. Stuff like "how did X work?" There's no practical use for these questions now, apart from keeping older systems running… but are those systems old enough?

Just to check: do we want these questions?

  • 2
    I personally would expect to find stuff on retro computing that I can potentially run myself, be it an old OS or an old piece of hardware, emulated if needed. That becomes hard for web based stuff if you don't have source code or any other means to access what is now gone. What remains is q/a based on anecdotal evidence where you can only "scrape" the surface. (all puns intended) – rene Feb 13 at 8:20
4

Personally I consider anything web related not old enough to be Retro or historical, but then I have been running web servers since TBL's 1991 code version!

I know some people see the 1990's as historical and some see 2010 as historical and retro. Depends on your of view.

However if we started having questions on too much stuff that modern we might lose the site distinctiveness.

Your mileage may vary.

(But I'll probably appear in my own version of the "Four Yorkshiremen Sketch")

  • That's a "not for a decade", then? – wizzwizz4 Feb 13 at 17:07
3

For a given technology, ask three questions:

  1. Is the technology still considered "state of the art"? In other words, has something better been sold or freely available?

  2. Does the original manufacturer/author still support the technology?

  3. Is there another StackExchange site that is willing to discuss the technology?

In my humble opinion, if the answers to all three questions are "no", then it is appropriate for Retrocomputing.

The answers are all "no" for Digg's web APIs.


Update:

I'm not 100% sure question #2 is necessary.

To answer @wizzwizz's comment, here are some examples:

  • 8085 processor: NNN --> retro

  • 80386 processor: NNN --> retro

  • Intel Core Solo: NNY --> not retro

  • 6805 microcontroller: (still used for automotive applications) NYN --> not retro

  • Wired Ethernet: (Xerox is OEM) YNY --> not retro

  • WiFi: YYY --> not retro

  • LocalTalk: NNN --> retro

  • MS-DOS: NNN --> retro

  • Windows XP: NNY --> not retro

  • Windows 10: YYY --> not retro

It's really hard to come up with a good YNN example. If something is still state-of-the-art, it is usually still being sold and supported by the OEM, and there is often a SE site willing to discuss it.

The idea is that NNN should qualify as being on-topic. However, there also needs to be a list of topics that are explicitly allowed, even if they have some "yes" answers. Some examples of things that should be explicitly on-topic:

  • Processors with less than 32 bits. Some are NYN, NNY, or NYY.

  • Aspects of serial/UART/RS-232 communication not covered by other SE sites (NYN).

  • System V or BSD Unix (some support on various SE sites).

  • Microsoft Windows versions prior to XP.

  • Classic MacOS (some support on Think Different).

  • USENET (NYN).

  • Adapting an old (on-topic) technology to use a new (off-topic) technology. For example, Ethernet on a Mac Plus.

  • Ooh. Controversial! How would this proposed policy affect other technology? Discontinued iPhones would be NNY, so we wouldn't have to worry about that. – wizzwizz4 Feb 18 at 11:15
  • Upon further reflection: Plan 9 is YNN, USENET is NYN and old Macs are NNY, and I can come up with more very easily, so this system doesn't work for determining what's not retro. – wizzwizz4 Feb 20 at 13:44
  • @wizzwizz4: The idea is that there are two paths to being considered "retro". The implicit path is to answer NNN to the questions. The explicit path is being on a list made by the community, regardless of the answers to the questions. Plan 9, USENET, and classic Macs would be on the explicit list and therefore be on-topic. – DrSheldon Feb 21 at 2:49
  • 1
    You put Wired Ethernet in "not retro". That's certainly the case for 10/100/1000baseT, but what about older implementations such as 10base2 or 10base5 (thinnet and thicknet, iirc)? I'd consider a bus implementation of Ethernet to be retro. – Kaz Feb 21 at 6:51
  • @Kaz all implementations of Ethernet are buses. It's just that sometimes the physical bus is contained entirely within a switch or hub. – JeremyP Feb 27 at 16:13
  • I think question 3 is problematic. For example, there is no question that 6502 is retro and yet, you can discuss it on Stack Overflow. – JeremyP Feb 27 at 16:15
  • @JeremyP: That doesn't matter. There are two paths to being on-topic: the implicit path (the 3 questions), and an explicit path of specific topics. Processors less than 32 bits are retro and should be on the explicit list, regardless of the answers to the 3 questions. – DrSheldon Feb 27 at 17:27
  • @DrSheldon What explicit list? – JeremyP Feb 28 at 9:20
2

Where questions about an old API bring out the development of the service that was provided, then it may be on topic.

I would agree with Brian's answer that the WWW isn't retro. It isn't mentioned in our defining What constitutes Retro?" question. Although we have had some occasional discussion of pre-web internet services in our (sadly underused) chat room. So, pre-web internet services that no longer exist, or at least are no longer widely used, could be counted as retro. (Think ARCHIE, VERONICA, WAIS, Gopher, anon.penet.fi, etc. etc.)

  • Glad you mentioned all those other services we used to run. I had contemplated adding them to my answer, so glad you aired them. Perhaps mention usenet also.. – Brian Tompsett - 汤莱恩 Feb 13 at 10:48
  • @BrianTompsett-汤莱恩 - yes, usenet would count. Which leaves open the possibility of CIX, BIX, Compuserve. We could go on.... – Chenmunka Feb 13 at 10:52
1
  • I'm much apealed by Brian's answer, as my feelings are much the same. I mean, after all, a 386 is modern wizardry, in't it? No use for such power and even less any history there :)))) On an equally serious side, he touches a very important issue - what younger consider 'old' is future technology to old farts like me. Still, their view is as valid as mine. So we may need to be somewhat welcome to such questions (Im not asking to cheer for or being less critical at all).

  • Dr.Sheldons's answer is a great attempt for a more systematic approach. Still, the criteria are even more debatable - to start with the first, 'State of the Art' is a more than just vague term. Try to apply that to the wheel and come again :)) Similar the next one, as presence of an original manufacturer, or author, does not hold any relevance to the item - even more so when talking about software or protocols. And last but not least, the third may need as well refinement, as 'willingness' may not be a great criteria. Some of the examples given do already underline the inherent problems. So if at all, my collection here would go more like this:

    • Does the question target a product/software/protocol still in commercial/public use

    • Is the question not tied to a specific historic issue.

    • Is there another (prefered SE) site where it is clear on topic (not just willing to accept)

    Especially the last should be of prime concern, as they are meant to eliminate generic issues for which specialized sites exist. I have to give that the first one is somewhat debatable, as out of mainstream use and not used is a wide topic - even more for items that never became as mainstream. Think Gopher here - there's still a good number of such servers. Or the underlaying board system for usenet.

  • Now, when it comes to API or protocols, then it gets complete blurry. Sure, the Apple II's Monitor ROM API is a clear yes (*1), but already the IBM PC's BIOS API can be questioned - ast it's basically supported all the way up to today - including floppy calls an PCs where no floppy has been installed for more than a decade.

    So I would prefer to take such questions with a lot of scaptizism about bein on topic at all. It only becomes a clean yes when not tied to the API/protocol in general, but a specific implementation that itself will be on topic.

Now, somewhat unrelated to the core question, but it was touched by it:

  • Which leads to me being uneasy with the term "retro" at all. retro is a zeitgeisty fashion word, not anything marking serious interaction. And it's more toward interaction than history. It's retro to wear a bowler hat to a party, but historic to wear a 1890s outfit (*2) (even with a smartphone instead of a pocket watch)

  • I do believe that, while the name is catchy - like all fashionable terms until they go out of fashion, it is as well misleading and producing some of the irritations/off-topic-votes/clashes we have. RC.SE did basically suck up Computing History, so much is true, And I would say rightful, as it offers a lower hurdle. At the same time it creates the issue discussed here. People coming here for products still up to date, just because they believe them to be old. Like asking about a new kitchen knife on a site for medival swords.

  • In a few years from now Retro will be as outdated to cathegorize this as nowadays youth language of the 90s is (wont even mention the one I picked in the 70s :))

And quite frankly, I have no proposition to solve this ...


*1 - Thinking of it, that's just by feeling. not really by a hard definition.

*2 - Unlike Hollywood told us, not the ten gallon hat was the standard headwear for out west (and back then), but the bowler. It was not only fashionable, but a durable protection gear made for riding and other hard work - the victorian version of a hard hat.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .