9 times out of 10 a list like this includes a treatise on floating point number representation, which while useful, probably isn't of utmost importance in the 21st century, but hey, at one time folks thought that was required for 'all programmers' to read. At least this list does seem more up to date and relevant.
I just wish we'd stop with 'all X should' titles. Its demeaning and inaccurate.
Are these strictly required for anyone? I suppose not. But they would be useful for everyone, and we'd all be better off if everyone had a stronger understanding of these things.
Also, I think finding "should" as demeaning is a bit much. "Should" means that the author thinks the benefits of knowing something outweighs the costs of learning it, nothing more. Pretty reasonable. Doing anything else is reading too much into it.
I would disagree (with the extent of their applicability and general usefulness). Not that this isn't somewhat useful to many or most programmers -- you may certainly be right about that -- but there are other subjects (like data structures, for example) that are probably a lot more useful, and serve as much more fundamental underpinning for common technologies. So, yes, we'd all benefits if more programmers learned this stuff, but we'd benefit even more if they spend their time on even more important/general CS topics.
Because programmers spend much of their time in code they sometimes tend to place too much emphasis on code over working, well-behaving, performant running programs. Producing such programs requires a lot more than "the right" programming style: it requires a good understanding of hardware, of requirement analysis, of common failure modes, of algorithms and data structures. Programming style (or language) is just a part of what's required, and probably among the least important parts.
The widespread belief among PL people is that "good" programming languages (for your own definition/preference of "good") promote good working software, but not only has that never been proven, there isn't much evidence to suggest this is even true at all (now, I'm not saying it's not true, but just playing devil's advocate and pointing out it isn't evidently true).
 Proof: binary (and other types of trees) trees are used in every programming language, while classes, object, higher order function or monads are most certainly not; ergo: you can certainly program -- and produce good, working software -- without classes/object/high-order-functions/monads, but you can't produce good software (in general, that is), without knowledge of trees (and/or other data structures).
Knowledge of the fundamental concepts talked about on that list of papers, and the history therewith, is what allows us to go past the current level of engineering and actually reach greater heights. Most of the emphasis nowadays is spent on knowledge of specific toolchains, frameworks, etc, instead of actually learning WHY and HOW these things work.
From that basic foundation you can then go into any field and learn the semantics, details, and problem-specific techniques to deal with the problems presented. Without that foundation, we're all just floundering around, becoming proficient in using these tools without actually KNOWING how they work and therefore unable to take them to the next level.
 - A conversation with Alan Kay https://queue.acm.org/detail.cfm?id=1039523
