9 ms·

Tricky Programming Concepts Aren’t

Apocryphon 15y ago
It's good to see someone bluntly take apart common misconceptions.
- evincarofautumn 15y ago
  My pleasure. It's good you find it blunt: I tried to be concise so people would bother reading.
  - nasmorn 15y ago
    tl;dr Programming is not as hard as people make it out to be.
    - evincarofautumn 15y ago
      No. Pointers and recursion are easy. Programming is hard, like writing and design, because it is both.
      - danso 15y ago
        Why can good programmers claim to be both good at writing and design whereas writers, under that taxonomy, are only good at writing? Isn't good writing inherently a type of good design, in terms of presenting an "interface" to the reader and adroitly arranging the elements?
        evincarofautumn 15y ago
        I meant only to equate the core skill set of the three. Programmers aren't necessarily good writers of literature or designers of graphics, but neither are writers necessarily good writers of software, nor artists good designers of it.
- xlm 15y ago
  Agreed, that was refreshing (and affirming). 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"
  - danso 15y ago
    Doesn't this underscore the argument against the OP? If Feymnan is correct, this means that many CS teachers don't really understand these concepts that they tell their students to be "tricky." 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.
    - rcfox 15y ago
      Or perhaps these people just repeat "this is tricky" because that's what they were told. These people probably also say that Java is slow and Perl is a write-only language. It's easier than having a real opinion.
    - evincarofautumn 15y ago
      Feynman is wrong. Understanding something (technical skill) doesn't automatically make you good at explaining it (communication skill). Being poor at explaining something does not necessarily betray incomplete understanding.
      - mechnik 15y ago
        Feynman is not wrong. Technical skill does not equal understanding something. Consider an idiot savant who is technically proficient at playing piano but can't string two words together. These definitions of 'understand' may help: 1. Perceive the intended meaning of (words, a language, or speaker): "he could usually make himself understood"; "she understood what he was saying". 2. Perceive the significance, explanation, or cause of (something): "she didn't really understand the situation". http://www.google.com/search?aq=f&q=define%3Aunderstand http://www.google.com/search?aq=f&q=define%3Aunderstand
BrianHV 15y ago
I'm on board with his basic pedagogical point: don't tell people you expect them to struggle. 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."
- evincarofautumn 15y ago
  My point is that a memory reference is a conceptual reference. There is no difference. Understanding references is not about building abstraction atop your understanding of them; it's about recognising that you can express natural abstractions literally through them.
  - BrianHV 15y ago
    I'm unclear on what it means to "understand references" in a way that doesn't involve the way they behave in code. Unless you're saying that the concept as it appears in code can be explained entirely with the tautological definition, in which case I would be inclined to disagree. 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.
    - evincarofautumn 15y ago
      I just think he comes too close to saying that it's entirely the onus of the student to understand the concepts, when the other half of the problem is that they're being taught (in my humble but loud opinion) incorrectly.
qntm 15y ago
Of course, there are plenty of actual tricky programming concepts: closures, tail recursion, coroutines, memory management, concurrency, regular expression matching, caching, algorithmic complexity, naming things...
- evincarofautumn 15y ago
  And you've just given me an idea for my next article. :)
- gatlin 15y ago
  Another commenter made a great point that knowing how and when to use these things is likely more difficult, but having a good grasp of the concepts is important. Here is a minute of me stabbing at analogies: 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.
  - mark_story 15y ago
    Great explanations.
    - gatlin 15y ago
      Thanks! Maybe the author of the article will agree.
  - 15y ago
matan_a 15y ago
Interesting article and it does go a good job of explaining these basic concepts. 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.
- evincarofautumn 15y ago
  True, but understanding goes a long way toward practical skill.
  - matan_a 15y ago
    you are definitely right about that
