Wikipedia:Reference desk/Archives/Computing/2016 November 15
| Computing desk | ||
|---|---|---|
| < November 14 | << Oct | November | Dec >> | Current desk > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
November 15 edit
Searching for bibliography about concrete things every programmer knows edit
Searching for bibliography about concrete things every programmer knows
I am searching for a serious treatment of the problems every programmer should be able to solve to claim he knows the language. I am not interested in general advice that is more related to the way we should work: work in team, ask the user for feedback, test the code daily, and so. Nor I am interested in general knowledge that's good to know like understanding Unicode and floating-point arithmetic. It's more like concrete things like inverting a list, or, adding element to it, or loops.
- I would personally begin with The Art of Computer Programming. 209.149.113.4 (talk) 19:38, 15 November 2016 (UTC)
- I respectfully disagree; The Art of Computer Programming is especially academic; and not all programmers require familiarity with all of the contents of that book series.
- "Every programmer" is an immensely broad group of people. I think the OP needs to step back for a moment and reformulate the question.
- Should a VHDL programmer, a Visual Basic programmer, and a programmer of the FMS/FDC computer all be held to the same standard of baseline knowledge?
- Nimur (talk) 20:41, 15 November 2016 (UTC)
- Then, I'd like to restrict the question to general purpose languages like C, Java, JavaScript and so on. Is there a set of problems that any programmer of these should know? In the same way that everyone who claims to speak English must know what 'table' or 'car' mean, but cannot be asked to know the meaning of 'luciferous' or 'lucubration'. Dikipewia (talk) 00:15, 16 November 2016 (UTC)
- confusion: You say "set of problems," which is what The Art of Programming covers. Then you list terms, not problems, which a basic documentation guide would cover.
- Don't go too deep into the analogy. It only illustrates that there are things that all people who have an ability know, and some others are extra. Dikipewia (talk) 02:25, 16 November 2016 (UTC)
- Every programmer probably ought to have a basic understanding of some math concepts, including symbolic algebra and elementary formal logic; and at least a passing familiarity with the abstraction of conceptual ideas using formal grammar; even if they only know these concepts by other names.
- Beyond this very small subset of all possible conceptual tasks, I think you will find that there is such an incredible diversity of programmers that we can't expect them all to share very much more than these fundamentals.
- The languages you list - C, Java, JavaScript - are all actually quite similar: notably, you didn't mention any hardware description languages, nor anything from the Lisp family, nor any of the mathematical abstractions of formal computation like APL or reverse Polish notation; you omitted any domain-specific languages like MAXScript or High-Level Shading Language; no graphical programming tools like Logo or LabView or Simulink or Rational Rose. The list goes on and on... the diversity is incredible. Although these programming tools might be unfamiliar to you, these and many others are each a method for a human to interface to a machine and to provide systematic instructions defining a computational task. A programmer fluent in writing HLSL kernels might be an expert mathematician with a solid background in image processing and numerical physics - but this might shock you, they might never write a for loop or an if-statement, ever, under any circumstances. (That's how you know they're good at their job!) Ever seen a programmer's manual that disrecommends the use of conditional logic? Here's one such document, the CUDA Programming Guide for general purpose computation on NVidia GPUs! How can we expect the same set of knowledge from these programmers as we would wish to find among any old group of perl nuts?
- Computers, and their applications, are incredibly diverse - and so are programmers. You might naïvely assume that all programmers must know certain topics - you might start listing topics like recursion, pointers, iteration, abstract data types ... but even those "generic concepts" are actually only a very small part of the wide and wild frontier that we call programmable computation.
- I would like to see every programmer read at least these three essays, each written by a different but foundational computer scientist:
- Edsger W. Dijkstra, On the cruelty of really teaching computing science (1988)
- Ken Thompson, Reflections on trusting trust (1984)
- Peter Norvig, Teach Yourself Programming in Ten Years (2001, with updates)
- There is much to be learned about computers and computer programming by reading these papers - and really, actually, sincerely groking them. They might not seem "technical," but trust me - they are profoundly more technical than many great textbooks and programming guides. Any programmer who really, actually, sincerely studies computer science should read them. Sadly, this type of knowledge, while actually important for all programmers, is terrifyingly uncommon; programmers spend a lot more time learning for-loops and language syntax than learning how computers do things. In my experience, I find that it's easy to find programmers who can do the Fibonacci problem or otherwise "hack a Google interview." But those skills, while perhaps necessary for certain jobs, are not sufficient for creating great programmers. Programmers of computers, whether they want to admit it or not, are mathematicians. The one common theme is that they must all know computational mathematics, no matter how they choose to apply it.
- Quoting, id., on the inaptness of using certain analogies to explain the terrifying reality that is a programmable computer: "the analogy is ridiculously shallow: it is orders of magnitude worse than comparing, as a means of transportation, the supersonic jet plane with a crawling baby, for that speed ratio is only a thousand." And, on the issue of dealing with properties of all programmers: "The moral of the story is: deal with all elements of a set by ignoring them and working with the set's definition."
- Nimur (talk) 04:58, 16 November 2016 (UTC)
- Don't go too deep into the analogy. It only illustrates that there are things that all people who have an ability know, and some others are extra. Dikipewia (talk) 02:25, 16 November 2016 (UTC)
- confusion: You say "set of problems," which is what The Art of Programming covers. Then you list terms, not problems, which a basic documentation guide would cover.
- Then, I'd like to restrict the question to general purpose languages like C, Java, JavaScript and so on. Is there a set of problems that any programmer of these should know? In the same way that everyone who claims to speak English must know what 'table' or 'car' mean, but cannot be asked to know the meaning of 'luciferous' or 'lucubration'. Dikipewia (talk) 00:15, 16 November 2016 (UTC)
- Complete agree with Nimur. Once you get beyond "Hello World" and "99 bottles of beer" it is very difficult to identify a set of problems or concepts that should be common to all programmers. Will a programmer need to know about objects ? pointers ? memory management ? handling interrupts ? floating point arithmetic ? sorting algorithms ? stacks ? databases ? It all depends on the language and the application. Gandalf61 (talk) 10:07, 16 November 2016 (UTC)
- I agree. There isn't a set of rules for programming in general. I expect, by the 3rd year, that all of my students fully comprehend loops, functions, classes, memory management, etc... Those are the basic tools. Understanding computer programming is, in reality, understanding how to solve a problem and implement the solution. As an analogy, you might know the name and function of every tool in a mechanic's toolbox, but that doesn't mean you can repair an engine. That is why I immediately thought of Knuth. In his class (back in the 70's, I don't know how it is now), he would introduce a completely different problem every week. The problem wasn't important. How you solved it was important. Contrast with McCarthy, teaching down the hall in the same building: He would introduce a programming construct and the goal is to make up a problem to fit the construct. Both are legendary programmers and lecturers who churned out many programmers, but I personally feel that Knuth taught how to program. McCarthy taught constructs that were helpful once you learned how to program. So, if you ask McCarthy, he would likely list recursion first (because it is McCarthy after all), then memory management with various ways to construct every type of list or tree that you can imagine, and then control structures. Knuth would smile and ask if you enjoy solving problems and then give you something that makes the ACM programming competition problems look like elementary school work. 209.149.113.4 (talk) 13:25, 16 November 2016 (UTC)
- For the unfamiliar, IP user 209.149.113.4 refers to John McCarthy, famous for pioneering work in artificial intelligence research and the Lisp language; and Donald Knuth, famous for computer science education research, TeX, and author of The Art of Computer Programming.
- Nimur (talk) 17:15, 17 November 2016 (UTC)
- I agree. There isn't a set of rules for programming in general. I expect, by the 3rd year, that all of my students fully comprehend loops, functions, classes, memory management, etc... Those are the basic tools. Understanding computer programming is, in reality, understanding how to solve a problem and implement the solution. As an analogy, you might know the name and function of every tool in a mechanic's toolbox, but that doesn't mean you can repair an engine. That is why I immediately thought of Knuth. In his class (back in the 70's, I don't know how it is now), he would introduce a completely different problem every week. The problem wasn't important. How you solved it was important. Contrast with McCarthy, teaching down the hall in the same building: He would introduce a programming construct and the goal is to make up a problem to fit the construct. Both are legendary programmers and lecturers who churned out many programmers, but I personally feel that Knuth taught how to program. McCarthy taught constructs that were helpful once you learned how to program. So, if you ask McCarthy, he would likely list recursion first (because it is McCarthy after all), then memory management with various ways to construct every type of list or tree that you can imagine, and then control structures. Knuth would smile and ask if you enjoy solving problems and then give you something that makes the ACM programming competition problems look like elementary school work. 209.149.113.4 (talk) 13:25, 16 November 2016 (UTC)