Talk:Computer/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Article organization

Since we want to make this a hub article ala Physics, I think it would be good if we first tried to agree upon an outline. I think it's a lot easier to expand upon an outline than just start writing. Here's what I have in mind, feel free to modify it as you see fit:

• Intro paragraph/section -- Can be partially adapted from what we already have, but this should be done last after the rest of the article is written.
• History -- Also can be adapted from what we have. Keep this brief and link to the various articles on computing history.
• Computing hardware -- Mostly tables of links
  • Very early computers
  • Early electronic computing devices
  • SSI/MSI/LSI computers
  • Microcomputers
    • Embedded computers
    • Personal computers
    • Server class computers -- ehh... maybe
  • Theoretical designs -- quantum, bio/chemical, etc
• Software topics -- Also tables, need some help here
  • Compilers/core libraries
  • Operating systems
  • Applications -- this is obviously super-broad, someone suggest some way to reasonably divide this up further and avoid making this section too huge
• Computer-related professions
  • Engineering
  • IT
  • Programming
• Further reading -- books and such, actual WP articles should be covered above

We also probably should figure out where to fit in some links to articles on computing theory, dunno exactly where to put that. Please critique what I have above. I know I've missed things, but I intend this to only be a starting point. -- uberpenguin @ 2006-08-01 20:21Z

I like that organisation - I have several suggestions.

1. The 'Software topics/Applications' section would certainly explode if we actually named applications in there - and we'd probably get linkspammed into oblivion if we did. So it needs to name classes of application (Word processing, Spreadsheets, Games, Browsers,...) - and we need to keep in mind the non-obvious ones (Industrial control, surveillance, simulation, scientific visualisation...). That's going to be a hard list to maintain - but we can at least find some way to segment the space ('Desktop application types', 'Embedded application types'...etc). The problem is going to be deciding how finely we slice it - do we say "Office applications" or do we have "Spreadsheets, Word processing, Scheduling..." ? I suggest we start to put it together and see how out of hand it gets. We can provide a careful balance between brevity and completeness when we 'go live' with the new article - and perhaps it'll stay well balanced when the masses start tweaking it.
2. I don't agree with "Compilers/core libraries" as a division. Compilers belong in 'Software development tools' - which in turn belongs with 'debuggers' and such as a section down under 'Applications'. Libraries are clearly different though - they are not applications and they aren't operating systems - so they need their own section.
3. We should probably add a topic under 'Software' that covers data formats and transmission protocols - XML, HTML, WAV, JPEG, that kind of thing - and also TCP/IP, NetBIOS, etc. There is a very thin line between what's data and what's code these days - having a section on file formats allows us to talk about things like XML and PHP that skate along the edge without causing major riots about whether they are 'Software' or not.
4. I wonder if we need a top-level section about standards and standards organisations?
5. The hardware section needs something about 'Peripherals' so we can talk about printers, scanners, hard drives, etc.

SteveBaker 22:36, 2 August 2006 (UTC)

Regarding 1, I say we stay broad and vague and only cite very notable examples in few high level categories. We can always use the "not our problem" trick by referencing the main article as Application software or the like. I'm creating a new section on this talk page with our proposed outline, revised per your suggestions. Feel free to edit it directly without concern for trampling on my comments. -- uberpenguin @ 2006-08-03 00:47Z

I'm strongly opposed to naming any actual examples of application programs - no matter how notable. Once you name one - you either name all half million of them or you spend the rest of your natural life reverting linkspam as every two-bit software house puts it's favorite widget into the list. This article is one of the most vandalised in the entire Wikipedia - let's not invite more problems. SteveBaker 00:52, 3 August 2006 (UTC)

That's mostly fine by me, however I don't think we'll be able to avoid naming some things. Think about it, in the category of OSes, you more or less HAVE to cite some examples to define major "types"; Windows NT family, UNIX/BSD families, the TRON family, etc. Any software mention on this article should definitely be very sparing, but I think it would be very hard to create a comprehensive (lofty aspiration, I know) article without name-dropping some software. Anyway, take a look at the outline below and change anything you feel is out of line. -- uberpenguin @ 2006-08-05 03:56Z

I have no problem with naming OS's - firstly there aren't so many of them that we can't name them all - secondly, most of the really obscure ones are OpenSourced and not likely to cause LinkSpamming. The problem with applications is that we could never come even close to naming all of the notable ones - let alone the ones who THINK they are notable. Libraries are a little more tricky - but notable libraries are typically not commercial - or they are bundled with something else...so maybe they aren't a problem either. We can name OpenGL, DirectX and stuff like that without getting into trouble I think. SteveBaker 14:36, 5 August 2006 (UTC)

