Talk:Manchester Mark 1/GA1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

GA Review[edit]

Article (edit | visual edit | history) · Article talk (edit | history) · Watch

Hi, I'll be reviewing this article. The rules for GA reviews are stated at Good Article criteria (OK, Malleus knows these perfectly well, but this is for the benefit of others).

I usually do reviews in the order: coverage; structure; detailed walk-through of sections (refs, prose, other details); images (after the text content is stable); lead (ditto). Feel free to respond to my comments under each one, and please sign each response, so that it's clear who said what.

When an issue is resolved, I'll mark it with  Done. If I think an issue remains unresolved after responses / changes by the editor(s), I'll mark it  Not done. Occasionally I decide one of my comments is off-target, and strike it out --Philcha (talk) 16:09, 8 February 2009 (UTC)[reply]

Coverage[edit]

I think there are significant gaps here from the point of view of a non-specialist reader - or even a techie with no knowledge of the history. A lot of it's what was not present in the Mark 1, to make it plain what a primitive stage in the development of computers this was:

  • A summary of relevant parts of History of computing hardware would help provide context, e.g.: EDVAC was the first stored-program computer designed (proposed August 1944) but only went live in 1951; SSEM was the first one to go live (June 1948); EDSAC live May 1949, 5 months before Mark 1. -Philcha (talk) 16:09, 8 February 2009 (UTC)[reply]
  • The Manchester Mark 1 started work in April 1949, the month before EDSAC started work. Neither machine was complete on those dates. The Manchester Mark 1 was completed in October 1949. EDSAC was slower to be completed and had a less advanced architecture: it didn't get its full main store until 1955/56, didn't get index registers until 1953, and never got a backing store.
  • Should mention that there was no OS, which everyone has taken for granted since the mid-1950s (GM-NAA I/O may have been the start, in 1956, but was only a job queue manager; proper "I am God" OSs only appeared live in the 1960s). --Philcha (talk) 16:09, 8 February 2009 (UTC)[reply]
  • Atlas Supervisor counts as the first OS according to some. The first Atlas was commissioned in 1962.
  • Presumably there was not even an assembler, and the Mark 1 had to be programmed in binary or the compressed representation of binary the article quotes ("ZDSLZWRF")? --Philcha (talk) 16:09, 8 February 2009 (UTC)[reply]
  • Yes, but: they developed a "relatively high level language" for the Ferranti Mark 1 by 1952. Mark_1_Autocode http://www.computer50.org/mark1/program.html — Preceding unsigned comment added by 86.141.217.115 (talk) 02:49, 28 January 2014 (UTC)[reply]
  • Did it have any built-in interrupt handling? I'd guess it relied on clock synchronisation of CPU and memory / drum operations, but what about paper tape I/O? Looks like the first hardware-based interrupt handler may have been around 1957, see e.g. John McCarthy's REMINISCENCES ON THE HISTORY OF TIME SHARING (look for "IBM 704"). --Philcha (talk) 16:09, 8 February 2009 (UTC)[reply]
  • IIRC IBM's licensing of index registers and other Manchester techs was what enabled it to overtake the early commercial leader Univac in the mid-1950s. I.e. the Mark 1 was a significant factor in the rise of "Big Blue". If that can be supported, it's historically important. --Philcha (talk) 16:09, 8 February 2009 (UTC)[reply]
  • Should disambig from Harvard Mark I, often known as "Mark I" in the literature. --Philcha (talk) 22:51, 8 February 2009 (UTC)[reply]
    • This article is called the "Manchester Mark 1", not the "Mark 1". No disambiguation is necessary. --Malleus Fatuorum 23:02, 9 February 2009 (UTC)[reply]
  • Several of the sources I've found say that Eckert & Mauchly: were so overwhelmed by requests for info about ENIAC that they ran a summer school at the Moore School, and the Manchester team got a lot of ideas there; E & M first raised the idea of a stored program computer, but their notes dealt mainly with the engineering issues and von Neumann's more elegant abstract presentation got more attention (and he had more political pull, being in on other programs such as the A-bomb). --Philcha (talk)