RyanMcGreal 15y ago
> This is exactly like the process of essay writing Indeed. I find that essay writing and programming light up exactly the same parts of my brain.
adbge 15y ago
I'd love to see more programming abstractions described in simple, no nonsense terms. I think that, as programmers, we often get so used to our own jargon that we unconsciously create a non-trivial barrier to entry. 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.
- theFco 15y ago
  In my case I think it is after "a lot of sifting through academic language" that I get a cool idea through my thick skull. Academic language is (or should be) about being precise not obscure. What I am trying to say, is that learning takes time. The simple, no nonsense terms resonate in your mind after you really grasp the concept. Otherwise it's just a high level overview that won't allow you to really use the concept.
- SkyMarshal 15y ago
  If you learn something like haskell from books instead of blogs, the explanations are usually much much more comprehensive and cogent. Both Learn You a Haskell and Real World Haskell are excellent in that respect. 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.
  - evincarofautumn 15y ago
    I found Learn You a Haskell unexciting; it was more useful for me to hang out with my Haskell-programming acquaintances, read a lot of code, and get my hands dirty using it than it was to just read and play with examples. 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.
sliverstorm 15y ago
Has the author ever tried to teach anyone pointers? Who had never heard of them before? I've introduced several people to pointers, and while they aren't "hard" in the sense that it takes them months of hard labor to understand, there's a reason they have the reputation they do. I personally love pointers, and have a bad habit of trying to do my own memory management with them.
- evincarofautumn 15y ago
  Yes, I tutored CS in C++ for a few years, and near-tautological explanations like these seemed to work best to cut through the explanations of the professors. I like to think I've helped create a good programmer or two. In general the profs were trying to be strictly correct, at the cost of explaining things in terms that their students would actually understand.
- matwood 15y ago
  IMHO, the only problem with teach pointers is that professors try to dress them up. Not understanding a pointer typically means not understanding the basics of the underlying hardware. This touches on one of the common problems today is that software has been split away from the hardware that runs it. 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.
deleted 15y ago
[deleted]
rflrob 15y ago
This seems to be creating a false dichotomy in the original argument. It's not that there are some people who can't understand concepts like pointers and recursion, but having taught programming to several crops of complete neophytes, I've discovered there are some concepts that some people get right away, and others don't[1]. My response to this isn't to write off the people who don't get it, it's to work harder with them, but that doesn't change the fact that given two people with the same explicit programming background[2], and exposed to the same lectures, a fraction of them will need further work. It's this kind of concept that I call tricky. [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.
- rhizome 15y ago
  Valorizing the optimal case is not a safe strategy.
- MaxGabriel 15y ago
  He's not creating a false dichotomy to attack--he's responding to Joel Spoelsky's post, and Spoelsky creates a very clear dichotomy of smart and not-smart in his post "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."
- astrofinch 15y ago
  I've done a fair amount of one-on-one programming tutoring both for friends and family and for pay. In my mind there's no question that the variation in the speed with which people pick up programming concepts is quite significant.
chrismealy 15y ago
OK, instead of saying "this is tricky" people should say, "this will take some practice." I got pointers right away but it took a lot of practice to use them without error.
- evincarofautumn 15y ago
  I like that. It's not "you can't", it's "you will have to work".
- lutorm 15y ago
  The author completely missed the point about why teachers say "this is tricky". It's not about telling students to pay attention, they do that if they want. And it's certainly not about telling people it's so hard they need not bother. It is to make it OK for students to not understand right away and not feel bad about asking questions.
  - evincarofautumn 15y ago
    I was trying to be brief, but that is essentially what I meant to say...perhaps I'll edit to clarify that. I think the effect is still the same, though, regardless of the motivation behind the phrase.