Perhaps you're confused. Most people who refer to themselves as "web designers" aren't meant to be or and aren't trying to be computer scientists or engineers. Many of them have a graphics design education, or taken inspiration from that tradition. Some of the more technically-minded of them can do basic coding, but most of them stop at HTML and CSS. But they're better than I am at UI/UX, and visual design, because that's what they do. They're not meant to be computer scientists.
But I do share your opinion that there are certain foundational concepts and knowledge that all professional programmers should have in common, including some of the papers referenced.
I'm not trying to create separate categories between front-end, back-end, desktop, CLI, and systems engineers. The distinction I am trying to make though is that yes, while Computing has become a vast field, there simply are some basic fundamental skills that are absolutely required if we want to go beyond our current level of achievement.
These are things that you have mentioned: deep knowledge of algorithms, data structures, software engineering, computer architecture, etc. This is absolutely the MINIMUM requirement Without understanding these things, we will stay at this present level of software engineering forever. Sure we will have mastered the tools, and the current programming-paradigms that these tools teach us, but we will not be able to advance.
I've been studying Computer Science for the last four years (BSc and now MSc) but was coding for maybe three years before that.
By the time I finished 2nd year of Comp Sci I had a pretty good understanding of algorithms, design patterns, some theory (Petri-nets, state machines, etc..), databases, etc. Going into my MSc, there is quite a lot that you can't learn without reading papers. For example, chances are you are going to have no idea how to solve the consensus problem in a distributed system without reading Paxos.
Unrelated to numeric computing, my favourite thing would be Butler Lampson's Hints for Computer System Design.
Edit: Changed 'In some ways duck typing' to 'In some ways weak typing' as rightly pointed out below.
It's weak typing (or equivalently "automatic type conversion" as you say) that is to blame. "Duck typing" - also "structural polymorphism", "subtyping polymorphism", know in OCaml as "polymorphic variants" and adopted as a default by Go's interfaces semantics - would only enable "'10' + 10" if String type would have a method "+(x:Number)", which most likely is not there, or if it is it's explicitly laid out.
It's weak typing - ie. language trying to coerce elements of expressions to the types which make the whole expressions make sense, with implicit rules that no one ever reads - that's dangerous.
Sorry for being this pedantic, but while I'd like to see less weak typing in languages (outside of some specific domains, like AWK) I'd also would like to see more "duck typing", because it's more convenient than nominative polymorphism and exactly as safe.
We don't need to say "all must know X things" in order to convey a notion of a well-rounded programmer. Of course we don't have to agree. Still, generally speaking, I think the bare minimum is this: the ability to solve your problems with the languages and tools you know in a reasonable amount of time.
But that doesn't say much, so any list needs to get more specific:
* ability to use your tools
* ability to decompose a problem
* ability to debug a problem
* ability to communicate intent via code
* ability to communicate intent via language
Especially the closer one gets to domain specific things, yes. But I think it is beneficial to all who develop software to realize from time to time how deep the rabbit hole of implementation specific complexities goes, mainly so they understand how to design their systems without stepping in any "obvious" implementation specific landmines.
But in general I think your post validates the claim, since I really need to be aware of of all the traps in the floating point number representation to do my programming job properly :)
a) Hope they suddenly improve, which is probably not going to happen
b) Accept they have limits and encourage them to use systems and frameworks that are hard to screw up on, written people who are good at security?
I note in the Sony hack the only computers that survived basically intact were Macs, not I guess because their owners understood security but because they were well designed and idiot friendly.
Wow, this is utterly worthless, if not harmful, advice. There is no correlation between choosing PHP for an application with the security of said application. PHP apps are so widely deployed that securing them is a pretty well-known process at this point.
The Hoare paper actually linked is hopelessly outdated, despite being an interesting historical artifact.
Yeah, I know, make your own list. Maybe I will. Nonetheless, the author specifically mentions "cover a wide-range of topics" as a goal and this list fails to meet that goal.
Personally, I'd like to see a concept map of essential computer science topics combined with some of the top papers and books that cover each. It could be implemented as a curated collapsable directed graph.
I've tried building one of these before, both for CS and for Maths. Funnily enough formatting, displaying and making it accessible (whilst retaining enough data) was the time-consuming issue, despite all the tech around for handling graphs. :/
Disclaimer, I'm a PL researcher, but I work in a systems group.
These are definitely interesting papers, especially to someone like me who has a much stronger interest in programming languages than other (admittedly essential) topics like performance and similar, but this selection is a revealing demonstration that a lot of people who are heavy into functional programming tend to think that FP is the silver bullet of software engineering and that beyond it, there's nothing really interesting worth learning (especially not OOP or other non-FP methodologies).
I know that this is the kind of effect the paper had on me (I spent a lot of time carefully reading it shortly after it was published), and now I almost never use what knowledge I gained from it to make performance optimizations, but it does frequently discourage me from attempting optimizations that I now know would probably not have the desired effect.
The foundation of information theory. It is, by far, the most astonishing paper I have ever read. Far more astonishing than Lamport's famous conclusion about clocks. It is the kind of paper that causes a soul rift when read thoroughly.
Great stuff! But there are way more important whitepapers to be honest. I can't really think of the others right now, but if you go to the Digital library from ACM / IEEE, you can find really good stuff.