Tricky Programming Concepts Aren’t
evincarofautumn.blogspot.com
evincarofautumn.blogspot.com
I'm concerned that he's going a little too far in the other direction, though. It's great to come up with a simple or even tautological explanation for concepts. However, those explanations don't address the nuances of why those concepts challenge people in practice. And telling someone it's easy when s/he actually is struggling is just as dangerous.
When I was learning C, I absolutely understood that a pointer pointed to something, and I wasn't bogged down by people telling me it was hard. That didn't stop me from dereferencing null pointers, returning addresses to variables on the stack, getting confused when someone added to a pointer, etc. The aptitude that Joel wrote about and Jon derides isn't the aptitude of applying a metaphor to code. It's the aptitude of coalscing a set of program behaviors into a mental abstraction that is more than "a pointer points."
I don't care what the OP says. This guy was simply not capable of understanding the concepts. Maybe at some level he was, and he had some kind of psychological blinders on that prevented him from getting what I was saying, but he really, really didn't get even the most basic concepts. And when it comes down to it, it doesn't matter whether he has some innate ability that he can't tap -- if he can't do it, even with lots of help, then he can't do it.
While I was helping him, others from the lab came over repeatedly to ask me for help, assuming I was the lab assistant. I WAS able to help a half dozen other students understand their program.
It was his third attempt at taking the class. He finally gave up and changed his major, IIRC.
I remember that it was a pretty straightforward architecture, though. Something like 68000, which I knew already, but it was even more orthogonal with respect to addressing modes. I think it had 16 32-bit registers, and you could use any as an address to load data from, complete with offset for easy manipulation of data structures.
I do know x86, and while the 8086 was designed by idiots, it's not that hard to get the basics. Segment registers are a PITA, but as long as you're using 32-bit mode and not accessing more than 4Gb at a time, you can mostly ignore them. I've had to deal with something similar in another architecture, and you just end up with abstractions that hide the details as much as possible. Same as coding anything else that's nontrivial, really.
Of course, I'm also not sure that Joel's suggestion that some people have an aptitude for such understanding is "irresponsible." If you were to say he underestimates what people can pick up with practice, that would be a different story.
I think you could spin a lot of plausible pedagogical theories, but I'd be more interested in seeing some actual evidence.
The other thing to remember is that teachers speak to roomfuls of students at a time, not one student at a time. If you've got one student, then sure, you need never explicitly say that a particular concept is tricky. You can determine trickiness by trial-and-error: If the student gets confused at any point, explain again, but otherwise just keep going.
But with a whole roomful of people it's not as if you're going to fool them by avoiding the word "tricky": They're going to know when you cover something that is tricky, because half the audience will be confused, and the other half is then going to have to observe you explaining the tricky thing over and over again to the first half.
Also, in my experience, when people (especially teachers and professors) say "this is tricky", it is often in part or in whole because they are only giving you a partial explanation -- part of the picture.
It's "tricky", because they are telling you to accept certain things prima facie when actually (for me, at least) they'd make a hell of a lot more sense and be easier to absorb with a more complete description/explanation.
Some of the time, this is because they don't really understand the topic themselves. Other times, one or another pedagogical inclination or requirement makes them avoid a deeper discussion. ("I don't have time" or "We don't have time" or "That's beyond the scope".)
That is same problem as saying "Oh, this is hard and tricky." The author didn't seem to suggest to tell students things are easy, which is misleading and harmful, but rather he used the example of art teachers where the students are not told that things are easy but rather they need to practice and put in a lot of effort. Hell, he didn't say the word 'easy' once in his blog entry.
Lecturers and many others seem almost afraid to say "You're going to have to work hard." and then stand by that statement.
I'm currently at university and I've seen exactly what he has said. Lecturers and students saying x is hard and tricky and for most of the other students here that seems to have demotivated them. I think the current schooling system here in Australia and in other countries in the world where I've spent time or have friends from is horribly flawed in many ways and what this blog entry about is just one of those flaws.
The research states that flow is achieved by balancing skill and challenge. http://en.wikipedia.org/wiki/Flow_(psychology)#Mechanism_of_...
With respect to the original author, it sounds like he hasn't been far enough along in his career to be humbled by a hard problem.
[1] I'll fully grant the possibility that I'm teaching them in a sub-optimal way. But very few people have the luxury to learn from the optimal teacher.
[2] It's conceivable that some people have had experiences and training that, while not formally programming, have nevertheless taught them the abstraction and logical reasoning skills that are necessary to understand core programming concepts.
"I've seen that the 100% Java schools have started churning out quite a few CS graduates who are simply not smart enough to work as programmers on anything more sophisticated than Yet Another Java Accounting Application, although they did manage to squeak through the newly-dumbed-down coursework...I used to be able to tell the smart kids because they could rip through a recursive algorithm in seconds, or implement linked-list manipulation functions using pointers as fast as they could write on the whiteboard. But with a JavaSchool Grad, I can't tell if they're struggling with these problems because they are undereducated or if they're struggling with these problems because they don't actually have that special part of the brain that they're going to need to do great programming work. Paul Graham calls them Blub Programmers."
For extreme examples, try digging into some of Haskell's features -- I still have no idea what arrows are, but I've been given the impression that they're advanced and hard to understand -- or reading some of the discussions on Lambda the Ultimate. It usually turns out that the concepts are surprisingly simple, but it takes a lot of sifting through academic language to figure it out.
I find more and more that blogs are great for discussing things you already have deep knowledge of, or of finding leads to resources for learning them (book recommendations, etc.), but there's no comparison to books for really learning something well.
Blogs are just too piecemeal, and the articles are usually written in a few days or a week, versus up to a year or more for books. Hence the quality of pedagogy is just much higher with books than blogs.
Even as someone who writes a technical blog, I'll agree that blogs aren't the best medium for disseminating learning materials. That's what proper online documentation and books are for: specialised topics, in long form. I can write 50 1000-word blog entries and help people on more topics, but fewer people per topic, or I can write one 50,000-word book and reach many people on just the one.
And of course, neither books nor blogs nor language references, etc. substitute for actually sitting down and programming something challenging. But they can help reduce the amount of initial time wasted on trial and error, get you using the language idiomatically, and get you up to speed on language-specific best-practices faster.
Although the time could arguably be spent more productively improving said documentation, sometimes an informal tone (which may not be appopriate in docs) can help to dissolve frustrations..
Sure, they could use terms that are easier to understand to the uninitiated, but then you risk having to explain your terms every time because people use different ways to refer to the same thing. Jargon evolves precisely to solve that problem, at the cost of making it harder for somebody new to understand.
Obviously when learning these things, you need a clear and easy to understand description of the terms, but as others have stated, a book usually does this, while blogs and research papers probably assume you already know whats what.
Managing code with pointers is hard, but grasping the concept is easy.
Closures are far more confusing.
I didn't learn regular expressions for a very long time because people said they were hard. That was stupid. It took me a couple of days to get good at them.
When the teacher says "this is tricky", consider the possibility that they aren't merely trying to motivate the students. It might just be a simple statement of fact: There's a significant population that doesn't get this at first glance, and you have to know that, regardless of whether you get it yourself or not.
Why? In my mind, managing student psychology is more important than conveying meta-facts. If a student will learn slower if you tell them that other people find something hard, then don't tell them that. As a bonus, the meta-fact might become less true.
I learned to use them long before I had any clue what a DFA was or had even heard of an accepting state. It was pretty intuitive to me that you just have to specify these patterns and it would match whatever you told it to.
When I later read more about the theory and how they were constructed in a compiler book, I wouldn't have been able to decipher a word of it if I hadn't already known how they were supposed to work.
I wonder why more books don't show you what they do before showing you how they're made.
IMO (obviously this is subjective) this is not true but it depends upon whether you mean confusing to use or confusing to understand the full implications of a thing under the hood.
Closures are pretty easy to start using for just about any halfway decent programmer if you lay off the theoretical underpinnings and just show them: here do this, and this will happen. Actually understanding how they function is another matter, but to just start using them is fairly simple assuming the language you are using supports them natively.
Pointers on the other hand are a fairly simple concept and unlike closures there is really no depth to the concept, but because most people's brains don't deal well with indirection beyond one level, pointers are very "tricky" when it comes to training your brain on how to use them correctly even after you understand the concept.
Closures are easy to use, hard to grok; pointers are easy to grok, hard to use, so which is more confusing depends a lot on what you mean by confusing.
I've spent much time tutoring people on various subjects, programming, physics, math. And the fact is there are just some people who can't grasp certain concepts. From my observations I think the culprit is a poor ability to integrate information into a single mental model. I've seen this many times. Someone can understand concept A, B, C in isolation, but when you try to guide them into combining the three to solve a problem they break down.
I think this really goes to the heart of intelligence. More intelligent people can integrate more information at a single time. This is probably related to working memory (there isn't a single place in your head where working memory functions, but its spread out). Tough concepts like pointers exemplify this. You need to understand the memory model, accessing a memory location, using that info to index back into the memory array, and how the syntax of the language supports these actions.
Analogies can help as it reduces the amount of info you have to hold in your head, but its not a replacement for understanding what it actually is. I think its time to admit that there is an intelligence barrier to some concepts that some people don't cross.
What I mean when I say such things is that I have a mental model of the student's current understanding. That mental model is based off of what I have taught them, and the understanding they have demonstrated through questions and assignments. When I try to think about this concept with just those tools, I think it may be difficult to understand.
I always try to build a bridge from their current mental model (or, more accurately, my mental model of their mental model) to the mental model required to understand this new concept. If I have difficulty building that bridge, then I think it is a "tricky concept" for them.
Except they aren't the same thing in many programming languages. In particular C++.
To implement a linked list, just open your eyes and think about what the term means: it is a list, and at each place there must be a thing, and the address of the next thing if there is one.
This is one example of a type that you probably won't use a reference in C++ (at least not a mutable linked list).
The thing the author did was actually swapped out one analogy for another, although unknowingly. To really get away from analogy is to point out that there are values stored in memory locations (determining the value uses metadata associated with memory locations). You can use those values literally, or you can use them as an index into other memory locations -- and then recurse (to tie both concepts together).
Also, I didn't swap analogies: I traded analogy for metaphor. (A reference in a computer program is a conceptual reference in the real world.)
A pointer is a memory address. That's all it is. It can contain any valid memory address for the system.
A C++ reference is essentially a hard link to another declared object. As far as the compiler is concerned, a reference to an object is the object, and therefore has all the attributes that the original object has.
Pointers are like a house street addresses. They do not directly allow the user to see anything about the house, but they tell the user where the house is.
References are like what people call a certain house. I may call the house I live in "home", but my friend Bob may call it "cube13's house". Both myself and Bob use different terms for it, but we both mean the exact same physical location.
I think you're beginning to walk that line where people start getting confused -- "I thought you said they were the same thing. Now you're saying they amount to some modified version of what you said?"
Also, I didn't swap analogies: I traded analogy for metaphor. (A reference in a computer program is a conceptual reference in the real world.)
I'm no grammar buff, but that seems to be walking a fine line. From my most recent CS SAT test:
reference::computer as conceptual reference::real world
In any case, many would argue that metaphor is equally dangerous. Djikstra has ranted on this very topic, saying it creates dangerous visualizations.
My point is that there is way to teach the concept relying on neither analogy nor metaphor, but a more basic concept of how data is stored. I think you'll find different students will react favorably to different techniques.
"Amounts to" is a phrase that lets you say pretty much anything. Eg: A pointer amounts to an int.
If you are going to say that it amounts to an immutable pointer, you should at least add a caveat about how int *const x; would be different from int& x;
Is there a reason why this analogy is invalid? I found it to be quite useful in using, understanding and explaining C pointers.
Pointers are not ints. First off, pointers are unsigned data types. Also, on 32-bit systems, they're 32-bit unsigned longs, and on 64-bit systems, they're 64-bit unsigned long longs.
Both of those are incredibly important to understand, especially because the first can lead to very weird bugs with unsigned/signed comparisons or addition. I recently ran into a bug that involved that. 50% of the time, the program crashed with an incorrect memory address error. The other half, it worked completely fine. It turned out that we were casting a couple of pointers to signed values before doing some range checking. The cast converted them to hugely negative values, which broke the comparison check and sent us down a completely incorrect code path.
The second is important when dealing with structure and class allocation sizes.
Just want to point out that "int" is not a fixed defined size in C++ either, it just has a minimum size. You equally cannot depend on the size of int or void*.
It is to make it OK for students to not understand right away and not feel bad about asking questions.
Example: Shortly before a final exam for an undergraduate introductory course on logic, there was a student behind me who said "I still don't get this De Morgan thing"
This was something that was covered in the first week, it was impossible to do about 90% of the work in the class without it and has got to be at least as obvious as pointers and recursion. The student was trying in the class and went to office hours, study groups, etc.
I still don't have a good explanation for how someone can't grasp De Morgan's laws in under an hour, much less after 16 weeks of class.
Have you ever had to read something unfamiliar that you found incredibly boring (think reading a patent application)? You end up reading the same page over and over but you absorb very little of the information. Your mind just moves through the words but doesn't make the effort to understand what was being read. This occurs simply because you don't have enough interest in the material at hand.
Seeing how intimidation can factor in this is a bit more difficult. You can usually see this by watching someone try to solve something that they think they can't solve. A lot of times people in this situation make a lot of half hearted a attempts but rarely follow through. I think this is similar to how people struggle when they are put in a situation where they need to make a really open ended decision and get overwhelmed by the options.
Edit: clarity
As the great teacher, Richard Feynman puts it: "if you can't explain something to a first year student, then you haven't really understood it"
So, if numerous professionals are having trouble understanding a concept - or, they believe they understand something when they really don't, which is actually worse - then that seems to me to be empirical evidence arguing that said concept is probably difficult.
And of course you can make the argument that it just happens to be the case that these concepts are easy and society has just happened to promote a bunch of morons into professional positions, but I think that is the more difficult hypothesis to prove.
As to why they don't understand - well, who taught them?
I personally love pointers, and have a bad habit of trying to do my own memory management with them.
I'm certainly not saying that anyone who writes software needs to know the ins and outs of a modern CPU, but basic knowledge of how a computer works (memory, CPU, DMA, mmio, etc...) is what's often missing when talking about low level programming concepts.
Coroutines: A subroutine is a basement which you go down into and come up from via the same door. A coroutine, by contrast, is an adjacent room with several doors and you can leave temporarily even if you're not completely done in there (of course, you must re-enter whichever door you previously left; not a perfect analogy).
Concurrency: doing multiple things at once. In a kitchen, concurrent actions work best when the cooks either don't share resources or have clever schemes for ensuring there is always an alternative activity to perform if resources are in use. This can be as simple as getting on a list for the knife, or blender, or what-have-you, and you'll be called when it's open.
Caching: I dislike going to the grocery store every time I am hungry so I cache things I will need to make shorter trips on average. How much you cache at once is important to determine.
Regular expression matching: This isn't what I'm trying to find, this is a description of what I'm trying to find.
(When you're painting, for example, you keep pencil, eraser, brush, paints, and palette nearby, because they're in active use and it would take awhile to fetch them every time you needed them.)
Your other examples are great though. I worked in a kitchen for a couple of years and it's definitely all about concurrency.
Either way, thanks. And, your article is fucking brilliant. I might ape its style soon in a few "Learn Perl" articles of my own.
1) '[\d]' means any digit
2) '+' means one or more
3) '[\d]+' means one or more digits
Understanding that is not hard or tricky at all. Using that to build a complicated regular expression is hard.
I think that's the author's point. Understanding the concept of a pointer or recursion is not hard. Actually using those concepts to build something takes practice and hard work.
edit: formatting
Problem solving is difficult. Recognizing how to apply dynamic programming is difficult. NP-completeness proofs are difficult.
If I'm learning a semester's worth of new things, and in there 10-20% is going to be discontinuously difficult, I want the prof to acknowledge that fact. I hate feeling like an idiot, and an acknowledgement that a particular topic requires a manner or mode of thinking orthogonal to what I'm used to helps a lot.
But...
There is a huge difference between understanding something and knowing how to implement that knowledge properly in the real world. The former is a building block for the latter, but just the understanding of what pointers are or recursion is doesn't dictate someone's ability to use them properly or efficiently.
Indeed. I find that essay writing and programming light up exactly the same parts of my brain.
On an only vaguely related note, this reminds me of something from college. I was helping a friend of mine who was taking an intro to programming class. It was in C++, and he had been given a class outline for a queue, and was required to fill in the implementation. I was horrified to find that the teacher's class declaration used method names "NQ" and "DQ".
I honestly question whether the instructor even understood the meaning of the word 'queue' and how 'enqueue' and 'dequeue' are derived. It was obvious that this cutesy shorthand completely obliterated any hope of my friend ever making the mental connection between the code and what it conceptually represented.
(Incidentally, they also taught C++ streams for I/O. Apparently, their goal was to prevent new programmers from succeeding)