waqf 15y ago
Since even the most high-level concept, explained correctly, can be absorbed and applied by any person of average intelligence, I will be very interested when the author (or, y'know, anyone) posts such an explanation of motivic cohomology.
aidenn0 15y ago
Experience has shown me that there are people who just won't get these concepts. I don't know if they decided it was hard and gave up or what. 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.
- eeperson 15y ago
  I don't think the difficulty stems from an inherent inability to learn a concept. I think the difficulty occurs largely because of two factors: lack of interest and intimidation. 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
kenjackson 15y ago
A pointer points. A reference refers. These are the same thing. 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).
- evincarofautumn 15y ago
  A pointer is a particular kind of reference (a value type that enables indirection), and C++ references are another (not very different) kind. A reference in C++ amounts to an immutable pointer. 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.)
  - esrauch 15y ago
    > A reference in C++ amounts to an immutable pointer. "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;
    - evincarofautumn 15y ago
      "Nullability" would be that caveat. But that's an argument about C++, not an argument about references.
    - TeMPOraL 15y ago
      > Eg: A pointer amounts to an int. Is there a reason why this analogy is invalid? I found it to be quite useful in using, understanding and explaining C pointers.
msluyter 15y ago
I'd like some actual empirical evidence that saying "this is tricky" or "this is difficult" actually de-motivates ("turns off") students. It might, but I can also plausibly imagine the reverse. What if you say "oh, this will be easy and fun!" and then they have trouble with it? IMHO, that might send the message that they're just dumb. At least when you say "it's tricky" and they struggle they may not think it's their fault and might be willing to keep trying. I think you could spin a lot of plausible pedagogical theories, but I'd be more interested in seeing some actual evidence.
- mechanical_fish 15y ago
  I'm sure it depends crucially on the student. 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.
- sp332 15y ago
  If you tell someone that a simple concept is difficult, they will have trouble understanding it. I have seen this firsthand many, many times.
- evincarofautumn 15y ago
  I'm just citing personal experience. I would be very interested to see studies that clearly backed up or refuted my perceptions. The real machinery at work is probably more interesting than I imagine, and definitely more interesting than I make it out to be in the article.
- xyzzyz 15y ago
  It's just like the whole "engineering is not for women", which successfully discourages girls from entering technical fields.
georgieporgie 15y ago
A queue is a queue of things. 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)
radagaisus 15y ago
Let me get this off my chest: pointers are NOT hard. If every 16 year old with weed can talk about representation and meaning, every CompSci student can grok pointers. 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.
- mechanical_fish 15y ago
  Thanks for the excellent introduction to my next topic: An important function of programming education is to teach people which things other people often find difficult. Because intuition is not a reliable guide. And the secret to all effective communication -- which certainly includes programming, as well as writing and teaching -- is to write stuff that your audience can understand. 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.
  - regularfry 15y ago
    > Thanks for the excellent introduction to my next topic: An important function of programming education is to teach people which things other people often find difficult. 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.
- Natsu 15y ago
  > I didn't learn regular expressions for a very long time because people said they were hard. 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.
msutherl 15y ago
lol, I love the guy who commented: "Awesome post. Now do monads please?"
- stonemetal 15y ago
  Monads are a lot like pointers in that the Dictionary definition is rather simple. It is the implications and proper use that takes dedication and practice.
scott_s 15y ago
I'm sure I have said similar things before when teaching students. I have no problem with these concepts because I've dealt with them for years. 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.
- mattdeboard 15y ago
  Thank you. I think this is a responsible, reasonable approach. "This is going to be tough" is a reliable signal from instructor to instructed that we need to pay close attention, because this next part won't be easy.
hackinthebochs 15y ago
People try so hard to find excuses why some people can't understand some concepts, such as pointers. It's all an attempt to avoid just admitting that some people aren't capable. 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.
gtrak 15y ago
Actually they are.
mattdeboard 15y ago
Completely disagree with you. There is nothing more demotivating and infuriating than a professor breezing through challenging material with no acknowledgement that it is 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.
- evincarofautumn 15y ago
  You're disagreeing with something I didn't say. A professor should not "breeze through" anything. I just said they shouldn't set up students with preconceptions of difficulty.
aangjie 15y ago
Phew.. I haven't tried to teach programming to anyone yet, but i think it would be a good idea to ask the student to point to some object. Then point to a different object. Then explaining to them that they are asking the computer to do the same thing as moving their hand and index finger. *- Ofcourse, it may not be practical in a big class, and it might help to put the objects in a sequence. Any feed back on having tried this??