I'll deal with structure when coverage issues are resolved. --Philcha (talk) 16:09, 8 February 2009 (UTC)[reply]

  • Replies
Thanks for undertaking this review. I'll try to deal with the issues you've raised:
  • The National Physical Laboratory's Pilot ACE, Cambridge University's EDSAC, and the US Army's EDVAC are already mentioned in the first paragraph of the Background section. Anyone who wants more history can click on the hat to the History of computing hardware.
  • I've explained what system software was available, and that there was no operating system. --Malleus Fatuorum 19:18, 8 February 2009 (UTC)[reply]
  • There was no assembler, the machine was programmed in binary, as you say. I've added a sentence to make that clear. --Malleus Fatuorum 18:48, 8 February 2009 (UTC)[reply]
  • There was no interrupt system. As you suggested, the rotational speed of the drum was chosen to synchronise with the CPU clock, and the machine waited for paper tape operations to complete. Again, I've added a piece to make that clear. --Malleus Fatuorum 18:48, 8 February 2009 (UTC)[reply]
  • I'm not aware of any evidence that index registers or any other of the Manchester licensed technology was as crucial to IBM's success as you're suggesting. Index registers just make it more convenient to iterate through a block of memory. It could be done almost as easily by amending instructions in memory. In fact, the Univac Solid State Computer offered index registers as an option in the early 1960s, but there was little takeup.[1] --Malleus Fatuorum 19:37, 8 February 2009 (UTC)[reply]
Re Univac, I suspect that's because in the 1950s they'd followed the line (later attributed to IBM) "if you find a deficiency, call it a feature and sell the benefits" :-)
And of course self-modifying code was quickly found to be a can of worms.
I haven't found for WP:RS for index regs as a big factor in IBM's rise to dominance, maybe it was just folklore in my early days in computers. --Philcha (talk) 22:51, 8 February 2009 (UTC)[reply]
  • Lavington (1998) says that Williams saw ENIAC on a visit to the US in 1946, and that the summer school at the Moore School of Elecrical Engineering was to design EDVAC, ENIAC's successor. Wilkes (EDSAC) attended the summer school, but none of the Manchester group did. The only apparent inspiration Williams got from his visit was from ENIAC's demonstration that a machine containing 18,000 valves could be kept error-free for long enough to do some useful work. (Might be worth adding that to the SSEM article.) "None of the Manchester group and few people in the United Kingdom generally were in direct contact with ENIAC or the EDSAC EDVAC designers." --Malleus Fatuorum 12:56, 9 February 2009 (UTC)[reply]
Would be worth clarifying how much info was transferred when, with refs. By "EDSAC designers" do you mean "EDVAC designers"? EDSAC was British.
The reliability issue is definitely worth mentioning. --Philcha (talk) 16:10, 9 February 2009 (UTC)[reply]
No information was transferred. Manchester Mark 1 owed nothing to ENIAC or to EDVAC, other than the insight than a machine composed of 18,000 valves could actually work. --Malleus Fatuorum 23:09, 9 February 2009 (UTC)[reply]

Background[edit]

  • Should point out that the Manchester team got a lot of ideas from Eckert & Mauchly's summer school about ENIAC, see sources I found. Sorry I can't remember which sources say what, that's the disadvantage of speed-reading. --Philcha (talk) 00:03, 9 February 2009 (UTC)[reply]
    • No, they didn't, see my comment above. None of the Manchester group attended the summer school, which was about the design of EDVAC, not ENIAC. --Malleus Fatuorum 13:03, 9 February 2009 (UTC)[reply]
  • Should point out that von Neumann publicised the stored program concept in the 1945 First Draft of a Report on the EDVAC, based on discussions with Eckert & Mauchly, who were held back for implementing their ideas by a "freeze" order on ENIAC, but managed to build on a limited read-only stored program capability in 1948. --Philcha (talk) 00:03, 9 February 2009 (UTC)[reply]
    • Mention of the von Neumann architecture was relevant in the SSEM article, but I don't see that it bears repeating here. Neither do I see the relevance of Eckert & Mauchly's 1945 paper. --Malleus Fatuorum 15:37, 9 February 2009 (UTC)[reply]
