Talk:Computer program/GA2

GA Review

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

Reviewer: Ovinus (talk · contribs) 17:44, 7 June 2022 (UTC)[reply]

I don't think this one is ready for GA yet. Broad comments:

History is rather long and focuses on less-useful things. I'd trim down the section on Relay-based computers (example: The Mark I's integer registers were 23 digits wide (binary or decimal?) and had various units for setting constant values, program execution, arithmetic operations, special functions (trigonometric and logarithmic), and output.)
"4-bit microprocessor" – The concept of what an "n-bit processor" actually is is not really defined.
The Harvard architecture's concept concept of separating instructions from data, along with the fact that modern computers have elements of both, should be introduced early on
Mention of non-x86 ISAs seems relevant (at least ARM, maybe RISC-V, PowerPC, etc. in passing. CISC vs. RISC is relevant too, I think)
To characterize the implementation of SIMD (SSE introduced 1999) in the same subsection as 16-bit x86 is misleading. For a history section spanning the whole of programming history there deserves to be a paragraph on the continuing widening of registers. ARM even has 1024-bit registers in its Scalable Vector Extensions now
Expanding memory capacity from 16-bit to 32-bit, 64-bit is not discussed
Definitely needs to be a paragraph on the transition from assembly language to higher and higher-level languages. I know it's discussed in Programming languages, but it's a critical part of history
The Computer programming section simply doesn't belong. It's also described at a massively different technical level than the preceding section.
The standardization of languages like C, Fortan, C++, and even high-level languages like ECMAScript, should be discussed somewhere
Program examples in Object-oriented programming are... wanting. First of all, C is not an object-oriented language. Second, it includes such distracting information as include guards and a Makefile. The inclusion of a Makefile would only be warranted if, say, discussing the various stages of compilation, but that's not done.
"The principle behind a functional language is to use lambda calculus as a guide for a well defined semantic" – No one but students who have taken a class in, say, formal language or functional programming, will understand this sentence and the following description
"A functional language compiler will not store this value in a variable. Instead, it will push the value onto the computer's stack before setting the program counter back to the calling function. The calling function will then pop the value from the stack." Not necessarily true; compilers will transform functional constructions into whatever they think executes fastest on a given CPU, which probably does not involve a memory access

Essentially, I think this article talks about less important things, and is overall far too technical for the base article "Computer program". Of course such an article would include technical parts, but a less-informed reader, who perhaps has never written a line of code in their life, should be able to skim the article and take away some main thrusts. Ovinus (talk) 17:44, 7 June 2022 (UTC)[reply]