It's good to see someone bluntly take apart common misconceptions.

evincarofautumn 15y ago
My pleasure. It's good you find it blunt: I tried to be concise so people would bother reading.
- nasmorn 15y ago
  tl;dr Programming is not as hard as people make it out to be.
  - evincarofautumn 15y ago
    No. Pointers and recursion are easy. Programming is hard, like writing and design, because it is both.
    - danso 15y ago
      Why can good programmers claim to be both good at writing and design whereas writers, under that taxonomy, are only good at writing? Isn't good writing inherently a type of good design, in terms of presenting an "interface" to the reader and adroitly arranging the elements?
      - evincarofautumn 15y ago
        I meant only to equate the core skill set of the three. Programmers aren't necessarily good writers of literature or designers of graphics, but neither are writers necessarily good writers of software, nor artists good designers of it.
xlm 15y ago
Agreed, that was refreshing (and affirming). 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"
- danso 15y ago
  Doesn't this underscore the argument against the OP? If Feymnan is correct, this means that many CS teachers don't really understand these concepts that they tell their students to be "tricky." 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.
  - rcfox 15y ago
    Or perhaps these people just repeat "this is tricky" because that's what they were told. These people probably also say that Java is slow and Perl is a write-only language. It's easier than having a real opinion.
  - evincarofautumn 15y ago
    Feynman is wrong. Understanding something (technical skill) doesn't automatically make you good at explaining it (communication skill). Being poor at explaining something does not necessarily betray incomplete understanding.
    - mechnik 15y ago
      Feynman is not wrong. Technical skill does not equal understanding something. Consider an idiot savant who is technically proficient at playing piano but can't string two words together. These definitions of 'understand' may help: 1. Perceive the intended meaning of (words, a language, or speaker): "he could usually make himself understood"; "she understood what he was saying". 2. Perceive the significance, explanation, or cause of (something): "she didn't really understand the situation". http://www.google.com/search?aq=f&q=define%3Aunderstand http://www.google.com/search?aq=f&q=define%3Aunderstand

I'm on board with his basic pedagogical point: don't tell people you expect them to struggle. 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."

evincarofautumn 15y ago
My point is that a memory reference is a conceptual reference. There is no difference. Understanding references is not about building abstraction atop your understanding of them; it's about recognising that you can express natural abstractions literally through them.
- BrianHV 15y ago
  I'm unclear on what it means to "understand references" in a way that doesn't involve the way they behave in code. Unless you're saying that the concept as it appears in code can be explained entirely with the tautological definition, in which case I would be inclined to disagree. 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.
  - evincarofautumn 15y ago
    I just think he comes too close to saying that it's entirely the onus of the student to understand the concepts, when the other half of the problem is that they're being taught (in my humble but loud opinion) incorrectly.

qntm 15y ago

Of course, there are plenty of actual tricky programming concepts: closures, tail recursion, coroutines, memory management, concurrency, regular expression matching, caching, algorithmic complexity, naming things...

evincarofautumn 15y ago
And you've just given me an idea for my next article. :)
gatlin 15y ago
Another commenter made a great point that knowing how and when to use these things is likely more difficult, but having a good grasp of the concepts is important. Here is a minute of me stabbing at analogies: 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.
- mark_story 15y ago
  Great explanations.
  - gatlin 15y ago
    Thanks! Maybe the author of the article will agree.
- 15y ago

matan_a 15y ago

Interesting article and it does go a good job of explaining these basic concepts. 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.

evincarofautumn 15y ago
True, but understanding goes a long way toward practical skill.
- matan_a 15y ago
  you are definitely right about that

RyanMcGreal 15y ago

> This is exactly like the process of essay writing Indeed. I find that essay writing and programming light up exactly the same parts of my brain.

adbge 15y ago