Okay. The application section will definitely be the hardest to reduce to something sane, so I say we don't worry about it too much until we have to. I'll get started with this outline this weekend and the week after next (I'll be out of town this coming week). -- uberpenguin @ 2006-08-05 15:35Z

Proposed outline

• Intro paragraph/section -- Can be partially adapted from what we already have, but this should be done last after the rest of the article is written.
• History -- Also can be adapted from what we have. Keep this brief and link to the various articles on computing history.
• Computing hardware -- Mostly tables of links
  • Very early computers
  • Early electronic computing devices
  • SSI/MSI/LSI computers
  • Microcomputers
    • Embedded computers
    • Personal computers
    • Server class computers -- ehh... maybe
  • Peripheral devices
  • Theoretical designs -- quantum, bio/chemical, etc
• Software topics -- Also tables, need some help here
  • Libraries
  • Operating systems
  • Data exchange
    • Protocols
    • File formats
  • Applications
    • To be determined...

Perhaps...

• • • Office & Productivity
      • Word Processing
      • Desktop Publishing
      • Presentation
      • Database management
      • Scheduling & Time management
      • Spreadsheet
      • Accounting
    • Internet Access
      • Browser
      • Email/News/Chat Client
      • Web Server
      • Email server
    • Manufacturing
      • CAD
      • CAM
      • Plant management
      • Robotic manufacturing
      • Supply chain management
    • Graphics
      • 2D Paint
      • 2D Vector Drawing
      • 3D Modelling
      • 3D Rendering
      • Video editing
      • Image processing
    • Audio
      • Music editing
      • Music playback
      • Mixing
      • Audio Synthesis
    • Software Engineering
      • Compiler
      • Assembler
      • Interpreter
      • Debugger
      • Text Editor
      • Performance analysis
      • Version control & Source management
      • Shells and Command-line tools
    • Educational
      • Edutainment
      • K thru 9 education.
      • Commercial training systems
      • Flight simulation
    • Computer Games
      • Strategy
      • Arcade
      • Puzzle
      • Simulation
      • 1st Person Shooter
      • Platform
      • Massively Multiplayer
      • Text Adventures
    • Misc
      • Artificial Intelligence
      • Malware scanners & checkers.
      • Installation tools
      • File management
• Computer-related professions
  • Engineering
  • IT
  • Programming
  • Standards organizations
• Further reading -- books and such, actual WP articles should be covered above

The BIG table.

I took the proposed table (above) an dumped it into the article - making links wherever possible (until I ran out of time/stamina!). I think we probably need to lose the rightmost column of the applications section and make the rightmost links just be a comma-separated list under the second-to-the-right boxes. SteveBaker 20:50, 5 August 2006 (UTC)

Agreed. We definitely need to do something along those lines to keep the software table from dominating the rest of it. We can always split the major topics into individual tables if need be. In fact, that's probably better from an organizational standpoint since it will allow us to add headings which will be added to the TOC. Good job so far, though.

Some things to discuss:

• • We could probably do for some concrete examples in the computer hardware section. Especially in the first two sub-sections which don't in themselves have articles that can be linked to. In other words, let's list some notable early computers and notable pre-microcomputer devices as well. I realize this leaves us potentially open to another notability argument like the ABC debacle, but I don't think that's a valid reason to leave the information out. I'll add a few.
  • The Operating system subsection probably could be modified a little bit. I think Solaris can be taken out since it falls under the UNIX category just as easily as do AIX, HP-UX, etc. I'll change the sub-sub category heading to "UNIX/BSD" (BSD is just as important to UNIX as UNIX is) and perhaps mention some major related OSes in a sub-sub-sub-section (heh). I'm also somewhat inclined to stick Linux under UNIX, but I know this will cause a lot of angst, so I'll leave it. Additionally, I think the TRON project may be worthy of mentioning here. ITRON variants, after all, collectively power more devices than any other single embedded OS and probably any single desktop/server OS.
  • Library seems to be lacking... Surely we can think of a better categorization? The three listed are all media libraries and we don't even bother to mention the C standard library.
  • We probably should work in mention of major programming languages.
  • IEEE and IEC should definitely be mentioned as relevant standards organizations.

Actually, the more I think about it, the more I feel we should separate the big table into separate tables along major topic lines. -- uberpenguin @ 2006-08-05 22:34Z

I did some reorganization of the table. However, I've come to the conclusion that we really should separate the table into the major categories and create sub-sections for them. Each subsection should briefly introduce and explain the topic and then display the table. While tables will help this article, I think it's bad form if we totally rely on them as the sole content. The reader should be given SOME help in interpreting what they are looking at. -- uberpenguin @ 2006-08-05 23:41Z

I didn't intend to suggest that this was remotely close to the final form this table must take - I just wanted to put a representative sample of stuff in there so we could get a feel for the scope of the problem - and where the subdivisions could meaningfully be made. It certainly makes it clear that we don't want to split the Application software section up as finely as I did - and that we need a lot more hardware granularity. I agree that splitting the table up with subsection title text between the sections would help. That serves a couple of useful purposes: Firstly it gets the entries into the index at the top of the article - so shortcuts to each sub-table are then possible. It also removes the left-most column from the table which is definitely a good thing.

In the hardware section, I think we should talk about the classic 1st Generation (mechanical), 2nd Generation (Vacuum Tubes), 3rd Generation (Transisitors) and 4th Generation (Silicon chips) of computers. The earlier generation sections can be split further into things that are strictly calculators (anticathera mechanism, difference engine, ABCD, etc) and things that are hard-programmable (Digicomp-I, ENIAC) and things that are truely programmable. We should then subdivide the 4th generation into Mainframe --> Minicomputer --> Microcomputer phases and we can yet further subdivide the microcomputer section up into the 8bit (8080, Z80), the 16 bit (MC6800, Intel 8088), the 32 bit (MC68000, Intel 80486/Pentium) and the latest 64 bit eras. We somewhat need to be guided by the existance or otherwise of suitable articles to link to - but from the noodling around I did today, it's pretty clear that there are articles of some sort on just about every minute aspect of computers so I don't think we have to worry on that score (although once this is done, I think we're going to want to start looking at all of these myriads of poor articles with a view to brushing them up a little).

For the 'Libraries' and 'Standards organisations' sections - I agree that we need to put in a wider set - I was getting table-entry-fatigue by that point - so I just stuck in something. If we get the overall structure right, we can dink around with the actual contents later...even after the new article goes 'live'. SteveBaker 01:06, 6 August 2006 (UTC)

OK - the BIG table is now a handful of almost sanely sized tables. It's much nicer that way. SteveBaker 01:20, 6 August 2006 (UTC)

I like your idea for the organization of the history of computer hardware. Let's go down that route. -- uberpenguin @ 2006-08-06 01:23Z

Excellent! Your wish is my command...(I'm *so* sick of editing tables!). We need to fill out some of the entries - I'm a bit hazy on the really early relay-based machines and I've kinda zoned out on 64 bit systems (It's a CPU! What more do I need to know? I don't even bother to ask their names anymore.) SteveBaker 03:08, 6 August 2006 (UTC)

Frankly the only major relay based computer that I can think of is the Harvard Mark I (from which we get the "Harvard architecture"). Tubes were much more popular than relays for obvious reasons. Anyway, this report by BRL is a good resource for listing major American computers of the early electronic era. -- uberpenguin @ 2006-08-06 03:22Z

Also, the 32/64 bit thing is a little difficult since a lot of common ISAs started out as 32-bit and later had 64-bit extensions or implementations. You could even argue that Intel x86 has been around in 8, 16, 32, and 64 bit forms (though I think most people wouldn't go that far; starting with the 32-bit 80386). I'll add a footnote to this effect. -- uberpenguin @ 2006-08-06 03:36Z

I just noticed that nowhere does the software table mention graphical user environments (or user interfaces in general). I think that's an oversight that we should correct! -- uberpenguin @ 2006-08-06 04:02Z

Yeah - I know. The trouble is that in MS Windows, the GUI is just a part of the OS - but in UNIX'en, it's a totally separate package...and indeed is split into the X11 layer and a window manager layered on top of that. So it's a little difficult - it's also arguable that most of the code in a GUI system is in the libraries that programs link to - gtk for example. SteveBaker 05:45, 6 August 2006 (UTC)

Okay, back from vacation and ready to work on this some more. I think the user interface category is a pretty important subtopic to have under software. I also think it can more or less be split into WIMP, text user interfaces (weak article, but you'll understand what I'm getting at), and Other, for experimental stuff that doesn't fit either category. I have no qualms with listing MS Windows under both the OS and the UI categories since there is no common name I'm aware of that differentiates the core Windows OS from the GUI. We can just interject a footnote that explains why Windows appears in both sections and be done with it. Sound good? -- uberpenguin @ 2006-08-13 02:20Z

Yep - that works for me. So we can have a section on Window managers so we can point to X11, Carbon, MS Windows (as-a-windowing-system), KDE, Gnome, etc. SteveBaker 03:01, 13 August 2006 (UTC)

Careful there... You're treading territory where we might have to make further subdivisions. Sometimes there's a fine line between "window manager" and "graphical desktop environment", especially in the Free software world. I'd rather not get into that particular semantics debate, so I think it's better to just lump all WIMPs into one category and not make mention of the various components therein. For example, X11 is a graphics server (standard), GTK is a widget toolkit, Metacity is a window manager, add all three and some various extra software and you get GNOME, a desktop environment. This article shouldn't get into that level of detail, especially since the lines between those components are often not as easily defined in many other GUIs (like MS Windows and QNX Photon). Unless you have further suggestions, I think the farthest we should go here are the subdivisions of WIMP, text interface, and other. We'd probably be well suited to just mention "complete" graphical environments from the *nix world (KDE, GNOME, Xfce) rather than the components that make them up like X11. As much as I hate to more or less ignore X11 for the purposes of this article, I can't think of a good way to draw category lines that can include X11 and stay terse. -- uberpenguin @ 2006-08-13 03:14Z

Actual article content

So we have (and will continue to) talked a lot about table organization so far, but we need to start thinking about what this article should actually discuss content wise. Tables are awesome for an article like this but they cannot totally carry it, so we need some actual text. Obviously the text should be very lean and only express some fundamentals about computers and let the tables take over from there. I'll throw out a few things I think this article should actually discuss:

• Summary of computer hardware history
• Explanation of what a "computer" is and how the meaning of the term has changed and been assimilated into popular culture. Tie this in with stored program architecture (making a good segue into software).
• Brief discussion of software "from the ground up". That is, explain low-level and high level languages and how we get from, say, C to assembly to machine code. I'm probably not the one to write this in its entirety; it would be better suited for an actual programmer.
• Something about networking... Yet to be determined since I'm not sure what level of detail we should give this one.

Comments? -- uberpenguin @ 2006-08-14 00:23Z

I can certainly explain binary through assembler through low level languages to high level languages from the ground up (I am a programmer). What concerns me more is a way to more firmly get across the message about what a program does with the hardware. In my experience, people outside the industry are pretty terrible at understanding what's going on inside the big beige box. (It doesn't help this article at all - but in the past, I've taught children using a 'kid powered computer' that I put together: http://www.sjbaker.org/steve/software/hiccup.html )

I dunno how specific we want to get with exactly how a program influences hardware. That gets heavily into implementation and is covered somewhat in other articles like CPU. Unless of course we're talking across terms and I'm missing what your concern is... -- uberpenguin @ 2006-08-14 02:40Z

Historical data in BIG table'o'links

There was some editing relating to DOS appearing in the big table of software links and an edit summary that said that DOS didn't belong there because it's pretty much obsolete.

I don't agree with that because an encyclopedia has to talk about historical stuff as well as current things - but that got me to thinking...If we should mention old operating systems as well as new ones...we should talk about IBM timeshare and batch systems and the infamous GEORGE-III - also VAX/VMS, VM/CMS, CP/M, MS-BASIC...and DOS/PCDOS/MSDOS/DrDOS. But would it be better to separate current software links from historical ones? This is a tricky organisational decision.

I think my current preference would be to split some of the categories in the current table into 'Current' and 'Obsolete' sub-categories so that people who aren't interested in dusty old history and just want to see what OS's there are out there right now don't have to click through 50 links to obsolete stuff in order to find what they want.

What about programming languages and such? In the window manager category, we'd need 'GEM' for example. —Preceding unsigned comment added by SteveBaker (talk • contribs)

Yeah, but if we keep going down that road it will be difficult to prevent the tables from becoming huge and duplicating the other huge list pages that already exist. What I really meant to get across is that DOS and Windows don't have much to do with one another any more, and even saying that old Win 9x was "DOS-based" is a real stretch. I just don't think DOS and Windows should be grouped together if we keep the DOS category around. As much as possible we should just list pretty notable examples in each category. I mostly added a bunch of items with the view that I might as well put them down while I have them in mind and we can always trim the fat later. -- uberpenguin @ 2006-08-14 16:25Z

P.S. - Don't worry about discussing minor additions here unless you think there'd be objections to them. It will save time. If you think GEM is significant, by all means add it. -- uberpenguin @ 2006-08-14 16:26Z

Comments

I've had Computer on my watchlist for a good while, since I edited it at some point or other, but just now took a closer look at a Talk reply and discovered this rewrite discussion. Here are my comments (not necessarily in order):

1. Technically, viruses and other malware are software, so....

2. Might note a couple of examples of firmware that users are most likely to deal with, such as in BIOS "ROM"s, optical drives (CD/DVD writers) and routers.

3. Might check some of the software distribution sites to see how they categorize software and what categories they have. One of the oldest such sites is [www.simtel.net Simtel]. You'll also find some of the more obscure categories.

4. The intro says "A computer is a machine...". "Machine" has connotations which may not apply well in the future, such as with organic and/or cellular computers. "Device" is better, but not much.

I'd say, stick with machine. Regardless of the mechanical connotations of the term, "Turing machine" is one of the benchmarks by which we define computers, so I don't see a problem in keeping the term. -- mattb @ 2006-09-06 13:12Z

5. Isn't there already a Software article? If so, then let it be the main article for software, and just summarize it here. This will take care of any complaints about the software topic being large.

Yeah, but we should have at least some software categories here since it's such a major topic. The trick is figuring out how to keep it concise. -- mattb @ 2006-09-06 13:12Z

6. Might want to add that memory can also be I/O (in addition to programs and data) -- the best example, which is used by most modern computers, is video, which is generally memory-mapped.

That's a good point, I'm just not sure if its appropriate for a very high level article like this one. Beyond the stored-program architecture, I think it's a good idea to stay away from computer architecture details here. -- mattb @ 2006-09-06 13:12Z

7. Don't forget supercomputers and grid/distributed computing (such as Beowulf and SETI@Home.

Good catch; we should definitely have some information about massively parallel systems. -- mattb @ 2006-09-06 13:12Z

8. Re: Unix/BSD/Linux, I'd say just call them all "Unix-like" or something similar. Separating them would imply more to the masses than is actually the case, and the wording is sufficiently generic that only fanatics would be offended (they'll be offended no matter what anyway, so &$%^ them).

"Unix-like" is fine by me. -- mattb @ 2006-09-06 13:12Z

9. May want a mention that the von Neumann architecture has also indirectly contributed to our current malware woes.

I sort of think that's a loose connection to make. Many modern ISAs include support for marking memory segments as read-only. I suppose that it is fair to say that the architecture was never designed with security in mind and that the lack of separation between software and data can be a security issue if it's not addressed. We'll see, overall I think this is a very minor point in the context of what we should be covering in this article. -- mattb @ 2006-09-06 13:12Z

10. On the subject of the Windows GUI; it is indeed all built in, but there are several different ones, such as GDI (in Win3x, as I recall), GDIPLUS (in Win95 through XP, I think), and DirectX 10 (in Vista). As for *nix, I seem to recall hearing of some work to merge KDE and Gnome, or something like that.

11. People seem to easily misunderstand what software is and can do. Anyone who reads science fiction (especially the cyberpunk type) can see that some of the authors have a non-technical "knowledge" of what software can do, etc.; from the viewpoint of someone in the field, some of this "science fiction" more closely resembles fantasy.

Agreed... I think Steve commented on this earlier. I'll try to take a stab at explaining how software works in basic terms when I redo the stored program architecture section. I think the hardware/software interaction is probably the most important thing we can convey in this article, so it will probably require a lot of tweaking. -- mattb @ 2006-09-06 13:12Z

12. I think historical stuff (like DOS) should be in the historical section, and mentioned elsewhere only when it is relevant to discussion of modern computers. Note that third-party versions of DOS are still supported, although nowadays mostly aimed at embedded systems.

So you think we should remove legacy OSes from the software table and only mention them where they fit in with other sections like history? I guess I could go along with that. -- mattb @ 2006-09-06 13:12Z

13. I'm not sure that I'd say that Win3x was DOS-based. A better term might be "DOS roots", which understates the matter, but is closer or "uses DOS as a foundation".

14. Instead of (or in addition to) comparing modern embedded computers to a deck of cards, I'd suggest mentioning modern cellphones.

15. Please define or rephrase "regenerative memory".

Heh... "Capacitor memory"... I agree, that's terribly phrased. -- mattb @ 2006-09-06 13:12Z

16. In theoretical future technologies, it seems to me that the distinction between quantum and nanotechnology, and biological and nanotechnology, are likely to be considered nit-picking or irrelevant in the future; may want to clarify that there is considerable overlap here already and it's likely to overlap more in the future.

Sounds good, feel free to make appropriate changes. I know very little about theoretical computing models, so I'm not the one to write this information. -- mattb @ 2006-09-06 13:12Z

17. Fourth Generation probably ought to be in subgroups, with the bit sizes and the computer categories being separate. There are mainframes with bit sizes from 4 to 64, and ditto for embedded, personal, laptop, and server.

The integer range thing was, I think, just used as a method of subdividing microprocessors. I'd be very keen on using a different scheme, though, because I see little reason to even mention bit width in this article. -- mattb @ 2006-09-06 13:12Z

18. What is "Death ray of Ming the Merciless"? I presume it's humor (and yes it would certainly be an output device of some kind), but I don't get the reference; was his death ray computer-controlled? If so, this is probably more appropriate (and the humor more obvious) in a section on automation and/or robotic control.

Joke. Placeholder. Article under (re)construction. Smile. :) -- ~~

19. I would replace ", and the next instruction is fetched." with something like "and the process reapeats with the next cycle.". I would drop the "halt" comment entirely, since you never see it in most programs, as far as I know (I haven't messed with assembler in ages), and it might raise more questions with some people.

That section is going to be totally redone. -- mattb @ 2006-09-06 13:12Z

20. Note that every model of CPU generally has its' own machine language, and there are significant differences betwwen manufacturers, such as Intel and AMD, but they have a large number of instructions which work identically or nearly so on all CPUs in the class.

21. I tend to dislike the word "program", since it tends to be overloaded, as in "TV program", "TV station programming", and so forth. I try to use "Software" where I can, since it is less ambiguous. Consider a program to record TV programs, or something like that; I would expect people to get confused. My suggestion is to say that when most people talk about programs, they really refer to the more generic "software". Many people also misuse it, as in "can you program my computer?". I'd suggest saying that "program" is more of a technical term than anything else.

22. Might want to mention that programming (software engineering) is still an art in many ways.

Heh... I'm not going anywhere near that one. Let's just stick to the facts. -- mattb @ 2006-09-06 13:12Z

23. The "computational" paragraph is unclear. I understand what it means, but it may not be clear to the uninitiated.

I think that's a relic from the old article. Free free to make broad sweeping changes to the software section because we had planned to anyway. -- mattb @ 2006-09-06 13:12Z

24. "few technical reasons why a GUI has to be tied to the rest of an operating system" -- I'm not entirely sure that I agree with this. At the very least, it needs to be tied to the shell, as is done in Unix-like OSes. The problem then is that you get applications which run with one shell but not another, which is why it is made part of the OS in the first place. See my comment above (10) about KDE and Gnome.

25. Human-like robots are being sold in Japan, which is apparently desperate for them due to their aging population; see ASIMO.

26. Only a single main article is listed; should be able to have main articles listed for most of the sections.

Yup. -- mattb @ 2006-09-06 13:12Z

--Scott McNay 05:35, 6 September 2006 (UTC)

Scott, basically we copied what was on the Computer article with the intention of rewriting most of it. So what you see here still contains a lot of stuff that needs to be redone. Unfortunately I haven't been working on this very much lately, but I'd still like to finish our plans here. The thing is, more editors always help, especially for an article with such a broad scope. Please feel free to change whatever you like on this page, just make a note on this talk page explaining what you've done. -- mattb @ 2006-09-06 13:12Z

Boy - that's a lot of great feedback!

1. Technically, viruses and other malware are software, so....

Yep - I agree - those should go inside the software category.

2. Might note a couple of examples of firmware that users are most likely to deal with, such as in BIOS "ROM"s, optical drives (CD/DVD writers) and routers.

Yes - but let's try to avoid becoming too 'PC-centric' and talk about firmware in embedded situations such as cell-phones.

3. Might check some of the software distribution sites to see how they categorize software and what categories they have. One of the oldest such sites is [www.simtel.net Simtel]. You'll also find some of the more obscure categories.

I'm pretty happy with the categories we have. Those sites tend to be a bit PC-centric too.

4. The intro says "A computer is a machine...". "Machine" has connotations which may not apply well in the future, such as with organic and/or cellular computers. "Device" is better, but not much.

In Physics, a machine is defined as a thing for converting energy from one form to another or transferring energy from one place to another. A computer certainly does that (and so would an organic or cellular computer) - but in truth, the important thing is not the 'machine' aspect of converting energy, that's how computers are implemented. I don't like device either. I agree with the sentiment that we talk about Turing machines and Babbages' Engine - and the old name for a CPU was The Mill. The use of mechanical metaphors is not inappropriate. I vote to keep machine.

5. Isn't there already a Software article? If so, then let it be the main article for software, and just summarize it here. This will take care of any complaints about the software topic being large.

Yes - that is the intention - we just kinda fizzled out on the effort. We need each of the large sections to be reduced to a couple of paragraphs preceeded by one or two {{main|xxxxx}} templates. Any important information from this article that isn't in the subservient article needs to be carefully transferred first.

6. Might want to add that memory can also be I/O (in addition to programs and data) -- the best example, which is used by most modern computers, is video, which is generally memory-mapped.

Well, that *was* true in the past. Just try mapping the display of your fancy new nVidia 7900 into CPU space and see where it gets you! The fact that I/O might have a separate address space (8080-style with IN/OUT instructions) - or mapped into the main memory space (68000-style) is somewhat arbitary. In the end, there are addressable locations to which you read and write data. I think the distinction between memory-mapped and I/O-mapped I/O is a strange one in the modern world.

7. Don't forget supercomputers and grid/distributed computing (such as Beowulf and SETI@Home.

Yes - good point.

8. Re: Unix/BSD/Linux, I'd say just call them all "Unix-like" or something similar. Separating them would imply more to the masses than is actually the case, and the wording is sufficiently generic that only fanatics would be offended (they'll be offended no matter what anyway, so &$%^ them).

The percentage of Linux/BSD fanatics in the Wikipedia community is VASTLY higher than in the general public. Offend them at your own risk! In truth, BSD is Unix - they come from the same source code tree - and you could justifiably smoosh them together. Linux, however, is not Unix - although it has similar internal interfaces. So to be completely encyclopeadic about it, we should keep them separate. To not do so would entail smooshing almost every single operating system into either "Windows" or "Not-Windows" - and that would be doing a terrible misservice to our readership. The only OS's that are both not-Windows and not-Unix-like are very, very obscure indeed. If you gave equal prominance to (say) Windows, Unix and BeOS - but left out Linux and MacOSX (Remember - MacOSX is based around BSD) - that would give a very skewed view of the world. So no - I object in the strongest possible terms to this suggestion.

9. May want a mention that the von Neumann architecture has also indirectly contributed to our current malware woes.

No - that's not true. To separate out code and data in main memory (which is what I think you are referring to) might help a little bit - but you wouldn't want to have separate hard drives for code and data - so there is still plenty of scope for malware. Also, much of the software we use is interpreted - Java programs (for example) are data that is read by the Java interpreter - which is code. So Java malware would still be possible. The ability to treat code as data and data as code is key to the success of modern networking. Without the von-Neumann architecture, Wikipedia couldn't exist!

10. On the subject of the Windows GUI; it is indeed all built in, but there are several different ones, such as GDI (in Win3x, as I recall), GDIPLUS (in Win95 through XP, I think), and DirectX 10 (in Vista). As for *nix, I seem to recall hearing of some work to merge KDE and Gnome, or something like that.

I'm not a Windows expert - if there are distinguishable Windows GUI's then lets list them. But the KDE/Gnome merge that (IIRC) RedHat attempted would only merge two out of the dozen or so window managers that are in common use in the *nix world.

11. People seem to easily misunderstand what software is and can do.

Yes indeed.

Anyone who reads science fiction (especially the cyberpunk type) can see that some of the authors have a non-technical "knowledge" of what software can do, etc.; from the viewpoint of someone in the field, some of this "science fiction" more closely resembles fantasy.

Right - and attacking those misconceptions are at the heart of what I want to achieve here.

Agreed... I think Steve commented on this earlier. I'll try to take a stab at explaining how software works in basic terms when I redo the stored program architecture section. I think the hardware/software interaction is probably the most important thing we can convey in this article, so it will probably require a lot of tweaking. -- mattb @ 2006-09-06 13:12Z

Yes. I want to get this down right. I don't think it belongs in the Computer article - it needs to go into one of the subservient articles - with the usual two paragraph summary placed here.

12. I think historical stuff (like DOS) should be in the historical section, and mentioned elsewhere only when it is relevant to discussion of modern computers. Note that third-party versions of DOS are still supported, although nowadays mostly aimed at embedded systems.

What is history? The problem with computers is that something we used last year is history this year. I think perhaps a better approach is to divide the history into defined 'eras' - the computer generations forming the natural boundaries. This approach is taken in (for example) the History of automobiles article. That way, we have a recent history section that says "Fourth generation to present day" and avoids the need to artificially decide when (for example) DOS became obsolete. I should point out that a major new version of the OpenSourced DOS was released just last week - so there must still be a fairly vigerous user community. We also heard on Slashdot the other day that some criminal had his Commadore 64 confiscated by police - who found that they couldn't understand the darned thing and were unable to investigate the files that were on it! When the Y2K thing was a big worry, companies who were still doing payroll on 20 year old machines came out of the woodwork demanding fixes to their antique software. So beware - things may not be as obsolete as you think!

13. I'm not sure that I'd say that Win3x was DOS-based. A better term might be "DOS roots", which understates the matter, but is closer or "uses DOS as a foundation".

In order to run Windows 3.1, you first booted into DOS and then typed 'WINDOWS' to boot Win3.1 - so yes, it most definitely was DOS-based.

14. Instead of (or in addition to) comparing modern embedded computers to a deck of cards, I'd suggest mentioning modern cellphones.

Right - the 'Deck of cards' analogy is long outdated...so is 'the size of a cellphone'. I just bought a computer that's inside a USB dongle less than 1" long which includes Linux and a complete web-server. The 2cm x 2cm die of an nVidia 7900 graphics chip contains 16 vertex processors and 48 fragment processors - each of which is an essentially separate computer. 64 computers in a 2cm die makes each one about 2.5mm across...so maybe "The size of a grain of rice" is the best size description. Embedded computers can be almost arbitarily small.

15. Please define or rephrase "regenerative memory".

I agree.

Heh... "Capacitor memory"... I agree, that's terribly phrased. -- mattb @ 2006-09-06 13:12Z

Urgh! You're right. Do you mean "Memory which is erased by the act of reading it" - in which case magnetic core stores fit that bill too. However, you can argue that when the read-then-rewrite cycle is performed automatically - then it's not regenerated anymore. On some very old core-store computers, you had to explicitly rewrite memory after you read it using software instructions. The idea being that if you didn't need the value any more after you'd read it, then the computer could run faster by not regenerating the memory automatically. However, I'd be hard pressed to name a computer that was like that.

16. In theoretical future technologies, it seems to me that the distinction between quantum and nanotechnology, and biological and nanotechnology, are likely to be considered nit-picking or irrelevant in the future; may want to clarify that there is considerable overlap here already and it's likely to overlap more in the future.

I don't think we know that. Quantum computing is very, very different than anything else because of 'superposition' trickery in which the qubits can simultaneously hold every possible solution to a problem. A nanotechnological/mechanical 'pushrod' memory would be just like conventional RAM and hold a definite 1 or a 0. So those are utterly distinct. It may turn out that biological and quantum technologies may one day merge - but right now, they are entirely different. The people who are using DNA replication to perform massively parallel 'travelling salesman' type calculations in a bucket full of slime are doing something quite different from the nanotechnologists like Drexler who envisage Babbage-machine types of technology shrunk down to atomic scales. So no - I disagree. Those are all very distinct field right now. If they ever do merge, we can change the article - but there is absolutely zero evidence that this has in fact already happened - not that it is likely to do so in the near future.

17. Fourth Generation probably ought to be in subgroups, with the bit sizes and the computer categories being separate. There are mainframes with bit sizes from 4 to 64, and ditto for embedded, personal, laptop, and server.

Dangerous. We are talking about history here. The history of the technology doesn't go in nice linear bus width increments like you think. We had Amdahl machines with 64 bits before we had 4 bit microprocessors. So no - I strongly disagree. The generations are about technology leaps - mechanical/relays/vacuumtubes/transistors/MSI/LSI - not about bus widths.

18. What is "Death ray of Ming the Merciless"? I presume it's humor (and yes it would certainly be an output device of some kind), but I don't get the reference; was his death ray computer-controlled? If so, this is probably more appropriate (and the humor more obvious) in a section on automation and/or robotic control.

It was late - I was tired - this is a temporary article. I wondered how long it would take someone to notice it! Feel free to remove it!

19. I would replace ", and the next instruction is fetched." with something like "and the process reapeats with the next cycle.". I would drop the "halt" comment entirely, since you never see it in most programs, as far as I know (I haven't messed with assembler in ages), and it might raise more questions with some people.

The 'HALT' instruction is very common in embedded situations since it puts the processor into a powered down state. Please stop thinking in PC terms. Also, the concept of a program halting is key to many theoretical computational issues such as (obviously) "The Halting Problem".

20. Note that every model of CPU generally has its' own machine language, and there are significant differences betwwen manufacturers, such as Intel and AMD, but they have a large number of instructions which work identically or nearly so on all CPUs in the class.

Again, you are looking only at PC clones. Look at embedded systems - they most certainly are not remotely cross-compatible.

21. I tend to dislike the word "program", since it tends to be overloaded, as in "TV program", "TV station programming", and so forth. I try to use "Software" where I can, since it is less ambiguous. Consider a program to record TV programs, or something like that; I would expect people to get confused. My suggestion is to say that when most people talk about programs, they really refer to the more generic "software". Many people also misuse it, as in "can you program my computer?". I'd suggest saying that "program" is more of a technical term than anything else.

The term is certainly overloaded in other fields - but software is too vague. Software includes data files. A "Software package" might include many programs - or no programs at all (just libraries). Within the field of computing, the term has a very precise meaning.

22. Might want to mention that programming (software engineering) is still an art in many ways.

Yes. Something I wish I could get my boss to understand! It truly is an art form. Any experienced programmer will look at two pieces of code - both of which solve the problem at hand - both of which are equally fast and space-efficient and he'll say "Wow! That's a beautiful piece of code - but this other one is ugly!" - that's art. Furthermore, show those same two pieces of code to another programmer and he'll probably come up with the opposite view. I run a team of 5 or so programmers who all work on the same 1 million lines-of-code application - and I can tell who wrote what bits just from the coding style alone. It's like looking at the brush strokes of a grand master oil painting and saying "I can tell that so-and-so didn't paint this - it was his understudy". Yes - it's most definitely an art.

23. The "computational" paragraph is unclear. I understand what it means, but it may not be clear to the uninitiated.

Yeah - that's got to change.

24. "few technical reasons why a GUI has to be tied to the rest of an operating system" -- I'm not entirely sure that I agree with this. At the very least, it needs to be tied to the shell, as is done in Unix-like OSes. The problem then is that you get applications which run with one shell but not another, which is why it is made part of the OS in the first place. See my comment above (10) about KDE and Gnome.

Yep - that's got to go. The GUI patently obviously DOESN'T need to be tied to the OS because there are plenty of examples (KDE, etc) of GUI's that are perfectly usable that aren't tied to the kernel. They aren't tied to the shell either. The Window manager ("GUI" is a vague term here) is at the same level in the software heirarchy as the shell - it is in fact possible to talk of "graphical shells" and "command line shells". But you can launch a graphical shell from a command line shell and vice-versa (at least under *nix). So one is not 'above' the other in the hierarchy.

25. Human-like robots are being sold in Japan, which is apparently desperate for them due to their aging population; see ASIMO.

Yes - but a robot is just a machine that happens to contain a computer. In fact, if you watch shows like "Robot wars" in which computers are hardly ever present, it is aparrent that the term "Robot" has lost it's connotation of "A mobile machine driven by a computer". Robotics is a separate field from Computing and I don't think we need to say very much about it here. Robotics are an application of computers - just like cellphones, greetings cards that play "Happy Birthday" when you open them, space craft, cars, PC's, TV remotes, Furbies, dish washers....why should we single out robots for special mention?

26. Only a single main article is listed; should be able to have main articles listed for most of the sections.

Yes - we aren't done yet.

SteveBaker 15:46, 6 September 2006 (UTC)

Comments, new section

(Getting long) (ouch, I'm still copying most of it. Oh well, at least it's now spaced out more, to separate individual items)

4. The intro says "A computer is a machine...". "Machine" has connotations which may not apply well in the future, such as with organic and/or cellular computers. "Device" is better, but not much.

In Physics, a machine is defined as a thing for converting energy from one form to another or transferring energy from one place to another. A computer certainly does that (and so would an organic or cellular computer) - but in truth, the important thing is not the 'machine' aspect of converting energy, that's how computers are implemented. I don't like device either. I agree with the sentiment that we talk about Turing machines and Babbages' Engine - and the old name for a CPU was The Mill. The use of mechanical metaphors is not inappropriate. I vote to keep machine.

Telling people that their brain is actually a machine may not go over to well with some. :) --Scott McNay 03:06, 7 September 2006 (UTC)

An encyclopedia is not for telling people what they want to hear - it's about telling them the truth - which is often uncomfortable. The brain is not only a machine - but it's also a computer. The marvel of the thing is how insanely dense it is. Several years ago I read that the entire DRAM production of the world for one entire year had just reached the equivelent of one human brain. We're a bit beyond that now - but a modern PC has about the processing power of an earthworm. SteveBaker 03:56, 7 September 2006 (UTC)

In this context, I'll agree. --Scott McNay 05:44, 7 September 2006 (UTC)

6. Might want to add that memory can also be I/O (in addition to programs and data) -- the best example, which is used by most modern computers, is video, which is generally memory-mapped.

Well, that *was* true in the past. Just try mapping the display of your fancy new nVidia 7900 into CPU space and see where it gets you! The fact that I/O might have a separate address space (8080-style with IN/OUT instructions) - or mapped into the main memory space (68000-style) is somewhat arbitary. In the end, there are addressable locations to which you read and write data. I think the distinction between memory-mapped and I/O-mapped I/O is a strange one in the modern world.

I used to do a lot of video fiddling. That was many years ago, though. I have no experience with modern video cards, though, with their advanced features, aside from putting one in and watching the impressive graphics. --Scott McNay 03:06, 7 September 2006 (UTC)

Graphics is my livelyhood - you can take that one to the bank. The ability to direct access display memory is really only still there so a PC can boot. Once it's up and running, you're locked behind a device driver that DMA's command packets to the firmware. The interface is more like a network connection than a peripheral in the classic sense. SteveBaker 03:56, 7 September 2006 (UTC)

A serial-like connection like that is probably easier for the GPU to handle; it doesn't need to second-guess what the application is doing with its' memory space. --Scott McNay 05:44, 7 September 2006 (UTC)

Right. You don't want contention between the CPU and GPU for RAM access - and you also don't want potential screwups when the CPU and GPU are accessing the same locations. It's just cleaner to require all accesses to go through the GPU. SteveBaker 05:40, 1 November 2006 (UTC)

8. Re: Unix/BSD/Linux, I'd say just call them all "Unix-like" or something similar. Separating them would imply more to the masses than is actually the case, and the wording is sufficiently generic that only fanatics would be offended (they'll be offended no matter what anyway, so &$%^ them).

The percentage of Linux/BSD fanatics in the Wikipedia community is VASTLY higher than in the general public. Offend them at your own risk! In truth, BSD is Unix - they come from the same source code tree - and you could justifiably smoosh them together. Linux, however, is not Unix - although it has similar internal interfaces. So to be completely encyclopeadic about it, we should keep them separate. To not do so would entail smooshing almost every single operating system into either "Windows" or "Not-Windows" - and that would be doing a terrible misservice to our readership. The only OS's that are both not-Windows and not-Unix-like are very, very obscure indeed. If you gave equal prominance to (say) Windows, Unix and BeOS - but left out Linux and MacOSX (Remember - MacOSX is based around BSD) - that would give a very skewed view of the world. So no - I object in the strongest possible terms to this suggestion.

Considering the topic of this article, I'd expect the majority audience to be "the masses", not fans. I suspect that you'd have trouble explaining the difference between Linux and the various Unix variants in such a way that most readers wouldn't then say "ok, so, again, what's the difference?". However, I grant that there's probably enough turf war already. :) Anyway, my point pretty much is that it's likely to be a waste of space listing anything other than OSes that people are likely to have heard of; anything else should be in the "Operating Systems" article. --Scott McNay 03:06, 7 September 2006 (UTC)

Once again - our purpose here is to educate. If we only list the things people know about, we're getting nowhere! SteveBaker 03:56, 7 September 2006 (UTC)

Ok, let me re-do again: this is an article on "computers"; there should be no more than a handful or so of OSes listed; readers desiring more detail should go to the OSes article. OSes listed here may include one or two that people may not have heard of, BUT are used in devices or services that they may know about, such as Symbian OS in cell phones, or Beowulf clusters doing weather analysis (or whatever; I'm sure Beowulf is used for something which is known to many people). --Scott McNay 05:44, 7 September 2006 (UTC)

Beowulf clusters are used for lots of things - but not many of them are noticable to the general public. That doesn't matter though - our task is to educate - so anything the general public doesn't know about is especially deserving of our efforts. I guess the ultimate example of a Beowulf cluster would be the 'Googleplex' - the cluster that runs the Google application. Also the large 'render farms' that the movie studios use for making stuff like Toy Story. I actually work with Beowulf clusters in my job - which is designing graphics software for serious military flight simulators. SteveBaker 05:40, 1 November 2006 (UTC)

9. May want a mention that the von Neumann architecture has also indirectly contributed to our current malware woes.

No - that's not true. To separate out code and data in main memory (which is what I think you are referring to) might help a little bit - but you wouldn't want to have separate hard drives for code and data - so there is still plenty of scope for malware. Also, much of the software we use is interpreted - Java programs (for example) are data that is read by the Java interpreter - which is code. So Java malware would still be possible. The ability to treat code as data and data as code is key to the success of modern networking. Without the von-Neumann architecture, Wikipedia couldn't exist!

I didn't say that von Neumann architecture was bad; the benefits would seem to massively outweigh the problems. Nevertheless, it would be a trivial point to make in this type of article, so might as well drop this item. --Scott McNay 03:06, 7 September 2006 (UTC)

10. On the subject of the Windows GUI; it is indeed all built in, but there are several different ones, such as GDI (in Win3x, as I recall), GDIPLUS (in Win95 through XP, I think), and DirectX 10 (in Vista). As for *nix, I seem to recall hearing of some work to merge KDE and Gnome, or something like that.

I'm not a Windows expert - if there are distinguishable Windows GUI's then lets list them. But the KDE/Gnome merge that (IIRC) RedHat attempted would only merge two out of the dozen or so window managers that are in common use in the *nix world.

Ignore this; mostly nitpicking on my part. :) Applications need to be updated to run on the newer GUI versions, but the GUIs are not interchangeable; one merely supersedes the older ones. --Scott McNay 03:06, 7 September 2006 (UTC)

11. People seem to easily misunderstand what software is and can do.

Yes indeed.

Anyone who reads science fiction (especially the cyberpunk type) can see that some of the authors have a non-technical "knowledge" of what software can do, etc.; from the viewpoint of someone in the field, some of this "science fiction" more closely resembles fantasy.

Right - and attacking those misconceptions are at the heart of what I want to achieve here.

Agreed... I think Steve commented on this earlier. I'll try to take a stab at explaining how software works in basic terms when I redo the stored program architecture section. I think the hardware/software interaction is probably the most important thing we can convey in this article, so it will probably require a lot of tweaking. -- mattb @ 2006-09-06 13:12Z

Yes. I want to get this down right. I don't think it belongs in the Computer article - it needs to go into one of the subservient articles - with the usual two paragraph summary placed here.

The other day, I read "Spin State", by Chris Moriarty. There are several scenes in which the protagonist is using virtual reality (in modern terms) to explore remote virtual scenarios, and is trapped by antagonists, unable to return to her body. The book is straight cyberpunk, no psychic stuff.

This may be related to a problem that many people seem to have distinguishing between memory and permanent (disk drive) storage, and understanding that loading something from the hard drive into memory doesn't cause it to disappear from the hard drive. Oh, and as long as I'm ranting, please save me from people who think "computer" refers to the monitor, and say "hard drive" when they talk about the computer ("can you put a DVD writer in my hard drive?"). I don't mind "CPU" as an abbreviation for "computer", though. --Scott McNay 03:06, 7 September 2006 (UTC)

Well, I flinch everytime I hear someone make that mistake - but again, our mission here it to prevent that kind of thing. SteveBaker 03:56, 7 September 2006 (UTC)

Which mistake? CPU instead of computer? I sometimes use it as an abbreviation when writing, but never when talking. --Scott McNay 05:44, 7 September 2006 (UTC)

CPU instead of computer is what makes me flinch. I open up the case of what is undoubtedly called a computer - and inside I can point to the little piece of it that is the CPU. Now, some people call the big beige box with the drive slots on the front and the connectors on the back "The CPU box" - and that's something I mind less because it distinguishes it as that part of the totality of the computer that happens to contain the CPU...much as people might refer to "The Bedroom" when that room in fact contains quite a lot of other furniture. SteveBaker 05:40, 1 November 2006 (UTC)

12. I think historical stuff (like DOS) should be in the historical section, and mentioned elsewhere only when it is relevant to discussion of modern computers. Note that third-party versions of DOS are still supported, although nowadays mostly aimed at embedded systems.

What is history? The problem with computers is that something we used last year is history this year. I think perhaps a better approach is to divide the history into defined 'eras' - the computer generations forming the natural boundaries. This approach is taken in (for example) the History of automobiles article. That way, we have a recent history section that says "Fourth generation to present day" and avoids the need to artificially decide when (for example) DOS became obsolete. I should point out that a major new version of the OpenSourced DOS was released just last week - so there must still be a fairly vigerous user community. We also heard on Slashdot the other day that some criminal had his Commadore 64 confiscated by police - who found that they couldn't understand the darned thing and were unable to investigate the files that were on it! When the Y2K thing was a big worry, companies who were still doing payroll on 20 year old machines came out of the woodwork demanding fixes to their antique software. So beware - things may not be as obsolete as you think!

Ok, agreed. BTW, I've yet to see a good explanation of why the US (most dependent upon technology at the time) did not have severe problems when Y2K came around. It pretty much fizzled (which is definitely a good thing!), and the suggestions that it was mostly hype doesn't seem adequate, and suggestions that the public warnings about it did the trick also doesn' seem adequate, both based on what I'd been hearing. --Scott McNay 03:06, 7 September 2006 (UTC)

I think it fizzled because enough people were terrified of the consequences that they knuckled down and fixed it. It's not like it was a surprise or was hard to plan for! It's interesting though that the 'billenium' bug (when all UNIX machines had their dates wrap throught the 1,000,000,000th second) went entirely unreported - even though it had the exact same chance of blowing up in our faces. There have been other critical numeric overflow issues too - when the Dow Jones index hit 10,000 for example. SteveBaker 03:56, 7 September 2006 (UTC)

I'm honestly surprised that there haven't been more events due to such problems. --Scott McNay 05:44, 7 September 2006 (UTC)

13. I'm not sure that I'd say that Win3x was DOS-based. A better term might be "DOS roots", which understates the matter, but is closer or "uses DOS as a foundation".

In order to run Windows 3.1, you first booted into DOS and then typed 'WINDOWS' to boot Win3.1 - so yes, it most definitely was DOS-based.

It was the same with Windows 95, 98, and 98SE (but not ME); Windows simply got loaded automatically. --Scott McNay 03:06, 7 September 2006 (UTC)

That's what I thought - but the last version of Windows I actually used was 3.1.1 - so I thought I'd stick with what I knew! SteveBaker 03:56, 7 September 2006 (UTC)

15. Please define or rephrase "regenerative memory".

I agree.

Heh... "Capacitor memory"... I agree, that's terribly phrased. -- mattb @ 2006-09-06 13:12Z

Urgh! You're right. Do you mean "Memory which is erased by the act of reading it" - in which case magnetic core stores fit that bill too. However, you can argue that when the read-then-rewrite cycle is performed automatically - then it's not regenerated anymore. On some very old core-store computers, you had to explicitly rewrite memory after you read it using software instructions. The idea being that if you didn't need the value any more after you'd read it, then the computer could run faster by not regenerating the memory automatically. However, I'd be hard pressed to name a computer that was like that.

I'd suspect that if you find such a device, it's probably embedded. --Scott McNay 03:06, 7 September 2006 (UTC)

Right - so it's pretty academic to talk about the memory needing to be regenerated unless you have to do it explicitly in software. Ironically, push-rod memory (such as might come about in Nanotech processors) might need to be regenerated - so this isn't just some kind of historical anachronism. SteveBaker 03:56, 7 September 2006 (UTC)

16. In theoretical future technologies, it seems to me that the distinction between quantum and nanotechnology, and biological and nanotechnology, are likely to be considered nit-picking or irrelevant in the future; may want to clarify that there is considerable overlap here already and it's likely to overlap more in the future.

I don't think we know that. Quantum computing is very, very different than anything else because of 'superposition' trickery in which the qubits can simultaneously hold every possible solution to a problem. A nanotechnological/mechanical 'pushrod' memory would be just like conventional RAM and hold a definite 1 or a 0. So those are utterly distinct. It may turn out that biological and quantum technologies may one day merge - but right now, they are entirely different. The people who are using DNA replication to perform massively parallel 'travelling salesman' type calculations in a bucket full of slime are doing something quite different from the nanotechnologists like Drexler who envisage Babbage-machine types of technology shrunk down to atomic scales. So no - I disagree. Those are all very distinct field right now. If they ever do merge, we can change the article - but there is absolutely zero evidence that this has in fact already happened - not that it is likely to do so in the near future.

I've seen theories (Roger Penrose, as I recall) that the brain is already a quantum computer. Many of the quantum computing work that I've read about seems to involve nano-scale items. --Scott McNay 03:06, 7 September 2006 (UTC)

Yeah - but those are definitely "out there" in terms of the mainstream. However, even if the brain were quantum-based, there is still a major difference between the way that present day researchers are looking at quantum, biological and nano-scale mechanical computers. SteveBaker 03:56, 7 September 2006 (UTC)

17. Fourth Generation probably ought to be in subgroups, with the bit sizes and the computer categories being separate. There are mainframes with bit sizes from 4 to 64, and ditto for embedded, personal, laptop, and server.

Dangerous. We are talking about history here. The history of the technology doesn't go in nice linear bus width increments like you think. We had Amdahl machines with 64 bits before we had 4 bit microprocessors. So no - I strongly disagree. The generations are about technology leaps - mechanical/relays/vacuumtubes/transistors/MSI/LSI - not about bus widths.

Take a closer look at the table; it lists both bits and types. --Scott McNay 03:06, 7 September 2006 (UTC)

18. What is "Death ray of Ming the Merciless"? I presume it's humor (and yes it would certainly be an output device of some kind), but I don't get the reference; was his death ray computer-controlled? If so, this is probably more appropriate (and the humor more obvious) in a section on automation and/or robotic control.

It was late - I was tired - this is a temporary article. I wondered how long it would take someone to notice it! Feel free to remove it!

I don't have a problem with humorous items, but I think that they should also be correct (considering that this is an encyclopedia), instead of being a flop (or gigaflop). :) --Scott McNay 03:06, 7 September 2006 (UTC)

I honestly would never have left it in there once the article goes "live". SteveBaker 03:56, 7 September 2006 (UTC)

19. I would replace ", and the next instruction is fetched." with something like "and the process reapeats with the next cycle.". I would drop the "halt" comment entirely, since you never see it in most programs, as far as I know (I haven't messed with assembler in ages), and it might raise more questions with some people.

The 'HALT' instruction is very common in embedded situations since it puts the processor into a powered down state. Please stop thinking in PC terms. Also, the concept of a program halting is key to many theoretical computational issues such as (obviously) "The Halting Problem".

Nevertheless, it still feels to me like excessive detail for this type of article. I think it would be appropriate an an article on assembly or machine language, or on embedded programming, or OS-level programming (waiting for the next interrupt), all of which are well beyond this scope of this article. --Scott McNay 03:06, 7 September 2006 (UTC)

OK - whatever. SteveBaker 03:56, 7 September 2006 (UTC)

20. Note that every model of CPU generally has its' own machine language, and there are significant differences betwwen manufacturers, such as Intel and AMD, but they have a large number of instructions which work identically or nearly so on all CPUs in the class.

Again, you are looking only at PC clones. Look at embedded systems - they most certainly are not remotely cross-compatible.

I did say "class", deliberately, although that may not be the best term. I would rephrase it as: "...but CPUs in the same class generally have a large number of instructions which work identically or nearly so on all CPUs in the class." --Scott McNay 03:06, 7 September 2006 (UTC)

I guess it depends on what you mean by 'class'. An Intel Pentium and an AMD of whatever generation are almost identical. A PowerPC CPU and a Pentium are pretty close - but take a look at an ARM or a MIPS CPU - those are RISC machines and have totally stripped down instruction sets that bear almost zero resemblance to the x86 style of machine with all of it's baroque curlicues and twiddly bits. I mean yes, on a very naive level you have ADD and SUB and MUL and MOV - but that's not what it's all about. Look at the addressing modes. Those RISC machines have a mere handful - x86 have more addressing modes than you can count! We can debate this - but for the purposes of this article, it's very dubious to say that these machines are even broadly similar. SteveBaker 03:56, 7 September 2006 (UTC)

For example, the "x86" class (or whatever you'd prefer to call it). A modern multicore 64-bit AMD consumer CPU (intended for a standard PC) should still be able to run generic machine language programs written for Intel 8088 CPUs, even though they are vastly different in many ways. --Scott McNay 05:44, 7 September 2006 (UTC)

But not vice-versa. Hence the distinction. SteveBaker 05:40, 1 November 2006 (UTC)

21. I tend to dislike the word "program", since it tends to be overloaded, as in "TV program", "TV station programming", and so forth. I try to use "Software" where I can, since it is less ambiguous. Consider a program to record TV programs, or something like that; I would expect people to get confused. My suggestion is to say that when most people talk about programs, they really refer to the more generic "software". Many people also misuse it, as in "can you program my computer?". I'd suggest saying that "program" is more of a technical term than anything else.

The term is certainly overloaded in other fields - but software is too vague. Software includes data files. A "Software package" might include many programs - or no programs at all (just libraries). Within the field of computing, the term has a very precise meaning.

Perhaps should have a note about the specific meaning of "program", then. On a side note, I must say that I really dislike "program" used as asomething other than a noun; most mis-use of it seems to happen when it is used as a non-noun. --Scott McNay 03:06, 7 September 2006 (UTC)

The verb "to program" bothers you? Surely not. SteveBaker 03:56, 7 September 2006 (UTC)

The verb "to wood" bothers you in reference to carving wood? So many people mis-use it that I think it's probably best to discourage non-specialists from using it as a verb. "I want you to program my computer" (person typically waggles fingers while saying this) may be technically correct usage, but tells you virtually nothing about what the person actually wants. The usual meaning of something like this is generally "I want you to install xyz for me". --Scott McNay 05:44, 7 September 2006 (UTC)

I can't help that people sometimes use the term incorrectly. However, amongst programmers, the verb is cleanly specified, frequently used and universally understood. SteveBaker 05:40, 1 November 2006 (UTC)

22. Might want to mention that programming (software engineering) is still an art in many ways.

Heh... I'm not going anywhere near that one. Let's just stick to the facts. -- mattb @ 2006-09-06 13:12Z

Sorry, but anyone who claims that it is not a fact is either lying or has no experience with programming, or is the world's best programmer and never has trouble making his programs print "Hello, World!". :) --Scott McNay 03:06, 7 September 2006 (UTC)

Yes. Something I wish I could get my boss to understand! It truly is an art form. Any experienced programmer will look at two pieces of code - both of which solve the problem at hand - both of which are equally fast and space-efficient and he'll say "Wow! That's a beautiful piece of code - but this other one is ugly!" - that's art. Furthermore, show those same two pieces of code to another programmer and he'll probably come up with the opposite view. I run a team of 5 or so programmers who all work on the same 1 million lines-of-code application - and I can tell who wrote what bits just from the coding style alone. It's like looking at the brush strokes of a grand master oil painting and saying "I can tell that so-and-so didn't paint this - it was his understudy". Yes - it's most definitely an art.

What I meant was that there is still a lot of b'guess and b'gosh involved; the best-written programs can still crash, and it's not like building a house of cards with cards and glue; some days it's more like building a house of cards with cards and an electric fan. --Scott McNay 03:06, 7 September 2006 (UTC)

That's nothing to do with it being an art. People complain about how buggy software is but they never see what a MILLION lines of gibberish really looks like and gaze in awe that not one single comma can be out of place or it'll go horribly wrong. I'm reminded of something a Lockheed engineer once told me. A typical Boeing 747 has a HALF TON of 'shims' in its structure taking up engineering tolerances and mechanical design errors. Any mechanical machine of the complexity of a million line software application would never work. The nearest machines in logical complexity are NASA spacecraft such as the Shuttle - which has close to a million parts. It's failure rate is a lot worse than most million line software applications.

Oh, you mean you're talking about reality. :)

Speaking of reality, it's hellish when you're trying to debug a program, and spend days getting nowhere... because the bug turns out to be in a library. :( --Scott McNay 05:44, 7 September 2006 (UTC)

No what makes software an art is not that it's so often unreliable - "art" isn't a derogatory term here. It is that beauty and style plays a part in what could otherwise be considered a purely rigerous structure. There is true beauty in some code. These five lines reverse the order of the bits in a 32 bit word. Hell - that's BEAUTIFUL! It's art - but only a programmer will ever understand why:

  n = ((n >>  1) & 0x55555555) | ((n <<  1) & 0xaaaaaaaa) ;
  n = ((n >>  2) & 0x33333333) | ((n <<  2) & 0xcccccccc) ;
  n = ((n >>  4) & 0x0f0f0f0f) | ((n <<  4) & 0xf0f0f0f0) ;
  n = ((n >>  8) & 0x00ff00ff) | ((n <<  8) & 0xff00ff00) ;
  n = ((n >> 16) & 0x0000ffff) | ((n << 16) & 0xffff0000) ;

SteveBaker 03:56, 7 September 2006 (UTC)

Perhaps I meant "black magic" or some such thing. :)

I never knew you could reverse bits by shifting, ANDing, and ORing; I'll have to look at that sometime. It does look beautiful, and it looks lke it can be done in parallel to some extent. Is it faster than right-shifting one register into Carry, and left-shifting from Carry into another register, 32 times? --Scott McNay 05:44, 7 September 2006 (UTC)

That's what makes it art. It's certainly not especially efficient - I've never seen anyone use it in an actual, functioning program - and if they did, I'd probably change it to the 'conventional' method. However, it's beautiful...as art. I wouldn't want to wallpaper my bedroom using a repeating Mona Lisa pattern either. Another one I like is swapping two integer variables...normally, we'd say:

 int tmp = x ;
 x = y ;
 y = tmp ;

which seems really, really, ugly to me. It offends me in the same way that pictures of Elvis painted on velvet offend me. But (for integers at least) you don't need to use a temporary variable if you say:

 x = x ^ y ;
 y = x ^ y ;
 x = x ^ y ;

...or even (in some programming languages):

 x ^= y ^= x ^= y ;

But that's art - it's not "a good way to program" - it's some peculiar thing that good programmers somehow instinctively recognise as 'cool'. Mathematicians and to some extent Physicists have a similar sense of what is elegant in an equation or a theory. SteveBaker 05:40, 1 November 2006 (UTC)

24. "few technical reasons why a GUI has to be tied to the rest of an operating system" -- I'm not entirely sure that I agree with this. At the very least, it needs to be tied to the shell, as is done in Unix-like OSes. The problem then is that you get applications which run with one shell but not another, which is why it is made part of the OS in the first place. See my comment above (10) about KDE and Gnome.

Yep - that's got to go. The GUI patently obviously DOESN'T need to be tied to the OS because there are plenty of examples (KDE, etc) of GUI's that are perfectly usable that aren't tied to the kernel. They aren't tied to the shell either. The Window manager ("GUI" is a vague term here) is at the same level in the software heirarchy as the shell - it is in fact possible to talk of "graphical shells" and "command line shells". But you can launch a graphical shell from a command line shell and vice-versa (at least under *nix). So one is not 'above' the other in the hierarchy.

I'm not familiar with how *ix OSes handle this, so perhaps I should shut up now. :) --Scott McNay 03:06, 7 September 2006 (UTC)

The OS has the 'kernel' which deals with stuff like process scheduling, file I/O, memory management, program loading and unloading. There is a graphical server (the X-windows system in the case of most *nix) - which is "just another program" as far as the kernel is concerned. It isn't really special in any way. X provides a fairly raw experience by itself and it's designed to operate in a client/server mode where programs that need GUI facilities send messages to X...possibly over a network if you are running the program on one computer and viewing the graphics elsewhere. Hence, we run 'Window Managers' on top of X that deal with the cute look and feel stuff and some of the nice behaviors. Application programs run within that. But all of these things (other than the kernel) are just programs. None of them are 'special'. You can replace any of them at will and that's OK. Windows isn't like that. The 'kernel' and the graphical environment and the window manager layers are all tangled up and near impossible to extricate. This is the cause of many of the ills of Windows as regards malware, poor reliability and such - and it has taken truly gargantuan efforts on the part of Microsoft to try to keep up with the robustness that a clean architecture would have bought them. SteveBaker 03:56, 7 September 2006 (UTC)

They are trying to get rid of some older stuff; DOS applications are no longer supported in Windows Vista; you need an emulator for that now, and they apparently have research projects on creating a new architecture. However, I do agree that it's top-heavy. --Scott McNay 05:44, 7 September 2006 (UTC)

25. Human-like robots are being sold in Japan, which is apparently desperate for them due to their aging population; see ASIMO.

Yes - but a robot is just a machine that happens to contain a computer. In fact, if you watch shows like "Robot wars" in which computers are hardly ever present, it is aparrent that the term "Robot" has lost it's connotation of "A mobile machine driven by a computer". Robotics is a separate field from Computing and I don't think we need to say very much about it here. Robotics are an application of computers - just like cellphones, greetings cards that play "Happy Birthday" when you open them, space craft, cars, PC's, TV remotes, Furbies, dish washers....why should we single out robots for special mention?

Perhaps because the article mentions robots, which is what I was responding to. :) --Scott McNay 03:06, 7 September 2006 (UTC)

Yeah - I don't think there should be much emphasis there - although people will perhaps look here for information about robots - so we need to put in something minimal to link them off to the right places. SteveBaker 03:56, 7 September 2006 (UTC)

Scott, basically we copied what was on the Computer article with the intention of rewriting most of it. So what you see here still contains a lot of stuff that needs to be redone. Unfortunately I haven't been working on this very much lately, but I'd still like to finish our plans here. The thing is, more editors always help, especially for an article with such a broad scope. Please feel free to change whatever you like on this page, just make a note on this talk page explaining what you've done. -- mattb @ 2006-09-06 13:12Z

I did indeed make some changes, but I thought most of it should be discussed first. I didn't reply much to your comments, Matt, since you're so agreeable. :) --Scott McNay 03:06, 7 September 2006 (UTC)

Yes - this is a productive discussion. SteveBaker 03:56, 7 September 2006 (UTC)

Major Rework

I've spent a couple of hours doing a top-to-bottom rework of this 'Temp' version. I think we are getting close to the point where I'd like to swap it out for the main article - but before we can do that with a clean conscience, we need to make 100% sure that all of the good information in Computer is definitely present either in this new article or (preferably) mentioned in one of the articles listed as 'main' at the top of each section. The new article - abbreviated though it is - is still vastly too big for a Wikipedia article. The goal is 32kbytes - we're still up in the 50kbyte region. SteveBaker 05:40, 1 November 2006 (UTC)

We're getting there. As I said below, I've blown away some sections that we shouldn't need for the final article. I'm in the process of copy editing (fixing little things like em dashes), rewording a little for clarity and grammar (remove second-person portions and get rid of archaic words like "whilst"), and adding some footnotes and such. Footnotes are great in an article like this where you want to keep the text simple and understandable, but would also like to make little side points to explain things in more depth. I used them a lot in CPU&emdash;successfully, I think. One stylistic thing I noticed that I'd like to think about changing is the italics and bolded words. I understand totally what you're trying to do by highlighting key words and phrases because I did exactly the same thing when I wrote CPU. Unfortunately the climate on FAC is that any non-essential use of bolding and italics is bad, and this will probably come up later if we don't address it now. So if it's alright with you, I'd like to cut down these styles to the barest minimum. -- mattb @ 2006-11-01T13:01Z

OK - that's good. The more stuff we can dump out of the article, the better...so long as it's adequately explained elsewhere. I was a little horrified to discover that this new article is actually longer than the original one - so there is certainly a need to trim the fat out of it wherever possible. My bolding and italicing habit is a bad one - feel free to cleanup! 'Whilst' is not archaic to British english speakers. It's a useful word. I can certainly recode the little C snippet into some kind of pseudo-assembler, I think that's a reasonable idea. The traffic light example (or something like it) seems very necessary to me. For people who truly don't understand what programs are or have any clue as to the inner workings, I find that these kinds of simple example really bring home to people both the power of programmability and it's putfalls. I'm certainly open to discuss changing the example - or the way it's explained - but I'm reluctant to remove it completely. SteveBaker 17:00, 1 November 2006 (UTC)

Touched up intro

I tried to simplify the language of the intro a little bit and have it be a decent broad overview of computers. It still may need a little tweaking, but I hope everyone is more or less pleased with its general content at this point. Hopefully I'll be putting in some good work on this article within the next few days. -- mattb @ 2006-10-24T20:12Z

What remains

I've gone through and edited the History section to my liking. Please make any revisions as you see fit. I believe all that remains for this article is to give the Stored program architecture section a good rewrite. I feel that we probably ought to say something briefly about networking and the internet (not sure exactly where to fit this in; suggestions are welcome). Beyond that, I believe all the sections after the big 'ol links section can be eliminated as unnecessary overlap with other articles. After that's done, we should give the big 'ol table a thorough review and post a suggestion at Talk:Computer for anyone interested to review this article before we move it to main space. Afterwards, we probably should request this article to be deleted since temporary pages in mainspace is now disallowed per WP:SP.

I'll also be converting the references over to the Harvard reference style and separate the footnotes and references section. I feel that combining footnotes and references into one section is messy and altogether horrible, and it makes much more sense to separate them. If you have any major objections, feel free to discuss it here. -- mattb @ 2006-10-24T23:36Z

Stored program architecture section

This is probably the most important section in this article, so I wanted to get it right. In trying to come up with a pretty basic criteria by which to explain it, I decided to go ahead and read through von Neumann's famous paper (a good read, by the way, it's very obvious why it is considered one of the pillars of modern computer design). I took some notes which I'll copy here. I've tried to note modern terms for many of the structures von Neumann described. (Sorry that this is messy, I just threw it down in a text editor whilst reading)