I'd add "publicised by John von Neumann's paper First Draft of a Report on the EDVAC in 1945" - to methat's mor einteresting than the endianess of any m/c, which is only important for binary programming and for dump-reading. --Philcha (talk)
Well, I don't agree. --Malleus Fatuorum 19:25, 9 February 2009 (UTC)[reply]
  • The whole business could do with a time line - I suggest a compact right-floated table. Should focus on Mark 1 (prototype, Intermediate and Final versions) but show other important events, e.g. First Draft of a Report on the EDVAC (1945), Eckert & Mauchly's summer school (can't remember when), limited read-only stored program capability for ENIAC (1948), EDSAC, Ferranti Mark 1 lifetime, IBM 701. --Philcha (talk) 00:03, 9 February 2009 (UTC)[reply]
    • This article is about the Manchester Mark 1, which was a prototype only in existence for a little over two years. and in its final form for just one. It owed nothing to Eckart & Mauchly's 1946 summer school. A timeline would be rather short and overkill IMO. --Malleus Fatuorum 13:08, 9 February 2009 (UTC)[reply]
  • The para about "Baby" looks rushed and unclear. Needs to separate the sub-topics of memory tech and stored programs, probably in separate paras. Then explain briefly the pros & cons of Williams tubes (advantage was random access to whole words as opposed to bit-sequential access on mercury delay lines, see e.g. http://www.cs.ucf.edu/courses/cda5106/summer03/papers/mark1.atlas.1.pdf; downside doubts about reliability, and some of the sources I found describe the problems and solutions, just cite them w/o details) and of stored programs (faster set-up compared w ENIAC, where it took days to set up a program and minutes to run it). If I've read some of the sources correctly, the combination of Williams tubes and stored program had other benefits (whole > sum of parts)- checkpoint/restart by saving memory to drum, program overlays and saving of common routines on the drum (the beginnings of reusability), which depended on the fast access time of the tubes. --Philcha (talk) 00:03, 9 February 2009 (UTC)[reply]
  •  Not done The phrase proof of concept might be useful to describe "Baby" and set up comparison with Mark 1, which was meant to be capable of real work. --Philcha (talk) 00:15, 9 February 2009 (UTC)[reply]
    • Mark 1 was meant as a prototype for the Ferranti Mark 1; the fact that it could be used to do useful work while the university was waiting to take delivery of the first Ferranti Mark 1 was really just a bonus. --Malleus Fatuorum 13:19, 9 February 2009 (UTC)[reply]
That appears inconsistent with your report that Lockspeiser saw "a demonstration of the prototype Mark 1" and then initiated the Ferranti Mark 1 commercial implementation. Or perhaps you've over-summarised the chain of events? --Philcha (talk) 16:10, 9 February 2009 (UTC)[reply]
The aim was initially to develop a realistic computing facility for the university, but that changed after Lockspeiser saw the demonstration. I'll try to make that clearer. --Malleus Fatuorum 19:25, 9 February 2009 (UTC)[reply]
Done, hopefully. --Malleus Fatuorum 21:01, 9 February 2009 (UTC)[reply]
"From about August 1948, the SSEM was intensively developed as a protype for the Manchester Mark 1, with the aim of providing the university with a more realistic computing facility" doesn't do it for me:
  • "the SSEM was intensively developed as a protype for the Manchester Mark 1" makes it look like the prototype Mark 1 Lockspeiser saw was SSEM with bolt-on goodies. --Philcha (talk) 22:16, 9 February 2009 (UTC)[reply]
  • which would seem to imply that the Manchester Mark 1 had separate objectives, not defined in the article, but not including leading to the Ferranti Mark 1, as that only became part of the plan after Lockspeiser's visit. --Philcha (talk) 22:16, 9 February 2009 (UTC)[reply]
  • I'd move the para "In October 1948, UK Government Chief Scientist Ben Lockspeiser ... and involved an estimated £35,000 per year" to the "Consequences" section. --00:03, 9 February 2009 (UTC)
    • I think it's important that paragraph stays in Background, as it clearly establishes that the Mark 1 was intended as a prototype for the Ferranti machine, not as a finished machine like EDSAC. --Malleus Fatuorum 13:17, 9 February 2009 (UTC)[reply]
See above. --Philcha (talk) 16:10, 9 February 2009 (UTC)[reply]
Nice, I'll add that to my toolkit, thanks! --Philcha (talk) 16:10, 9 February 2009 (UTC)[reply]

Development and design[edit]

  • I think the structure of this section is rather muddled. In particular the first para flip-flops between develpoment history and functional capabilities, without defining the functional elements. I suggest:
    • Quick summary of main components in the Final version (state that this summarises Final version): Williams Tubes as RAM (a term the majority of readers will recognise from computer ads, unlike "main store"); drum as long-term data storage (i.e. data was not lost when it was powered off; no need for "non-volatile"; easier to understand than "backing storage"); paper tape as main input, paper tape and teleprinter for main output; CRT as console display, what it showed controlled by switches; processor that ran programs, i.e. initiated I/Os, did calculations, took decisions; including index register, an innovation that made some common operations like stepping through rows of a table much easier to program (I think this is a more intelligible way of explaining it than "convenient iteration through an array").
      • "Stepping through rows of a table"? What table? --Malleus Fatuorum 22:49, 9 February 2009 (UTC)[reply]
A table is 1-D array of fixed-length records / structures / whatever your favourite language calls them. Index registers are at their best for stepping through the least "significant" (most repeated) dimension of arrays - and for that they are great. --Philcha (talk) 23:14, 9 February 2009 (UTC)[reply]
The point I was making is that there are no "tables" in memory. --Malleus Fatuorum 14:19, 10 February 2009 (UTC)[reply]
    • Fuller description of components and capacities.
    • Development history, with capabilities missing / added at each stage. Should include the prototype seen by Lockspeiser in Oct 1948. I think that implies that the material about use of switches for input and CRT for output in "Programming" should be moved here.--Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
  • The diagram shows no output device. OTOH I'm not sure that showing each of the (?) logic gates helps non-specialist readers. And what the heck was the "Staticisor"? I'd also be inclined to use template:Annotated image as that makes diagram text much clearer at thumb-like sizes, see for example Arthropod#Segmentation. --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
    • The diagram is based on Kilburn's own schematic diagram from his 1949 Nature paper. He doesn't show any output devices, although there was an output tube which could be switched to show the contents of any other tube, as on the SSEM, as well as the teletype. I'll try to explain what the staticisor did in a new paragraph on the general operation of the machine. Basically it was used to hold instructions while they were being worked on. --Malleus Fatuorum 21:09, 9 February 2009 (UTC)[reply]
    • That template has the significant disadvantage that the text would have to be removed from the diagram, thus making it useless at its full size. --Malleus Fatuorum 14:19, 10 February 2009 (UTC)[reply]
  • "1,024 (210) different instructions" appears here and in "Programming", I think it should appear only in "Programming". --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
  •  Done Was it able to handle fixed point arithmetic, e.g. 1.5 + 2.3? (in IBM mainframe assembler, programmers calculate the result's precision and then apply an edit mask to put the dot in the right place for printing / display, and stripping the dot out of input is even more fun; compilers build similar operations into generated code). --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
    • Any machine, including the Manchester Mark 1, can handle fixed point arithmetic by using implied decimal points. It does mean though that the programmer has to keep track of the precision, as you say. --Malleus Fatuorum 15:33, 9 February 2009 (UTC)[reply]
  •  Done How was arithmetic handled internally, in decimal or binary? If binary, was it able to convert for input / output, or did users have to convert the hard way? --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
    • Binary, the machine did the binary-decimal-conversions itself. Added a sentence to say that. --Malleus Fatuorum 14:17, 9 February 2009 (UTC)[reply]
Thanks. Philcha (talk) 16:28, 9 February 2009 (UTC)[reply]

Programming[edit]

  • "Thus "10010" represents "D", "10001" represents "Z", and so forth. Turing changed only a few of the standard encodings; for instance, 00000 and 01000, which mean "no effect" and "linefeed" in the teleprinter code, were represented by the characters "/" and "@" respectively" does nothing for me, and I think the artcile would be better without it, going straight from "The ITA2 system maps each of the possible 32 binary values that can be represented in 5 bits (25) to a single character" to "Because the Mark 1 had a 40-bit word size, eight 5-bit teleprinter characters were required to encode for each word." --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
    • I think it's interesting that Turing was the one who devised the modified ITA2 encoding system, so would prefer to see this material stay. There's also an anecdote that I meant to add about the significance of him choosing "/" to represent binary zero. --Malleus Fatuorum 14:20, 9 February 2009 (UTC)[reply]
  • Re "The Mark 1 had no system of hardware interrupts; the program continued after a read or write operation had been initiated until another input/output instruction was encountered, at which point the machine waited for the first to complete":
    • I think this would be better as part of the list of capabilities (or lacks) in "Development and design".
    • How did Mark 1 wait for a tape / printer I/O to complete, if there were no hardware interrupts? Do you mean programmers had to calculate the I/O completion time and ensure their code executed exactly the right number of instructions between request and completion? If so, should explain this, as most modern programmers work in blissful ignorance (except microcode programmers). --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
  •  Done Presumably once tape input was available programs were input in the 5-bit character coding, which the programmers had to look up / memorise? --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
    • That's right, in fact programmers were encouraged to learn the encoding by heart. --Malleus Fatuorum 14:26, 9 February 2009 (UTC)[reply]
I've just seen "The user is strongly recommended to learn the above table" in the ref. Ah, the not-so-good old days. --Philcha (talk) 16:32, 9 February 2009 (UTC)[reply]
Perhaps more recent than you might think. In the 1970s I worked for Olivetti, programming one of their machines in binary and memorizing the assembler codes, just like on the Mark 1. --Malleus Fatuorum 21:33, 9 February 2009 (UTC)[reply]
Just like you did on the Mark 1? --Philcha (talk) 22:18, 9 February 2009 (UTC)[reply]
  • Some of the material here would be better in "Development and design"'s list of capabilities: "Data was read and written from the papertape punch under program control"; possibly "The Mark 1 had no system of hardware interrupts; the program continued ... waited for the first to complete"; number range it could represent. --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
  • I don't think the endianness is important at this level of artcile (it's not a programmer's guide) and suggest removing it. --Philcha (talk) 01:48, 9 February 2009 (UTC)[reply]
    • I think it's interesting and see no harm in keeping it. --Malleus Fatuorum 14:17, 9 February 2009 (UTC)[reply]

Further developments[edit]

  • I suggest splitting this into 2 sub-sections - one for the Mark 1 lineage (Manchester & Ferranti), including Meg, and another for other lineages influenced by Mark 1 (mainly IBM 70x). --Philcha (talk) 14:36, 9 February 2009 (UTC)[reply]
  • Ferranti Mark 1's Autocoder language provided a form of virtual memory. The hardware features on which this was based were already present in M.M. 1, although Autocoder was only added by Ferranti in 1954. (http://www.cs.ucf.edu/courses/cda5106/summer03/papers/mark1.atlas.1.pdf; Lavington 1993) --Philcha (talk) 14:36, 9 February 2009 (UTC)[reply]
    • The hardware feature Autocode made use of was memory paging between the magnetic drum and main storage, which is already covered in this article. Autocode was developed on the Ferranti Mark 1 anyway, a quite different machine from the Manchester Mark 1, and appeared four years after the Manchester Mark 1 had been scrapped, so I don't see its relevance to this article. --Malleus Fatuorum 15:27, 9 February 2009 (UTC)[reply]
Already covered, but not very explicit and buried in a para that contains other topics.
As I commented re the "Design & Development" section, the elements need to be separated and made more explicit. And sources indicate that "paging" was not just for "one-level storage" but was also used as an early version of checkpoint/restart, in case of tube or other failure. In that respect it's a precursor of the IBM 650. --Philcha (talk) 16:48, 9 February 2009 (UTC)[reply]
Lavington 1978 is quite explicit about Manchester's influence on memory management - I suggest that's a must-have. --Philcha (talk) 17:00, 9 February 2009 (UTC)[reply]
Isn't that just a programming issue, already covered by the discussion of paging on the magnetic drum? I feel it necessary at this point to remind you that comprehensiveness is not one of the GA criteria. --Malleus Fatuorum 23:17, 9 February 2009 (UTC)[reply]
"comprehensiveness is not one of the GA criteria" - yet you include endianness and details of the 5-bit TT code :-)
Non-programmers and, I suspect, quite a lot of programmers (especially those who use e.g. VB or Delphi) will not make the step from M.M 1's paging to virtual memory, so you have to give them a bit of help. Even Lavington (1978), writing for other experts, thought it worthwhile to mak ethe point quite emphatically.
I think before we discuss the details any further we ought to discuss the issue of perspective (below). --Philcha (talk) 23:44, 9 February 2009 (UTC)[reply]
  • IBM 70x series used Williams tube memory up to & incl IBM 709. This m/c was short-lived (1958-1959) as US military customers wanted an all-transistor m/c, and the IBM 7090 (1959 to the introduction of IBM System/360) was a transisitorised 709. --Philcha (talk) 14:36, 9 February 2009 (UTC)[reply]
    • Interesting to read in an article about the IBM 70x series, but here? In any event, the IBM 709 used core storage, not Williams tubes.[2] --Malleus Fatuorum 15:18, 9 February 2009 (UTC)[reply]
Looks like I got mixed up on the details while speed-reading the sources I found.
However there's still a story to tell here. Williams tube lists a range of m/cs that used them, incl some early Univacs (although the 1st used delay lines; so Univac switched!), and the Soviet Strela - unfortunately w/o refs. I think the story is that SSEM was a successful pilot of Williams tubes and M.M 1 showed that they scaled up and were reliable enough - and then widely used, until core memory became available. --Philcha (talk) 16:48, 9 February 2009 (UTC)[reply]
Looks to me like you keep getting mixed up. --Malleus Fatuorum 23:19, 9 February 2009 (UTC)[reply]
How? Was not SSEM a successful pilot of Williams tubes? Did M.M 1 not show that they scaled up and were reliable enough? Did not alot of subsequent m/cs use Williams tubes? --Philcha (talk) 23:44, 9 February 2009 (UTC)[reply]
  • However the IBM 70x also used other design ideas from American institutes, see some of the sources I found. --Philcha (talk) 14:36, 9 February 2009 (UTC)[reply]
    • I don't see how this is relevant in article about the Manchester Mark 1? --Malleus Fatuorum 15:12, 9 February 2009 (UTC)[reply]
Objectivity: the M.M 1 was a strong influence on later computers but not the only one. --Philcha (talk) 16:48, 9 February 2009 (UTC)[reply]
Do you have a reference for "strong influence on later computers"? I don't. --Malleus Fatuorum 23:14, 9 February 2009 (UTC)[reply]
If Williams tube is right despite its lack of refs, a lot of subsequent mcs used Williams tubes.
Index regs were one of the patents IBM licensed, and used throughout the 70x series (and later, e.g. 360 and successors) that made them the dominant supplier.
Lavington 1978 is quite explicit about Manchester's influence on memory management. --Philcha (talk) 23:44, 9 February 2009 (UTC)[reply]

Refs[edit]

Sorry, you're right - I haven't seen a "References" section split like that before, although I think it's a good idea; do I have you permission to copy it? ---Philcha (talk) 15:40, 9 February 2009 (UTC)[reply]
Feel free to copy anything you like, I always do. :-) --Malleus Fatuorum 15:43, 9 February 2009 (UTC)[reply]