I'd love to see more programming abstractions described in simple, no nonsense terms. I think that, as programmers, we often get so used to our own jargon that we unconsciously create a non-trivial barrier to entry. 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.

theFco 15y ago
In my case I think it is after "a lot of sifting through academic language" that I get a cool idea through my thick skull. Academic language is (or should be) about being precise not obscure. What I am trying to say, is that learning takes time. The simple, no nonsense terms resonate in your mind after you really grasp the concept. Otherwise it's just a high level overview that won't allow you to really use the concept.
SkyMarshal 15y ago
If you learn something like haskell from books instead of blogs, the explanations are usually much much more comprehensive and cogent. Both Learn You a Haskell and Real World Haskell are excellent in that respect. 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.
- evincarofautumn 15y ago
  I found Learn You a Haskell unexciting; it was more useful for me to hang out with my Haskell-programming acquaintances, read a lot of code, and get my hands dirty using it than it was to just read and play with examples. 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.

sliverstorm 15y ago

Has the author ever tried to teach anyone pointers? Who had never heard of them before? I've introduced several people to pointers, and while they aren't "hard" in the sense that it takes them months of hard labor to understand, there's a reason they have the reputation they do. I personally love pointers, and have a bad habit of trying to do my own memory management with them.

evincarofautumn 15y ago
Yes, I tutored CS in C++ for a few years, and near-tautological explanations like these seemed to work best to cut through the explanations of the professors. I like to think I've helped create a good programmer or two. In general the profs were trying to be strictly correct, at the cost of explaining things in terms that their students would actually understand.
matwood 15y ago
IMHO, the only problem with teach pointers is that professors try to dress them up. Not understanding a pointer typically means not understanding the basics of the underlying hardware. This touches on one of the common problems today is that software has been split away from the hardware that runs it. 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.

deleted 15y ago

[deleted]

rflrob 15y ago

This seems to be creating a false dichotomy in the original argument. It's not that there are some people who can't understand concepts like pointers and recursion, but having taught programming to several crops of complete neophytes, I've discovered there are some concepts that some people get right away, and others don't[1]. My response to this isn't to write off the people who don't get it, it's to work harder with them, but that doesn't change the fact that given two people with the same explicit programming background[2], and exposed to the same lectures, a fraction of them will need further work. It's this kind of concept that I call tricky. [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.

rhizome 15y ago
Valorizing the optimal case is not a safe strategy.
MaxGabriel 15y ago
He's not creating a false dichotomy to attack--he's responding to Joel Spoelsky's post, and Spoelsky creates a very clear dichotomy of smart and not-smart in his post "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."
astrofinch 15y ago
I've done a fair amount of one-on-one programming tutoring both for friends and family and for pay. In my mind there's no question that the variation in the speed with which people pick up programming concepts is quite significant.

chrismealy 15y ago

OK, instead of saying "this is tricky" people should say, "this will take some practice." I got pointers right away but it took a lot of practice to use them without error.

evincarofautumn 15y ago
I like that. It's not "you can't", it's "you will have to work".
lutorm 15y ago
The author completely missed the point about why teachers say "this is tricky". It's not about telling students to pay attention, they do that if they want. And it's certainly not about telling people it's so hard they need not bother. It is to make it OK for students to not understand right away and not feel bad about asking questions.
- evincarofautumn 15y ago
  I was trying to be brief, but that is essentially what I meant to say...perhaps I'll edit to clarify that. I think the effect is still the same, though, regardless of the motivation behind the phrase.

waqf 15y ago

Since even the most high-level concept, explained correctly, can be absorbed and applied by any person of average intelligence, I will be very interested when the author (or, y'know, anyone) posts such an explanation of motivic cohomology.

aidenn0 15y ago

Experience has shown me that there are people who just won't get these concepts. I don't know if they decided it was hard and gave up or what. 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.

eeperson 15y ago
I don't think the difficulty stems from an inherent inability to learn a concept. I think the difficulty occurs largely because of two factors: lack of interest and intimidation. 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

kenjackson 15y ago

A pointer points. A reference refers. These are the same thing. 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).