---

Core parts of the device (EDVAC):

CA - Central arithmetical

• Arithmetic
• Contains three storage elements; two "input" operands, Ica and Jca; and one "output" operand, Oca (registers in modern terms)

CC - Central control

• Separation of instructions and computational organs used to carry out instructions
• Instructions must be stored somehow

M - Memory

• Intermediate steps for complex internal operations (e.g. multiplication, division)
• Program storage
• Data storage
  • Examples: tables for approximating complex functions like algorithms, initial & boundary conditions for diffeqs, intermediate results for iterative methods, sorting problems, statistical problems
• No separation of data and program storage! Good quote: "While it appeared that various parts of this memory have to perform functions which differ somewhat in their nature and considerably in their purpose, it is nevertheless tempting to treat the entire memory as one organ, and to have its parts even as interchangable as possible for the various functions enumerated above."

CC and CM collectively make up C. All data transfers between the three core components must be effected by structures contained entirely within the core components.

Extra parts not considered "core":

R - Storage (recording) medium; may somewhat blend with M

I - Input

• Organs that facilitate the transfer of information from R into C and M

O - Output

• Organs that facilitate the transfer of information from C and M into R

Details:

Interestingly, the EDVAC design used an additional bit for all numbers to distinguish instructions from data values (the number itself was 30 bits plus one bit for sign). I guess you could call this an early form of memory execution protection. :)

