Not impressedby Artelius (Login Mikrondel)
Note: this is a harsh criticism of the article. Please sit down before reading. My intention is to help you improve for the future, as evidenced by the examples and suggestions I give. Don't take it personally as it is not personally motivated.
The article is poorly written, poorly structured, poorly formatted, light on theory and analysis and makes some confusing and incorrect statements.
I found it quite hard to read given the poor sentence structure and lack of punctuation. The typos didn't help either. Put more effort into your communication and get someone pedantic to PROOFREAD.
The thing seemed like an unplanned ramble about program optimisation. For instance the "introduction" is not introducing the subject at all; it's a piece of optimisation advice that belongs in the body of the article. An introduction should introduce the subject and give an idea of what's going to be covered in the article. There was a lack of consistency as well; some sections got lots of discussion and examples while other (equally important) sections got just one paragraph which did not go into nearly enough detail for the average reader.
Better formatting would be nice too; at the very least I suggest making the headings larger and using a different font for code. A few paragraphs had their first line indented, most did not, and those that did were not indented consistently. Inconsistency looks unprofessional. There's even a CSS property (text-indent) for automatically indenting the first line of each paragraph. Don't use spaces! (And DO use spaces for code; and put it in a <pre> block or equivalent.)
Finally, the actual content felt really amateurish. Lots of observations but very little explanation for them, very little reference to established concepts. Some things in particular:
Why are one-line ifs slower? They're not! It's the use of AND/OR that is slower. I get pretty even results when comparing the structured IFs with this:
IF a THEN IF b THEN IF c THEN IF d THEN IF e THEN IF f THEN x& = x& + 1
So what's wrong with AND/OR anyway? BASIC guarantees that both their arguments are evaluated, even when unnecessary for the final result. It would be nice if you explained this.
Your "statistical" partial array fill
FOR i%=1 TO 300000
Array%(1000*RND, 1000*RND)= RND*7
is NOT equivalent to the other method! The important difference is the "statistical" method can modify array elements more than once, meaning that the number of filled elements will be on average smaller than using the other method. This will become more noticeable if you increase the proportion of the array you want filled (to 90% say).
"Assembly or ASM is a programming language which can be inserted inline in most other programming languages" is untrue. Very few programming languages support inline assembly language.
Recursive factorial isn't as hideous as you make out. It's the same time complexity as iterative factorial. The question should be which one is easier to understand, easier to read (as you rightly say elsewhere in the article). Recursive algorithms take a bit of getting used to but I really do believe they are more elegant and easier to reason about.
Recursive fibonacci can be hideous, though. Without serious compiler optimisation, its complexity is exponential while iterative fibonacci is linear. Yeuuch.
Finally it's extremely disappointing to see no explanation of algorithmic complexity analysis. Not even an intuitive explanation that avoids the mathematics. (The complexity of some algorithms is presented in the sample programs, but without adequate explanation of what this means. Inconsistency again.)
Yes, there are many points the article is dead right about, such as optimising the code that consumes the greatest part of a program's runtime, and optimising for readability as much as possible, and I'm sure it would be useful for people who are looking to improve the speed of their programs. But it could be so much better.
Sorry to tear your article to pieces like this; my intention is to help you improve the quality of your articles and point out factual errors - good quality, accurate articles are sure to attract more readers, after all.
Return to Index
|Response Title||Author and Date|
|You should talk! That's better, N54 loves it!||Clippy on Nov 13|
|STUPID N54||Artelius on Nov 13|
|wall of text||stosb on May 16|