evincarofautumn 15y ago
A pointer is a particular kind of reference (a value type that enables indirection), and C++ references are another (not very different) kind. A reference in C++ amounts to an immutable pointer. 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.)
- esrauch 15y ago
  > A reference in C++ amounts to an immutable pointer. "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;
  - evincarofautumn 15y ago
    "Nullability" would be that caveat. But that's an argument about C++, not an argument about references.
  - TeMPOraL 15y ago
    > Eg: A pointer amounts to an int. Is there a reason why this analogy is invalid? I found it to be quite useful in using, understanding and explaining C pointers.

msluyter 15y ago

I'd like some actual empirical evidence that saying "this is tricky" or "this is difficult" actually de-motivates ("turns off") students. It might, but I can also plausibly imagine the reverse. What if you say "oh, this will be easy and fun!" and then they have trouble with it? IMHO, that might send the message that they're just dumb. At least when you say "it's tricky" and they struggle they may not think it's their fault and might be willing to keep trying. I think you could spin a lot of plausible pedagogical theories, but I'd be more interested in seeing some actual evidence.

mechanical_fish 15y ago
I'm sure it depends crucially on the student. 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.
sp332 15y ago
If you tell someone that a simple concept is difficult, they will have trouble understanding it. I have seen this firsthand many, many times.
evincarofautumn 15y ago
I'm just citing personal experience. I would be very interested to see studies that clearly backed up or refuted my perceptions. The real machinery at work is probably more interesting than I imagine, and definitely more interesting than I make it out to be in the article.
xyzzyz 15y ago
It's just like the whole "engineering is not for women", which successfully discourages girls from entering technical fields.

georgieporgie 15y ago

A queue is a queue of things. 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)

radagaisus 15y ago

Let me get this off my chest: pointers are NOT hard. If every 16 year old with weed can talk about representation and meaning, every CompSci student can grok pointers. 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.

mechanical_fish 15y ago
Thanks for the excellent introduction to my next topic: An important function of programming education is to teach people which things other people often find difficult. Because intuition is not a reliable guide. And the secret to all effective communication -- which certainly includes programming, as well as writing and teaching -- is to write stuff that your audience can understand. 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.
- regularfry 15y ago
  > Thanks for the excellent introduction to my next topic: An important function of programming education is to teach people which things other people often find difficult. 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.
Natsu 15y ago
> I didn't learn regular expressions for a very long time because people said they were hard. 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.

msutherl 15y ago

lol, I love the guy who commented: "Awesome post. Now do monads please?"

stonemetal 15y ago
Monads are a lot like pointers in that the Dictionary definition is rather simple. It is the implications and proper use that takes dedication and practice.

scott_s 15y ago

I'm sure I have said similar things before when teaching students. I have no problem with these concepts because I've dealt with them for years. 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.

mattdeboard 15y ago
Thank you. I think this is a responsible, reasonable approach. "This is going to be tough" is a reliable signal from instructor to instructed that we need to pay close attention, because this next part won't be easy.

hackinthebochs 15y ago

People try so hard to find excuses why some people can't understand some concepts, such as pointers. It's all an attempt to avoid just admitting that some people aren't capable. 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.

gtrak 15y ago

Actually they are.

mattdeboard 15y ago

Completely disagree with you. There is nothing more demotivating and infuriating than a professor breezing through challenging material with no acknowledgement that it is 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.

evincarofautumn 15y ago
You're disagreeing with something I didn't say. A professor should not "breeze through" anything. I just said they shouldn't set up students with preconceptions of difficulty.

aangjie 15y ago

Phew.. I haven't tried to teach programming to anyone yet, but i think it would be a good idea to ask the student to point to some object. Then point to a different object. Then explaining to them that they are asking the computer to do the same thing as moving their hand and index finger. *- Ofcourse, it may not be practical in a big class, and it might help to put the objects in a sequence. Any feed back on having tried this??