Memory was logically divided into "minor cycles", corresponding to one instruction or data value (a word)

Well-defined instruction set... types of "orders" (instructions):

1. Orders for CC to instruct CA to carry out an arithmetic operation 2. Orders for CC to cause the transfer of a number from one place to another

• can occur between CA and M, within M, or within CA. the second kind can be replaced by two operations of the first kind, so for simplicity, all M-M transfers are handled by two CA-M transfers (load/store instructions in modern terms)
• CA-CA transfers are equivalent to modern register-register operations

3. Orders for CC to transfer its own connection with M to another point in M with the purpose of getting its next order from there (a jump in modern terms)

• For simplicity, CC is designed to follow orders in their "natural sequence" in M, but transfer instructions exist
• Two types of "transfers": transient and permanent (the latter is the one that is most commonly called a "jump" today; the former is basically a combined "call/return" which remembered its place in memory and executed one instruction at the transfer point before returning.. von Neumann saw little use for this latter type, but later systems obviously added a proper call stack and a return instruction to support modern subroutines)

There end up only being four actual instructions for CC; one instruction includes all of the arithmetic operations for CA (as well as I/O and the CA to M transfer operations only). Therefore CA does some instruction decoding of its own, which is a little different from modern designs where all decoding is usually performed in the control unit. The other three instructions are for jump, transfer of a constant into the CA's Ica (immediate value for a register, if you will), and a load from M to CA (CA to M was an instruction passed to and decoded by CA).