Perspective[edit]

The contrast between my comments and your responses indicates that we need to reach agreement on the article's perspective.

My view is:

  • It should be written for non-specialists. In this case I think that means primarily readers with no programming experience, followed by those who have used only relatively cushy development environments - e.g. Javascript, VB or Delphi on the client side; MS ASP, PHP, Cold Fusion, Java, etc. on servers; C / C++ for the few who write systems software.
  • So I think the main points to be brought out are:
    • How primitive computers, incl Mark 1, were in the late 1940s - no OS, no assembler, no hardware interrupts; consequences of these "deficiences".
    • Lavington 1993's table of vital statistics would illustrate how primitive late 1940s m/cs were, even compared with mid-1950s ones. If you throw in bulk and / or weight, power consumption and (where available) inflation-adjusted cost, that will really make an impression.
    • Nevertheless the late 1940s pioneers, notably the Manchester team, introduced many concepts that are became important: the advantages of high-bandwith, random-access memory (see Manchester Small-Scale Experimental Machine on disadvantages of mercury delay lines); index registers; reusable code; the hardware infrastructure for virtual memory, although software support (Ferranti Autocode) arrived only in 1954 and that lineage never had dynamic address translation hardware (AFAIK introduced with the design of Compatible Time-Sharing System, in the late 1950s).
  • Technical details should be just enough to make these points and no more - this is not a programmer's guide. --Philcha (talk) 15:46, 9 February 2009 (UTC)[reply]
  • I really could hardly disagree more with your perspective Philcha. This article, like every other GAN, ought to be judged against the GA criteria. Not against your idiosyncratic ideas of what it ought or ought not to cover. If you believe that it fails on criterion 3 then so be it, fail it and let's get to GAR; I'm not changing the article to suit your perspective. I believe it to be a good (by no means perfect or comprehensive) account of the Manchester Mark 1, which it would not be if I followed your suggestions. --Malleus Fatuorum 23:05, 10 February 2009 (UTC)[reply]
  • Comments from Pyrotec- Sorry, but I fundamentally disagree with Philcha. My background was DOS (or MSDOS), BASIC, Fortran 77, Pascal and I have used a teletype and punched paper tape for input, so I have sympathy with identifying primarily with readers with no programming experience, but I have no interest in "cushy development environments - e.g. Javascript, VB or Delphi on the client side; MS ASP, PHP, Cold Fusion, Java, etc. on servers; C / C++". So I don't see why the article should be distorted to fit those needs. Producing a whole load of defects - no graphical operating system, no CD-rom or DVD-player, no spreadsheets, comes under the category of "stating the bleeding obvious". I would award the article GA-status now. It would be great if I could find some typos or grammatical errors, especially as "MF" is the nominator, but I have better things with to do with my time than hunting for them; and I'm in favour of adding worthwhile improvements. So in summary, "It should be written for non-specialists" is probably the only thing that I agree with in your "Perspective".Pyrotec (talk) 19:54, 10 February 2009 (UTC)[reply]