---

File:Von Neumann architecture.png

The "Extra" stuff is just various details and such that I found interesting. For the purposes of this article, I think we should key in on is the simple organization of the EDVAC. That is, CC, CA, M, I, and O. R probably can be omitted because in modern usage, R has come to encompass any sort of I/O device, not just the storage described for EDVAC. The diagram to the right is nearly suitable for showing this organization. The only problem with it is that, strictly following von Neumann's description, there should be no arrow from the control unit to the memory since EDVAC's CC never had to write to memory. The question is, how should we explain von Neumann's model simply? I'm inclined to stick with the diagram on the right with some slight modifications:

• Remove the arrow from the control unit to memory since there really isn't a need for the control unit to write back to memory in the von Neumann model.
• Change "accumulator" to "temporary value storage" since the latter is more self-explanatory.
• Perhaps change the names of the control unit and ALU to match von Neumann's terms. This has the disadvantage of making it a little more work to connect them with their modern analogues, but has the advantage of not suggesting that this is an ALU in the modern sense (since a modern ALU doesn't contain registers, direct connections to memory, or direct connections to I/O)
• Make it prettier.

Of course, there's always the other option of just dumping von Neumann's EDVAC model and using a simplified model of what a modern microprocessor is more likely to look like. Please do weigh in! -- mattb @ 2006-10-25T02:30Z

Whilst this is a great description of EDVAC - it's a totally incomprehensible explanation for someone who came here to find out how his computer works. We need to dumb-down the language considerably and provide actual examples. Anyway - I completely rewrote the Stored Program section - splitting it into a discussion of what a program is - and a discussion of how a typical computer goes about executing it. The result is a bit long - and one could argue for moving it out into a subservient article - but if there is any part of the story which needs to be on the main Computer page - it's this. Please let me know what you think. SteveBaker 05:46, 1 November 2006 (UTC)

Nice work. I like how things look in general. I'm making some small changes; mostly stylistic with a few footnotes and extra bits of information I'd like to see. Two things that I'd like to discuss: First, the short C-ish syntax program in the Stored program architecture section. I'd sort of prefer to see that rewritten in a more assembly-like pseudocode because I think that's better indicative of the kind of instructions computers follow. C syntax is obviously more high level and takes a bit of translation before it can become something that might be executed by an average CPU. This is a rather minor issue, though. The other issue is the traffic light example program. I'm really not sure whether this is necessary to have. It's definitely a nice, easy to understand example, but I don't particularly think it adds much to what we're trying to get across in this article. I'd like to see a little discussion on that.

I think we're nearly good to go, though. I blew away several sections that are either already covered in our rewritten content or are covered in other articles (the digital circuits section, I believe, has little place here). I've left the networking and the internet section because I believe that it's a subject important enough to briefly mention here. -- mattb @ 2006-11-01T12:52Z

GPU a computer

In the process of proofreading, I've come across an example that calls a CPU a computer in its own right. Is this actually true (I don't know)? We're taking a strong "computers are stored program machines" stance in this article, so if GPUs aren't full stored program machines, then we probably ought not call them computers. Personally I thought even the most advanced ones were highly complex SIMD/DSP units at best. Anyway, we're doing pretty good if this is the biggest content issue I've found so far. -- mattb @ 2006-11-02T03:19Z

A GPU is certainly a programmable calculating machine - it can emulate a Turing machine - so according to Church-Turing it's able to do whatever any other computer can do (assuming you have enough memory and time). They aren't von Neumann though because the programs are kept rigidly separate from the data - so we're talking 'Harvard architecture' here. But GPU's are certainly stored program machines. I can write a program (either in machine code, or in the 'Cg'/'HLSL' or 'GLSL' high level languages), compile it on the CPU - download it to the GPU and cause it to execute. 'if' statements are available - although in some machines 'for' loops are not (with loops being 'unwrapped' by the compiler). However, the very latest GPU's can run pretty much anything you could write in (say) the C language so long as you don't want recursion or suchlike. They are indeed SIMD's (one single instruction stream is fed to as many as 48 little processors inside the GPU in parallel - which explains the problem with loops) - and I guess they are also a little like DSP's in some ways. But both SIMD and DSP machines are perfectly valid 'computers'...just a little weird compared to something like a Pentium. SteveBaker 16:50, 2 November 2006 (UTC)

Also, we might want to give the multitasking section a little more love. Certainly interrupts are an important part of multitasking, but there are more methods to accomplish that end than solely with interrupt handling. Maybe just a few words on this matter? I'd write it myself, but I'm really not a software person, so I'd probably do a poor job. -- mattb @ 2006-11-02T03:29Z

I wanted to defer that to the main article. All we need to do here is give a flavor of how things are done. "Less is more". SteveBaker 16:50, 2 November 2006 (UTC)

Pictures

I couldn't decide... I'm sort of between the Columbia or a photo of a classy looking Cray (Cray-XMP48, Cray-2). What do you think? I've also taken the liberty to add pictures here and there as I saw fit. Feel free to change them if you find a more appropriate one. -- mattb @ 2006-11-02T04:56Z

Also, can we please try to decide on just one photo for the intro paragraph? I know it's hard, but I really hate stacking photos on top of one another like that. Anyway, I'm done for the night. I hope you're not horrified at all the changes I made (my proofreading can sometimes tend towards my own personal writing style), but I think you'll mostly approve. I'll give this article another critical read-through and copyedit tomorrow and try to rewrite the networking section. -- mattb @ 2006-11-02T05:22Z

I intended to have the wristwatch be backup to the statement that a modern computer could fit into a watch. A lot of people would be skeptical about that - and adding an actual photo of a real, live, full-blown computer makes that a complete reality. But I didn't want a photo of a wristwatch to confuse a complete neophyte into thinking that computers were present in every wristwatch - or that computers and wristwatches are really the same thing. I agree that two photos at the top of the article is not ideal - but I think it's justified in this case. If this is really bothersome then I would prefer to move the photo - along with the "how big are computers" discussion somewhere further down the article. But to be perfectly honest - I'd prefer to keep it where it is now. SteveBaker 16:56, 2 November 2006 (UTC)

I honestly don't think it's necessary to provide visual verification of what we're asserting. Another thing to consider is that we're only representing embedded computers in the lead. If we're only going to have one photo there, it's fine, but if we are to have two, I'd sort of rather see one be a different class of machine. Anyway, I won't make a big deal about this... If you strongly want to keep it, that's fine. -- mattb @ 2006-11-02T17:05Z

Another way to look at this would be to dump the Lego RCX computer and look for a photo of the biggest computer we can find - ASCII-Blue or something. Then keep two photos at the top of the article as a way of visually illustrating the spread. SteveBaker 18:38, 2 November 2006 (UTC)

That's cool with me... I'll find out whether content produced by the US National Laboratories is free for us to use, because LLNL has a good photo gallery of BlueGene/L, the current number one spot on the Top500 list. -- mattb @ 2006-11-02T20:31Z

I've added several pictures to the article. I think the text/picture ratio is pretty good now, though we could stand for a couple more images. The only one I'm unhappy about is Image:Java source2.png, which is (I think) a very boring way to show a modern program. However, I couldn't really think of a better way off the top of my head. If you have any ideas on the matter, let me know. I was toying with the idea of an experimental or novelty programming language that is unconventional, but I sort of think it might be better to stay with something highly representative of common high-level languages. -- mattb @ 2006-11-04T20:40Z

I have a personal dislike of pictures that contain only text - and for pictures that are only there for decoration. We can do nicer (and coloured) text within regular Wiki markup - then it's easier to edit too. But we already have examples of programs - let's make them useful examples and explain what they are rather than dumping some random piece of code in just for decoration. SteveBaker 22:56, 4 November 2006 (UTC)

Agreed, I put it there mostly because I felt we should find something to illustrate a modern program, even if it is just filler. Any ideas? -- mattb @ 2006-11-04T23:32Z

Alternative "add 1000 numbers" program

Per my suggestion above, here's the add 1000 numbers program in MIPS32 assembly:

      lui   $2, 0         ; use $r2 for the sum
      lui   $3, 0         ; use $r3 for the current number
      lui   $4, 1000      ; use $r4 for terminating condition of Loop

Loop: addi  $3, $3, 1     ; increment current number
      add   $2, $2, $3    ; add current number to sum
      beq   $3, $4, End   ; if current number is 1000, jump to End
      j     Loop          ; jump back to Loop

End:  nop                 ; end of program; do nothing

Of course, this doesn't define any memory segments (better to leave all that out in a discussion of pure computers), but this code would work just dandy if translated to machine code and run on a MIPS R3000. Tell me what you think. We can change the comments or remove them altogether, if you'd like. -- mattb @ 2006-11-04T21:13Z

Also, here's what this would look like assembled and in-memory (big-endian):

 Address       Instruction
----------     -----------
0x00000000     3C 02 00 00
0x00000004     3C 03 00 00
0x00000008     3C 04 03 E8
0x0000000C     20 63 00 01
0x00000010     00 42 18 20
0x00000014     10 64 00 01
0x00000018     08 00 00 0C
0x0000001C     00 00 00 00

I'm fairly sure this is correct. I assembled it by hand, so there may be an error, but I think it may be useful just for illustrative purposes to cement the idea that programs really do just get turned into numbers. If we should end up sticking this into the article, it might be useful to label line numbers in the assembly with (abbreviated) hexadecimal as well. -- mattb @ 2006-11-04T22:14Z

Here's another thought. Maybe we could use something like this instead of the stop light example. I think my dislike of the stop light program stems from the fact that it is in really vague pseudocode and doesn't (in my humble estimation), tell the reader what sort of things a real computer is likely to do step-by-step. I think its abstractness may imply to some readers a level of intelligence that can't be attributed to computers. On the other hand, within the MIPS R3000 example there are all kinds of limitations of computers (and MIPS R3000s :) that we can point to... Very simple operations, the need for expressing an algorithm in absolute step-by-step terms, etc.

Anyway, give it some thought. I realize that it may be a daunting idea to dump assembly language into an example intended for the lay man, but I honestly think that with careful explanation it could be very useful in giving the reader a solid concept of exactly the kind of thing that a computer does. As far as I can tell, an good concrete explanation of a simple (real) low-level computer program in lay terms doesn't exist on wikipedia (even assembly language fails to deliver). Why not have it in the computer article where the reader might learn something pretty useful about computers? -- mattb @ 2006-11-04T22:29Z

I think we need something that's easy to understand - it doesn't have to be any real assembler for a real machine - it's illustrative value is as an example. So how about:

       mov     0,sum    # set sum to 0
       mov     1,i      # set i to 1
 loop: add     i,sum    # add i to sum
       add     1,i      # add 1 to i
       cmp     i,1000   # compare i to 1000
       jle     loop     # if i <= 1000 jump back to 'loop'
                        # all done, result is in 'sum'

I'd rather use a real assembly language to be honest (though your point is valid and I agree with it). Let me rewrite that thing in MIPS32 to simplify it a lot... -- mattb @ 2006-11-04T23:11Z

On second thought, using MIPS32 won't really make anything simpler as such; just allow usage of a different branch condition. I don't really see what's significantly more complicated about my R3000 example than your example. Is it the register names? I don't see why that would be difficult to explain... We could easily add a store word instruction to store the result in a named memory location after the loop, too. Anyway, what are your concerns with using the R3000 example? I'd really rather use a real example if possible, but I won't be stubborn about it if you honestly think it would be detrimental to do so. -- mattb @ 2006-11-04T23:29Z

The MIPS code is totally impenetrable to people who don't know what all the mnemonics mean - heck, I've spent a significant chunk of my life writing assembler programs and I can't understand it - without getting the assembler manual. It's full of distracting dollar signs that add nothing to the descriptive nature of the example - and what the heck is 'lui' anyway?! My example is more like PDP-11 assembly - or most 8 bit microcontrollers...very simple - very easy to understand. SteveBaker 03:30, 11 November 2006 (UTC)

I don't particularly think that any assembly is going to be quickly digested by the uninitiated, but the point of using it is to show a real example of a program that directly translates into computer instructions. I could make the argument that the average reader will have just as good a chance of understanding what the for ( ; ; ) syntax means as they would of figuring out what lui or jle do. We can leave comments in to explain things. The reader doesn't have to know exactly what the mnemonics mean or what the instructions do; understanding what they do in the context of the example should be sufficient. However, you may have a point about the distracting symbols and such, so I'll concede to using your syntax. Can we just dispense with the "end" instruction? -- mattb @ 2006-11-11T05:58Z

Oh, we could just replace that last jump with a nop if you think that the infinite loop thing is distracting (went ahead and did it). -- mattb @ 2006-11-04T23:35Z

Let's dump the 'end' instruction from my version and use that then. SteveBaker 12:34, 11 November 2006 (UTC)

I hate to keep revisiting this, (please don't hate me!) but I have one final alternative suggestion for your consideration that may make us both happy. I dug up a copy of the PDP-11/40 processor handbook (good 'ol Bitsavers) and wrote the program in PDP-11 assembly. Turns out that it's extremely intuitive (thanks to the PDPs' rather flexible addressing system) and not much different from your example:

      mov      #0,sum     ; set sum to 0
      mov      #1,num     ; set num to 1
loop: add      i,sum      ; add num to sum
      add      #1,num     ; add 1 to num
      cmp      num,#1000  ; compare num to 1000
      ble      loop       ; if num <= 1000, go back to 'loop'
      halt                ; end of program. stop running.

As you can see, this is nearly identical to your example, but is actually perfectly valid PDP-11 assembly. The only differences are the # marks to denote immediate addressing for the numerical operands and the mnemonic ble (branch less-than-equal-to) instead of jle. In this case I think the pound signs don't detract at all. It's very common for people to use # as shorthand for "number", which is exactly what is happening in this program. This version is both simple and valid assembly (for a very common computer, no less) and has the extra bonus of me being able to throw in a good reference for the article (the PDP-11/40 handbook I used). I think that this version is a great way to make us both happy (admittedly, this is a lot nicer example than the simple-but-painful MIPS). The halt is optional for our purposes. In basic operation it will literally halt the processor and in user mode it will generate a trap. I don't care if we leave it or take it out. Let me know what you think. -- mattb @ 2006-11-11T17:15Z

Yep - that's fine. Let's go with that then. It's rather nice to have some history in there. SteveBaker 22:16, 11 November 2006 (UTC)

Big link table

Few things yet to be resolved with the big links table:

• Enthusiasts Clubs - anything to add here, or should we nix it?
• Output peripherals - any more major examples?
• Software - add section on programming languages? I was thinking that programming languages is a pretty big software topic, but should we represent this topic in the table or just leave that to the programming language article?

We're getting close! -- mattb @ 2006-11-05T00:01Z

Since the (new) purpose of this article is to be a gateway to the other articles about computers, we need the Big Table'O'Links to link to as many 'second tier' articles as possible. We need to identify the high level articles that best cover the subject - and which point down to the 'third tier' articles. So, for example, we should definitely link to Computer keyboard - which talks about keyboards in general and is what I'd call a 'second tier' article - but not to IBM PC keyboard because it is the task of Computer keyboard to enumerate all of the tiny distinctions between keyboard types and to link down to those.

Enthusiasts clubs

I think we need links to articles about enthusiasts clubs. Ideally, we should find an article about computer clubs in general - but if there isn't one, we'll just have to list a bunch of clubs.

Output peripherals

(or peripherals in general) is a little tricky because things like stepper motors, solenoids, LED's...all of those things are peripherals to (for example) the computers inside robots. But I don't think it's right to list them.

Programming languages

Yes - we need a programming languages section - but I think it needs to be separate from software. A "compiler" is a piece of software - but a programming language isn't necessarily a piece of software. You could write in a language for which there is no compiler (as for example Ada Lovelace did (because she had to!) - but also Edsger Dijkstra who described his algorithms in a language of his own invention - for which a compiler was never written). So I think we should simply add another table for programming languages. I'll start that now.

SteveBaker 13:54, 5 November 2006 (UTC)

As far as peripherals are concerned, I think we should more or less ignore embedded computers since it makes the selection far to vast to effectively list. -- mattb @ 2006-11-10T22:28Z

British vs US english

In my copyediting I've noticed that the article is inconsistantly using British and US variants of words. This isn't surprising since I use US English and Steve uses British English. We need to decide on one variant or the other and go with it. I'd tend towards US English since the majority of the text seems to use US spellings and I'm doing a lot of the copyediting, but I wouldn't care if the article was written with UK word variants as long as everything is consistant. Let me know. -- mattb @ 2006-11-10T21:50Z

Yeah - I agree - the article was started in US english - so it should stay that way. Please feel free to fixup anything that looks wrong. SteveBaker 22:46, 10 November 2006 (UTC)

This is an interesting point. It is interesting because the page does indeed seem to be written by an American. I know this not because of the language used, but by the outrageous bias towards American claims of the invention of programmable computing. It is understandable how the general public, especially the Americans, would not be aware of Bletchley Park's achievements. Station X was Top Secret, and its existence has only been disclosed within the last 30 or so years, under a freedom of information act. Also, the time of an invention and when a prototype was manufactured, are two seperate dates. Either way, Alan Turing, who by all rights is why the West "won" World War II in the first place, invented the Universal Turing Machine no later than 1936.

Now unlike Alan Turing, Im not a mathematical genius, but I can calculate that 1936 is a good 5 years before 1941 (which is a German claim in any case). Not only that, but the British Charles Babbage, technically, invented the first computer as early as 1822. It was simply called the Difference Engine, and used Boolean Logic, and some time before then and his death in 1871, he had invented, if not built (funding problems) a Turing-complete computer.

Its a shame for those true British heroes that their countrymen cannot edit the actual page that researchers will read, and be misinformed by, to the point that in the future, America will be yet again given the credit for British achievement.

ps little tip: Great Britain invented almost Everything. go on, put it to the test.

22:46, 12 November 2006 —Preceding unsigned comment added by 84.192.146.246 (talk • contribs)

Entire books have been written on the subject of just what the first "computer" is. I've read plenty of history on the subject and am mildly annoyed that you seem to think that we have given unilateral credit to Americans. Please take the time to read the history section before making wild claims like this. If you still have issues, please bring them up here and we'll try to address them. Turing's work is indeed important, but regards computability more than actual computer implementation. Von Neumann gets a lot of credit simply because he was one of the first to pen a concrete design for an electronic stored program computer that saw implementation. We never claim that von Neumann invented the concept of stored programs; nobody singlehandedly did. We never even arbitrarily claim what the first computer was, preferring to list a few devices that may or may not be considered the first computers. Zuse certainly did important work (and we mention him), Colossus was a very significant achievement from the Brits (which we mention), the British even beat von Neumann to implementation with Baby and EDSAC (which we also mention), we even speak first of Babbage. Where is this American bias you are talking about? If the mere mention of von Neumann and the ENIAC team is an American slant, then I'm afraid we can't help you.

P.S. - That claim neither helps your argument nor has any shred of truth. The very nature of the word "almost" should indicate how useless the statement is. Want an example? Ohhh... Transistor (possibly implemented first by a German, but developed for commercial use by Americans). -- mattb @ 2006-11-12T22:06Z

Also, the difference engine was not programmable. You're thinking of the analytical engine. We mention both of these in the article. -- mattb @ 2006-11-12T22:31Z

Without being partial, I must say more people in the world prefer British English.--Darrendeng 09:01, 30 November 2006 (UTC)

You could use that 'popularity' argument to argue that the entire Wikipedia should be in <insert your favority flavor of English here>. But that's not how the rules work. The rule is that if there is a compelling reason to choose based on the subject matter then use whatever is most appropriate and stick to it. So an article about Sussex should be in Brit-English, an article about Texas should be in US-English, an article about Brisbane should be in Aussi-English. But if there is no compelling regional content in the article then whichever flavor of the language the article was initially written in should continue to be used. There is nothing uniquely British, American, Australian - or whatever about Computer - it's a totally international phenomenom. Hence, since this article happened to start out in US-English and must therefore stay that way. This is a good rule because we really don't want edit wars about colour/color, tyre/tire, and -ise/-ize. (PS, I am a Brit) SteveBaker 13:09, 30 November 2006 (UTC)

Ready to move?

I just gave the Computer article a look-over and have come to the conclusion that there's nothing left there that isn't covered or appropriately linked here. I think this article is nearly finished save for a few minor items and some copyediting. The only thing this one lacks compared with the current main article is that table comparing some of the machines leading up to stored program computers. I like that table, but I don't know if its really necessary or how to integrate it into this article. Any thoughts on that? If you don't think we should keep the aforementioned table, let's go ahead and move the article. -- mattb @ 2006-11-10T22:02Z

That table turns out to be a Template - so I stuck it into the History section in about the same place it is over at Computer. It fits into the flow of the text surprisingly well. I'm happy to move the article anytime - . Should we literally move it using the 'move' button - or copy/paste 100% of the text? I'm not sure of the consequences for version history, the semi-protection status, etc, etc. SteveBaker 22:58, 10 November 2006 (UTC)

That's a good question... I'll figure out the answer in a few minutes and you'll see the result. -- mattb @ 2006-11-10T23:03Z

Woah...wait a minute. We only have 3 references in the new article - the old one has 17 - we need to transfer as many of them as we can. SteveBaker 23:17, 10 November 2006 (UTC)

Most of the references in the old article were either very weak web references or don't really apply to the new article. I'll give them all another look-over, but I'm not a big fan of throwing in a bunch of weak weblink refs just for the heck of it. -- mattb @ 2006-11-11T05:45Z

References from the old Computer main article