Conclusion of review[edit]

Regretfully I do not believe that this article currently meets the GA criteria. Although as there is a lot of good research here, it still has the problems I raised above, :

  • (criterion 3a) Although it mentions the index register(s), it omits some aspects of the Mark 1's significance: its contributions to the development of virtual memory (stated emphatically by a good source I found and mentioned in a comment); the fact that Williams tubes, used by the Mark 1, quite rapidly displaced mercury delay lines as the standard memory technology. It fails to explain well to a non-specialist reader how much more difficult programming was in those days because of the lack of an assembler, hardware interrupts and an operating system. It also still omits the advantages of Williams tubes over mercury delay lines as a memory technology (cheaper, lighter, did not require such precise temperature control).
  • (criterion 3b) It goes into unnecessary detail on some points, notably on endianness and on character assignments in the 5-bit code used for the printer and tape reader and punch. The latest version also goes into a little too much detail on the origins of the stored program idea, for example Zuse had no direct connection with the Manchester team.
  • Although the prose is good, the article is unclear on the important point of the Mark 1 project's inital objectives and when and why they changed. The clearest statement is in the lead, but it does not quite match the various parts of the text which deal with this point. I'm not sure whether this is a matter of presentation or whether the sources are not explicit. --Philcha (talk) 23:57, 10 February 2009 (UTC)[reply]


- - - - - please add review comments /responses above this line - - - - -
 If you want to start a new section of the Talk page while this review is still here, edit the whole page, i.e.use the "edit" link at the top of the page.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Manchester_Mark_1/GA1&oldid=592735344"