We need to put these references back into the article someplace.

 <ref name="antikythera">{{cite web | author=Phillips, Tony | publisher=American Mathematical Society | year=2000 | title=The Antikythera Mechanism I | url=http://www.math.sunysb.edu/~tony/whatsnew/column/antikytheraI-0400/kyth1.html|accessdate=2006-04-05}}</ref>
 <ref name="Schickard">{{cite web | year=Unknown | publisher=computerhistory.org | title=Visible Storage | url=http://www.computerhistory.org/VirtualVisibleStorage/artifact_main.php?tax_id=01.01.06.00|accessdate=2006-04-05}}</ref>
 <ref name="shannon">Shannon, Claude Elwood (1940). [http://hdl.handle.net/1721.1/11173 A symbolic analysis of relay and switching circuits]. Massachusetts Institute of Technology: Thesis (M.S.)</ref>
 <ref>{http://scienceworld.wolfram.com/biography/Shannon.html Biography of Claude Elwood Shannon] - URL retrieved [[September 26]], [[2006]]</ref>.
 <ref>{{cite web | author=Unknown|title=IA-32 architecture one byte opcodes|publisher= sandpile.org| year=Unknown | url=http://www.sandpile.org/ia32/opc_1.htm | accessdate=2006-04-09}}</ref>
 <ref>{{cite web | author=Kanellos, Michael | title=Intel: 15 dual-core projects under way | publisher= CNET Networks, Inc.| year=2005 | url=http://news.com.com/Intel+15+dual-core+projects+under+way/2100-1006_3-5594773.html | accessdate=2006-07-15}}</ref>
 <ref>{{cite web | author=Chen, Anne | title=Laptops Leap Forward in Power and Battery Life | publisher= Ziff Davis Publishing Holdings Inc. | year=2006 | url=http://www.eweek.com/article2/0,1895,1948898,00.asp | accessdate=2006-07-15}}</ref>
 <ref>The last of the first : CSIRAC : Australia's first computer, Doug McCann and Peter Thorne, ISBN 0-7340-2024-4.</ref>
 <ref name="toms-tcount">{{cite web | author=Thon, Harald and Töpel, Bert | publisher=Tom's Hardware |title=Will Core Duo Notebooks Trade Battery Life For Quicker Response? | year=January 16, 2006 | url=http://www.tomshardware.com/2006/01/16/will_core_duo_notebooks_trade_battery_life_for_quicker_response/ | accessdate=2006-04-09}}</ref>
 <ref name="WindowsXP-size">Tanenbaum, Andrew S. ''Modern Operating Systems'' (2nd ed.). Prentice Hall. ISBN 0-13-092641-8.</ref>
 <ref name="ibm-pr">{{cite press release | publisher = IBM Data Processing Division | date = April 7, 1964 | title = System/360 Announcement | url=http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PR360.html}}</ref>
 <ref>{{cite web | title=Classical Super / Runaway Super | year=Unknown | publisher=Globalsecurity.org|url=http://www.globalsecurity.org/wmd/intro/classical-super.htm|accessdate=2006-04-05}}</ref>
 <ref>The last of the first : CSIRAC : Australia's first computer, Doug McCann and Peter Thorne, ISBN 0-7340-2024-4.</ref>
 <ref>{{cite web | author=Brown, Alexander | title=Integrated Circuits in the Apollo Guidance Computer | year=August 22, 2002 | url=http://hrst.mit.edu/hrs/apollo/ic | accessdate=2006-04-05}}</ref>
 <ref>{{cite web | year=Unknown | title=Technological Innovation and the ICBM | publisher=Smithsonian Institution|url=http://www.hrw.com/science/si-science/earth/spacetravel/spacerace/SpaceRace/sec200/sec270.html|accessdate=2006-04-05}}</ref>
 <ref>{{cite web | title=North America Internet Usage Stats | publisher=Internet World Stats | year=April 3, 2006|url=http://www.internetworldstats.com/america.htm#us|accessdate=2006-04-05}}</ref>

A computer program on a punch card?

I suppose one could create an entire 80-byte program, but saying that an entire program could fit on a computer card is misleading. Most programmers will tell you that most computer programs took hundreds, if not thousands, of cards. 74.100.135.139 eric

True, but the punch card was just an example. It's not really critical that we go into detail here since, as you said, it's not at all inconceivable to have a program that small. -- mattb @ 2006-11-12T18:50Z

The very important 1401 bootstrap program took less than a full card. [1] Search that page for "1401 bootstrap program". The 1401 itself was vastly important, so much so that most IBM S/360 Model 30 computers sold were ordered with the 1401 emulation feature. —Preceding unsigned comment added by 70.231.146.45 (talk • contribs)

Remarks 11/12/06 on the new "Computer" article

I chatted with uberpenguin and here are some of my comments. They're all over the map, from simple typos to suggestions to additional important topics to cover to sections that should be completely rewritten (History) to have a contemporary emphasis (lots has happened since 1960 but you wouldn't know it from the History section).

1. Take the first sentence's links and make paragraphs from them. Make a paragraph for "machine". Make a paragraph for "data". Make a paragraph for "instructions". You already have the last, but you need to have all three, in order. (Perhaps this exercise will make you ponder whether a better word than "machine" could be used.)

The intent is that this be a gateway article that mainly exists to point to the deeper articles out there. That first sentence is deliberately short and to the point - expanding it out into a bunch of paragraphs would remove it's meaning. This is an electronic encyclopedia - and we have links...let's use them. The word 'machine' is carefully chosen - and I'm well aware of it's meaning. SteveBaker 06:06, 13 November 2006 (UTC)

2. Herman Hollerith's name is not spelled with two n's. (oops, you fixed it)

Fixed. -- mattb @ 2006-11-13T02:34Z

3. The huge computer room picture should be captioned Columbia, not Colombia, I believe. But a still cooler picture, and more contemporary at that, is the one at http://en.wikipedia.org/wiki/Computer_cluster

Fixed the "Colombia" typo. -- mattb @ 2006-11-13T02:34Z

Rather than write complaints about simple typos here in the talk page - please just fix them. SteveBaker 06:06, 13 November 2006 (UTC)

4. The article does not even mention Apple or Mac computers and gives too little emphasis on the evolution of the modern-day computer from the punched-card accounting machine. (But then wikipedia doesn't even *have* an article on accounting machines!)

We only briefly mention PCs. Macs fall under the broad category of PCs. Personally I think our history section is plenty long enough for the purposes of this article. Of course, we're taking a strong "computers are stored program machines" stance in the development of this article's text, which explains why we quickly skim over the history of computers after the development of the stored program computer. -- mattb @ 2006-11-13T02:59Z

There are any number of computers that we haven't mentioned - what about Clive Sinclair's contribution? What about the Commadore PET, the Tandy TRS-80, the Atari ST and the Amiga? There are vastly too many to mention - this article is already nearly twice the size that Wikipedia recommends articles should be. That's why we have the huge links section at the end. I agree that Wikipedia doesn't have an article about accounting machines - and it probably should. Just as soon as someone writes it, we'll add a link to it here. SteveBaker 06:06, 13 November 2006 (UTC)

The Osborne is not a mainstream computer, of course. I don't suggest you document obscure machines. Intels, Powers, Sparcs, IBMs are mainstream computers. Richard Hitt

5. The History section gives information almost entirely before 1960; but the history of the modern General-Purpose Digital Computer actually dates from the IBM System/360 announcement, in 1964. A huge amount of evolution has occured since then. The IBM Personal Computer announced in 1980 began the mind-boggling progress to the present day, coupled with Bill Gates's Windows.

See my last comment. What you're saying is valid, but this article focuses on computers as stored program machines in order to help clearly define what should and shouldn't go here. Even though this may cause some bits of computer history to be omitted, I think it was the right choice (plus the history of computing hardware article is very good and covers all this). -- mattb @ 2006-11-13T02:59Z

Once again, this is a gateway article. We link to the full 'History of Computers' article. We only have space for a sentence or so about each major era. SteveBaker 06:06, 13 November 2006 (UTC)

I still think you put too much emphasis on old history and skimp on new history. Richard Hitt

6. You could mention what happens when a computer makes a mistake. There is memory-checking logic and CPU-checking logic to cause a special program to take control and analyze the failure.

Something to this effect could be added to a footnote. I don't really think it should go in the main article since it may interrupt flow a bit. -- mattb @ 2006-11-13T02:59Z

Firstly, the computer doesn't make mistakes (or at least so amazingly rarely as to be irrelevent) - the mistakes are in the programming. I'm not sure what 'memory checking and CPU checking logic' this is - but in the 35 years I've been working with computers, I've never come across this magical thing. SteveBaker 06:06, 13 November 2006 (UTC)

The IBM 7094 with its 32,768 36-bit words amazingly didn't even have parity checking for its memory. The 360 started out with parity checking for its memory, as did the 1401. Later 360s used CRC (Cyclic Redundancy Check) which is capable of detecting two-bit errors in a 64-bit memory word and correcting single-bit errors. Furthermore all IBM S/360, S/370, on up to the present day, have a so-called Machine-Check interrupt. When the machine detects an error in itself, it triggers a machine check to give control to the machine-check interrupt handler. The IBM PC started out with parity-checked memory; I haven't kept up but I'm sure it is at least that good. My computer experience is at a low-enough level that I had to know about these features, starting in 1966. The reason you think computers don't make mistakes is because of these hardware features and because of software that people like me wrote. Holler for references; they should be all over the place. Richard Hitt

7. The concept of subroutine calls is essential to modern programming. The concept of stacks is essential to all unix-like operating systems, such as Windows and Linux. You should speak of these hardware features.

I agree, we need to at least mention subroutines, good catch. Stacks I'm not so sure about. -- mattb @ 2006-11-13T02:59Z

Once again - we have limited space. We need to discuss what else we can toss out of the article - not what additional fat we can add. Detailed discussion of these details belong in daughter articles. SteveBaker 06:06, 13 November 2006 (UTC)

8. The modern computer is called technically a General-Purpose Digital Computer, and you should introduce this term. As to Special-Purpose Computers, such as embedded computers, you should spend scant time but provide a link to a Sepcial-Purpose Computers page. As to Analog Computers, likewise.

General purpose? Special purpose? Anymore those terms are pretty fluid and can be evaluated on a per-case basis, I think. Most supercomputers are special purpose, but they often use general purpose hardware. Most embedded computers are special purpose, but they often use the same types of hardware used in "general purpose" computers. I think there is a distinction, but that it's too weakly defined for us to be able to tersely state it in this article. Just my opinion. -- mattb @ 2006-11-13T02:59Z

If there are more articles that we havn't linked to - please add them into the links tables at the end. There is already a link to analog computers there. But if there is no article - we can't link to it. SteveBaker 06:06, 13 November 2006 (UTC)

9. You should probably mention today's hot topic of virtualization, which will become increasingly important: http://en.wikipedia.org/wiki/Virtualization

Hmm... Yeah, I'd support adding brief mention of it. Maybe into the link tables? -- mattb @ 2006-11-13T02:59Z

Yeah - it could go into the links table if there is an article about it. SteveBaker 06:06, 13 November 2006 (UTC)

10. Instead of a photo of ferrite-core memory, choose a photo of contemporary computer memory, either of a typical memory-expansion card or of a memory chip. Search images.google.com for: memory chip.

Heh... My choice of core memory was intentional. Pictures of IC packaging are exceedingly boring, pictures of SRAM/DRAM organization are way too technical to just throw into the article, and I don't have a good, high-res photo of a DRAM die (which might actually be interesting to use). If we can find a free high-res photo of some DRAM (or I can find the time to take one), that might be nice to put in the memory section, but until then I'd rather have an eye-catching picture than one that favors modern technology. The image is simply for illustrative purposes, anyway. -- mattb @ 2006-11-13T02:59Z

Yep - I agree with Matt. Everyone knows what a chip looks like - let's pick things people havn't seen. SteveBaker 06:06, 13 November 2006 (UTC)

I understand your point of view and at first blush I agree with it. But consider this. Most people nowadays think of add-on memory as that long bar of chips that they recognize if they dare to open a computer and have a book illustrating what's stuck on the motherboard. These only slightly sophisticated users would be done a disservice by showing them a picture of a thing they have NOT seen nor are likely to see. That was my complaint about the picture of ferrite cores (doing justice to that picture would of course require explaining x and y and sense lines). I favor the viewpoint that we should show them pictures of parts they HAVE seen, so they can go, "Aha! Now I know what that thing is!" Richard Hitt

11. If you're going to give an example of a binary machine instruction, don't give a MIPS32 example but give an Intel x86 example. Save old or obsolescent illustrations for the History section.

MIPS32 isn't old or obsolete. Furthermore, instruction decoding is much more straightforward than x86 since it's a fixed-length instruction word architecture. As with the core memory, it's just an illustrative example. -- mattb @ 2006-11-13T02:59Z

Why Intel? I don't know what the current figures are - but three years ago there were more MIPS processors in the world than x86 processors. You are making the severe (and all too common) assumption that all computers are little boxes that run Windows or MacOS. Embedded computers are VASTLY more numerous and actually have a larger impact on society than PC's. SteveBaker 06:06, 13 November 2006 (UTC)

Actually I'd pick a S/360 assembly program; it's much simpler than the x86, on the order of a MIPS. But I do like the simplicity and the self-explanation of the assembly code for the MIPS32 that you picked. Richard Hitt

12. Does a GPU actually contain multiple, possibly 50, cores, that is, processors? The linked article doesn't verify this.

That might be a good one to add a ref on. -- mattb @ 2006-11-13T02:59Z

The present nVidia 6800 ULTRA has 48 fragment processors and 16 vertex processors for a total of 64 processors. I wouldn't call them "cores" though since that's a little misleading. We could probably reference an nVidia technical site for that. SteveBaker 06:06, 13 November 2006 (UTC)

13. Note http://en.wikipedia.org/wiki/Computer_cluster -- you could modernize some of your supercomputer hyperbole by noting that many of the duties that supercomputers did are now done much more economically by large clusters of commodity PCs running Linux.

Yeah, it wouldn't hurt to add a sentence about clusters into the multiprocessing section. -- mattb @ 2006-11-13T02:59Z

No! Many of the jobs that supercomputers did 10 years ago can now be done by desktop machines - but the jobs that present supercomputers do today are just as far out of reach of todays desktop as 10 year old supercomputer tasks were from the reach of PC's of 10 years ago. All machines (both PC's and supercomputers) are growing in speed at about the same rate - and we'll never run out of problems that require supercomputers. SteveBaker 06:06, 13 November 2006 (UTC)

That's not really true, sad to say for supercomputers. With the possibly exception of stuff like weather forecasting. Render farms for the horrendous but very parallel job of computer animation are huge combinations of guess what? x86 commodity boxes. Google has half a million computers in their various datacenters, and they each and every one are guess what? x86 commodity boxes running Linux. Probably the Render Farms run Linux too. Look at that picture from that wiki page I cited; you will see a HUGE complex of computers all guess what? x86 commodity boxes running Linux, well, those look too well packaged and racked to be exactly commodity boxes but I'd bet they're x86. I bet that NSA uses more and more clusters of etc, and they are cryptographic crunchers. The NSA machines in the AT&T building at Folsom in SF are either Sun boxes or that Mountain View company whose name I forget, which contains the real winnowing code, I think. Yes, I know that Cray, owned now by SGI?, is still making something. Richard Hitt

14. For your program example of summing 1 .. 1000, why not show an example of computing the formula (n ( n + 1)) / 2? And then mention how this better program takes one one-thousandth of the time of the first program.

I dunno. I think simply adding that in to the article as it stands would be unnecessary bulk. Personally I'd rather use something like that for the program "Example" section rather than the stoplight program, but I'll defer to other editors here. -- mattb @ 2006-11-13T02:59Z

The stoplight program shows the that computers don't just crunch numbers. The 1...1000 example is merely there to show how much quicker it is to write the program than to use a calculator. The n*(n+1)/2 part is there to point out that computers can take longer to do some jobs than humans because they don't think about what they are doing. SteveBaker 06:06, 13 November 2006 (UTC)

My take is that it's poor programming, not stupid computers, that's the reason computers might take longer to do some jobs than they should. I would make this point by showing the assembly code for the one-step algorithm as well as for the thousand-step one. Or of course, show no assembly code for either; there's not much need to show any assembly code in a beginners' computer article. Richard Hitt

15. Footnote 9 proclaims a software bug when it should merely note a possibly unexpected behavior. The program may indeed have meant not to start a blink sequence until a full normal cycle has occurred. There are safety reasons for doing exactly this in the real world with real traffic signals.

I wanted to show how easy it is for bugs to occur - even in the most simple programs imaginable. Yes, I suppose it could have been intended for it to work like that - but the same could be said of any program that misbehaves. It's a nice simple example that anyone can understand - we can't be putting deep, complex stuff in here. Remember, no qualified programmers would be expected to gain any useful information from this section. It's there for people who have so little clue as to how a computer works that they'd type "Computer" into Wikipedia to find out. SteveBaker 06:06, 13 November 2006 (UTC)

Yes, and it could be explained further; I'm not sure a naïve reader would do anything but scratch his head. I've forborne suggesting tightening-up of the whole article, but a good editor, a technical editor, could do a lot of it. It is not much subtler if at all than other parts of the page to say that a "bug" amounts to "unexpected behavior". Richard Hitt

16. Footnote 12. Does flash memory wear out after repeated uses? I don't think so. See http://en.wikipedia.org/wiki/Flash_memory. You should provide a reference that flash memory wears out or delete the statement.

Yes, flash memory has a finite and comparatively (to DRAM) small number of write cycles before the floating gates stop working correctly. I'll find a ref. -- mattb @ 2006-11-13T02:59Z

Here you go. Page 2: "Endurance : 100K Program/Erase Cycles". I'll add this as a ref to the article. -- mattb @ 2006-11-13T03:13Z

That sure is a technical pdf! Maybe you could simply drop the issue of this flash memory problem? I don't doubt that technology will improve flash memory to the point that it's much better. Richard Hitt

Actually, here's a much much better reference that explains the failure mechanism (in case you're interested). I'll use this one instead. Cappelletti P., Bez R., Cantarelli D., Fratin L. (1994). "Failure mechanisms of Flash cell in program/erase cycling". IEDM Technical Digest. {{cite journal}}: Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link) (page 291). -- mattb @ 2006-11-13T03:17Z

Is there a URL for that? Richard Hitt

17. Footnote 13. Your link to instruction-set architectures only lists two 64-bit architectures, and one of them, the IA64, is a radical departure from the Intel x86 architecture. Thus when you say, "All of the architectures mentioned here existed in 32-bit forms before their 64-bit incarnations were introduced.", if by "here" you mean the supplied link, you're wrong. By the way, in general a compatible 64-bit architecture differs from its 32-bit predecessor not in the substance of its instructions but only in the size of its address space and its registers.

You're right, the "here" was ambiguous. I've tried to fix that. -- mattb @ 2006-11-13T02:59Z

18. Speaking of bugs, an important topic these days is "exploits". Clever if unprincipled programmers create special programs to gain unauthorized control of a computer, perhaps via the internet, by exploiting a known weakness (bug) in a program (say, a web browser). See http://en.wikipedia.org/wiki/Exploit_%28computer_security%29 You should mention this in your discussion of bugs, especially around the text "Errors in computer programs are called bugs. Sometimes bugs are benign and do not affect the usefulness of the program, in other cases they might cause the program to completely fail (crash), in yet other cases there may be subtle problems." That is to say, sometimes benign bugs are exploitable and turn malign.

I think that's a reasonable suggestion. Couldn't hurt to add a sentence to tie in exploits. -- mattb @ 2006-11-13T02:59Z

Yep - I agree. Holes that can be exploited can be regarded as bugs. We should (briefly) explain that. SteveBaker 06:06, 13 November 2006 (UTC)

19. it's should be its in the Memory section in the text, "... slower than conventional ROM and RAM so it's use is restricted ...".

Fixed. -- mattb @ 2006-11-13T02:59Z

Again - PLEASE just fix simply typos, spelling and grammar in the article rather than complaining about it here. SteveBaker 06:06, 13 November 2006 (UTC)

I would have if I could have. I haven't signed up yet, and so the document wasn't editable for me. Sorree. Richard Hitt

20. moder should be modern in the text, "The computer in the Engine Control Unit of a moder automobile ...".

Fixed. -- mattb @ 2006-11-13T02:59Z

21. Far more important than the von Neumann machine to the history of modern computing is the concept of upward compatibility. You treat it only slightly, but the fact that a computer program doesn't have to be rewritten to run on a bigger newer machine of the same type (IBM S/360 through zSeries; Intel 8088 through Pentium) is far far far more important than the concept of the stored-program computer. This historical Tipping Point occurred in 1964 with the announcement of the S/360, and IBM demanded of Intel with the advent of the PC that it do the same. Otherwise, 386 programs would not work on a 486, 586, ....

While it's definitely important, I wouldn't call it more important than the stored program concept. The latter is the very definition of a computer. However, I'm not opposed to treating upward compatibility a little more than we have. -- mattb @ 2006-11-13T03:08Z

22. Sorry to harp on your History section, but see http://en.wikipedia.org/wiki/History_of_computing_hardware_%281960s-present%29 -- and even THAT page misses the vast impact of upward compatibility on the computers of today. Your history section should deal mostly with that page and not with the ancient history of http://en.wikipedia.org/wiki/History_of_computing_hardware, or only very very briefly.

No need to apologize. Your point is valid, I just disagree with it in the interest of keeping this article terse and deferring to the history of computing hardware for a fuller story. -- mattb @ 2006-11-13T03:08Z

Again, we are at 56Kbytes of text - and the goal is <32Kbytes - we have to find ways to shorten the article - not expand it. If more description is needed in History of computing hardware - then fine - add it there. SteveBaker 06:06, 13 November 2006 (UTC)

I certainly agree about the shortness issue. I'm a newbie wikiwise but I can imagine that once it's out and public the trend will be to lengthen it, with various edits from the public. I personally think much can be removed from this document without compromising its introductory goal, e.g., the assembler-language examples. Richard Hitt

23. The description of a CPU as constituting a Control Unit and an Arithmetic-Logic Unit is what I learned decades ago. Terminology has changed to things like "instruction fetch" and "execution" units. The pipelining page, http://en.wikipedia.org/wiki/Instruction_pipeline, gives a good example of both pipelining and (take just the top line of the diagram) unpipelined processing. IF fetches an instruction. ID decodes that instruction. And so on, as illustrated at points 1 through 5 on that page. The wiki page http://en.wikipedia.org/wiki/Arithmetic_logic_unit appears to be based on the seventh edition of the Stallings book, and I suspect he's let it get rusty since the first edition.

Yeah, and von Neumann called them the Central Control and Central Arithmetic units, respectively. We just chose common terminology for both. I think it's fine as is; there are still architectures that have very simple control units. -- mattb @ 2006-11-13T03:08Z

24. Numbers are what computers work with, but programmers must work with them too, often in close harmony with computers themselves. The binary number system uses only 0s and 1s (for instance, 69 decimal is 1000101 binary) but more friendly systems are in use. The hexadecimal system is widely used and uses the digits 0, 1, ..., 9, a, ... f, where 'a' represents decimal 10 and 'f' represents decimal 15. And of course 0x10 represents decimal 16. Thus 69 is 0x45 = 4 times 16 plus 5.

I'm on the fence about this one. If we mention the usage of various radix numeral systems it hsould be very brief. -- mattb @ 2006-11-13T03:08Z

Might I humbly suggest you take my very sentences above and stick them in somewhere, almost verbatim? I intentionally wrote them for that possibility; I should have said so. Richard Hitt

It's probably worth a mention when we are talking about the progression from machine language to assembler. That's where programmers start using hex. SteveBaker 06:06, 13 November 2006 (UTC)

Well, that's it for me for the moment. Let me know what you think. I haven't gone back and reread for typos as I usually do, because I have laundry to fold, so please excuse all the typos.

Richard Hitt rbh00@netcom.com

Thanks a lot for your comments! You've made several very helpful suggestions. -- mattb @ 2006-11-13T02:59Z

Yep - thanks! SteveBaker 06:06, 13 November 2006 (UTC)

And thanks for putting up with my devil's-advocacy. Sitting ducks are always the easiest to shoot at. I think several sections of the document could be deleted with simple links for the curious: the assembly code; much of the (early) history section; How many bits were in the bus for 8088, ..., x86-64 CPUs. You could give a short jazzy section saying how much speed and capacity have increased for CPU, RAM, disks between 1980 and today for the ubiquitous PC, with links for further research; the combined order of magnitude of increase is somewhere around 10^12, truly astounding. You could better use existing Wikipedia pages, and I have noted several throughout my initial commentary points. Many many more exist to be exploited, I'm sure.

Richard Hitt rbh00@netcom.com

Richard: Thanks for your further clarifications - I hadn't noticed that you do not yet have a Wiki account and are therefore barred from editing this article. May I strongly urge you to get a Wikipedia account - it takes you one minute - and after you've had it for a few of days you'll be able to edit this (and other) semi-protected articles and to sign your comments with four '~' characters. You'll also have your very own Wiki user page with associated 'Talk' section. Sadly, this article was being vandalised dozens of times per day by people with no Wiki accounts - and we were being overwhelmed by the effort it took to continually fix up the damage. So we had to prevent them from editing by the 'semi-protection' mechanism which has the unfortunate side effect of locking out people such as yourself who have valuable contributions but have not yet created accounts. Serious contributors (such as you are obviously becoming) are expected to get accounts - but even if you plan on just an occasional edit, an account is worth having.

Also, you talk about "once (...the article...) is out and public" and "edits from the public". Let me make it abundantly clear: This article is already 'out and public' - all Wikipedia articles are, all the time - and I am the public - as is everyone else who ever edited any Wikipedia article anywhere! You and I and everyone else who contributes are on exactly equal footing - so if you disagree with what I've written, get in there and fix it (but don't be surprised if I subsequently 'unfix' it!) - we work by consensus and your voice is as valuable as anyone else here (well, it will be if you create a user account right now!!!!) SteveBaker 15:42, 13 November 2006 (UTC)

25. I would like to add a link to Prof. Sir. Maurice Wilkes (http://en.wikipedia.org/wiki/EDSAC) work for the Lyons Tea Shop, to produce the LEO (Lyon Electronic Office) (http://en.wikipedia.org/wiki/LEO_I) - which i think is the first real computer. 28Jan07 Alex Wells

On what grounds would you say that the LEO I is the "first real computer"? The wikipedia article indicates it ran its first program in 1951, several years after the "firsts" we enumerate in this article. -- mattb @ 2007-01-28T22:11Z

Future technologies & Crystal Balls

I agree that we shouldn't be talking about technologies that don't exist - but we can (and should) talk about the directions that reesarch is leading. So I changed the table entry to 'Research technologies' rather than 'Possible future technologies' to better represent what we're talking about here.

All four types of computer have in fact been demonstrated at some very basic level in the lab: Quantum computer with just one or two q-bits have been shown to be capable of doing calculations (and remember that you need very few q-bits to make an insanely powerful computer). DNA computers have been used to solve the Travelling Salesman problem and calculations of prime numbers - and someone recently demonstrated a tic-tac-toe playing program using some variety of chemical computer. Optical switches and gates are actually used in some extreme niche applications (I actually use such a system from time to time - so I know this for a fact) - but none of them have been used to create an entire computer yet. But all of those are definitely viable computer technologies - and we would be missing valid information to pretend that they simply don't exist just because they are in the research phase.

But there is a deeper matter at stake here. This article is here mostly to link to other Wikipedia articles and to organise those links into a coherent context. There are pretty good articles written about Quantum, DNA, Chemical and Optical computers - and it is the job of this article to point them out to our readership. If it were decided that any of those articles were too forward-looking for Wikipedia (I don't think they are) - then those articles should be put up for AfD - and if/when they are deleted then the link to them should be expunged from this article. However, it is not our job to second-guess the AfD folks or to offer summary judgement that an article is unworthy - to do so would be seocnd-guess AfD which would be a breach of Wikipedia process.

SteveBaker 05:32, 14 November 2006 (UTC)

Yup yup... Agree with your actions and rationale. As an aside, it seems apparent that quantum computers will be great at factoring numbers, but I'm not sure if that in itself leads to a better computer. Certainly a cryptographer's (or ne'er-do-well's) dream, but as far as advantages for general computing... That remains to be seen. Solving the TSP with a DNA computer sure sounds interesting, though, and definitely has applications across the board. -- mattb @ 2006-11-14T05:57Z

The key capability of both Quantum computers and Chemical/DNA computers is the ability to operate in almost infinite parallelism. The qubits of a Quantum machine can hold all possible 'solution states' in parallel and a bucketful of DNA holds an insanely large number of states simultaneously (ditto for chemical/nanotechnological computers). An optical computer can (theoretically) be made to switch different frequencies of light separately - so once again, there could be millions of calculations performed in parallel. So pretty much all of these technologies are going to be applicable to vastly parallel problems - which certainly limits the areas where they provide a significant speedup. Algorithms that don't exhibit massively parallel sections will probably run dog-slow on these machines - so you'd want a conventional electronic computer sitting there doing the non-parallel parts. But code breaking, travelling salesmen problems (which are of great use for all kinds of applications), AI, finite element analysis, weather forcasting, virtual wind tunnels, graphics...all of those things are potentially vastly speeded up by any of those 'future' technologies. SteveBaker 18:38, 14 November 2006 (UTC)

It's appropriate for the article to point out new computer technologies being actively researched by linking to the articles on them. The problem with this article as it stands is that these links are being presented as the Fifth Generation in the "History of Computing Hardware". Which of these technologies, if any, might become the basis for the generation which follows VLSI cannot be determined without a crystal ball. Not good. The links need to be moved elsewhere, perhaps under "Other Hardware Topics". -R. S. Shaw 07:07, 15 November 2006 (UTC)

That's easy enough to fix. I dispensed with "Fifth generation" in favor of "Theoretical/experimental". This new table heading should be clear enough. -- mattb @ 2006-11-15T07:26Z

That's OK with me. I would have gone with something like "Technologies competing for the title 'Fifth Generation'" - but that's kinda wordy. Yeah "Theoretical/experimental" works OK here. SteveBaker 13:47, 15 November 2006 (UTC)

Request for link to my page 'How Computers Work'

I suggest a link to my page 'How Computers Work' at http://www.fastchip.net/howcomputerswork/p1.html because much of the article is about '3. How Computers Work.' This is my first experience with Wikipedia. Thinkorrr 20:09, 3 December 2006 (UTC)

Thank you very much for requesting that your link be added here rather than adding it to the article yourself. That is generally considered proper procedure for external links (especially those with which you're affiliated) and is the correct way to proceed. I browsed over the book briefly and it looks pretty good, though I'd venture to say that the subject matter is more on digital logic and simple microprocessors than computers in general. Perhaps it would be a more appropriate link to include on the microprocessor article. Give me a little time to think about it and look over the book in more detail, and let some other editors comment as well. -- mattb @ 2006-12-03T21:06Z

You are right. I'll wait, though, as you suggest, before suggesting it. It really is about the processor only, not computers in general, so it doesn't belong here. Maybe I could talk someone into putting a link there. I wonder if I will be able to erase this. Thank you for your suggestion. Thinkorrr 22:53, 3 December 2006 (UTC)

FAC already?!

I'm a little horrified to see this article put up for FAC - it's nowhere near ready. It's going to get shot down in flames - and justifiably so. We need to get it up to FA standards - yes - but an early nomination makes it harder to get through the second (and in this case, third) time. SteveBaker 15:53, 25 December 2006 (UTC)

I nominated it partially to get some exposure and constructive criticism since the peer review process is pretty much dead in the water. Unfortunately, exactly the opposite happened and nobody is really offering constructive advice; only "the article's prose sucks, fix it" and "OH GOSH NEEDS REFERENCES". Here I was thinking we'd get some discussion on the article's layout and presentation... -- mattb @ 2006-12-25T22:03Z

Career computer

Once upon a time there were people who were called 'computers', as that was their job. Is this fact addressed in the article? Vranak

It is treated in the linked history of computing article. However, this usage is archaic and more or less irrelevant to what the word "computer" encompasses today. Therefore it is left out of this article for brevity and topicality. -- mattb @ 2007-01-04T00:55Z

What's up with 3 C's redirecting here?

Look and you'll notice the redirection. But there is no specific explanation on mention of the term in Computer. What is the relevance of having 3 C's redirect here. I though 3 C's stood for Cool, Calm and Collective (which is an expression, and an article that probably doesn't exist). Thank you! --CyclePat 01:27, 18 January 2007 (UTC)

P.s.: Alternatively there is also 3C's a business term. --CyclePat 01:29, 18 January 2007 (UTC)

ACM special interest groups

There has been one ACM special interest group (SIGGRAPH) mentioned in the article. I have added two others. Still, it is not clear why exactly these and no others are mentioned. In total, there are 12 such groups, and there is a category "ACM Special Interest Groups" for them. However, I do not know a way to insert a link to a category page (the only effect of such a link is that the current page is inserted into the category, which is of course not what is wanted here). --Tillmo 09:25, 20 January 2007 (UTC)

OK, have found out now how to point to category pages. --Tillmo 16:53, 10 February 2007 (UTC)

The add 1000 numbers program has an error.

The add the first 1000 numbers program has an error, it actually adds the first 1001 numbers. This is a very common mistake. it is often refered to as the off by one mistake. The OP code should be BLT. Curtis Garrett Garrett Curtis 23:50, 5 February 2007 (UTC)

There's no mistake in the program. Each number is summed before it is incremented, so the number '1001' is correctly caught by the ble instruction. -- mattb @ 2007-02-22T20:36Z

I stand corrected. I see it now. Sorry about that. Garrett Curtis 22:04, 7 March 2007 (UTC)

Computer

[[I think that computers are an important part in everyone's life now. Most of own computers and most of use them on daily basis. I think that it is cool that life brought us this since it is also the fastest and the easiest way to communicate with your love ones]] —The preceding unsigned by high school student (ralston high school)

Advertisement in article

In the "hardware" overview table, there is reference to "Digi-Comp I, Digi-Comp II, Geniac" which is pointless in a historical overview. I guess it's advertisement for the Digi-Comp.

Besides, I diasgree that "computer" has several meanings: by now it is pretty clearly a universally programmable digital machine. Being electronic, binary or having stored program is not required. --Vincent C M 27 February 2007 —The preceding unsigned comment was added by 194.219.37.70 (talk) 18:20, 27 February 2007 (UTC).

I've removed the Digi-Comp and its ilk. These were just left over from an early version of this article and weren't an advertisement. As for your second concern, it's a difficult thing to reconcile the historical meaning of "computer" with its modern meaning and maintain brevity and consistency. I think taking a formal, purely mathematical approach to defining a computer would be totally remiss since it ignores what most people, expert and lay man alike, think of as a "computer". I also think that the stored program concept is totally central to the notion of a modern computer. Nearly nothing that could be identified as a computer built within the past fifty years is not a stored program machine, and I think that fact is rather noteworthy. I'm also curious why you selected the "digital" criteria for a computer over the others. This article doesn't imply that a computer must be digital, electronic, or binary, though it does spend a lot of time on the all-important stored program concept. If you have any concrete suggestions as to phrasing you'd like to see changed, by all means post them here for discussion. -- mattb @ 2007-02-28T00:26Z

Hard disk is an I/O device?

I thought this was a storage device, not an I/O device. I am probabally hugely mistaken, but...

It is both. -- mattb @ 2007-03-22T14:50Z