Is learning to program inherently hard?(computinged.wordpress.com)
computinged.wordpress.com
Is learning to program inherently hard?
http://computinged.wordpress.com/2010/04/14/is-learning-to-program-inherently-hard/
19 comments
Is learning to ride a unicycle hard?
I think the difference here is that riding a unicycle is a fundamentally bounded problem: you balance, you move your feet, you do a couple of other things. By contrast, programming is effectively unlimited in its potential problem domain.
Philosophy? Music?
These are both hard to do really well, but they have a much greater margin for error and often aren't provably correct or incorrect. When I write an academic paper, if I have a typo on the fourth page, the entire rest of the paper won't catastrophically fail. When I write a program, however. . .
Hard is relative.
Very true! But some fields still, at least to my mind, feel harder than others. One (limited) way you could look at "hard" is in the context of universities: I've seen dropout graphs for various majors. It's not at all unusual for someone to go from electrical engineering to com, or CS to English, but I've yet to hear any English majors say, "English was too hard for me, so I switched to Chemical Engineering."
I think the difference here is that riding a unicycle is a fundamentally bounded problem: you balance, you move your feet, you do a couple of other things. By contrast, programming is effectively unlimited in its potential problem domain.
Philosophy? Music?
These are both hard to do really well, but they have a much greater margin for error and often aren't provably correct or incorrect. When I write an academic paper, if I have a typo on the fourth page, the entire rest of the paper won't catastrophically fail. When I write a program, however. . .
Hard is relative.
Very true! But some fields still, at least to my mind, feel harder than others. One (limited) way you could look at "hard" is in the context of universities: I've seen dropout graphs for various majors. It's not at all unusual for someone to go from electrical engineering to com, or CS to English, but I've yet to hear any English majors say, "English was too hard for me, so I switched to Chemical Engineering."
When I write a program, however. . .
It might not catastrophically fail, but it might mean anything from not compiling through to not outputting a newline or create a possible security issue via a buffer overflow.
Like the majority of things in life, it comes down to shades of grey, and that's why it's tricky at times ;)
It might not catastrophically fail, but it might mean anything from not compiling through to not outputting a newline or create a possible security issue via a buffer overflow.
Like the majority of things in life, it comes down to shades of grey, and that's why it's tricky at times ;)
On the note of linguistics - I started a linguistics course at the same semester as a compilers course, and I found them to be a perfect complement to each other; it was all patterns and parse trees. My non-CS classmates in the linguistics class had a much harder time grasping the concepts, and the professor had to come up with some crazy curve to account for the difference between our levels.
So, depending on how you approach computer science, you may find that those same skills have prepared you for linguistics, or vice versa. Either way, I highly recommend learning linguistics; it is a fascinating discipline.
So, depending on how you approach computer science, you may find that those same skills have prepared you for linguistics, or vice versa. Either way, I highly recommend learning linguistics; it is a fascinating discipline.
Forgive the pedantry, but riding a unicycle is not difficult even if you have bad motor coordination.
I'm fairly janky in terms of my motor skills and learned to unicycle in a week or two. It consists of hacks, concepts, and fundamentals just like most seemingly complex tasks.
I'm fairly janky in terms of my motor skills and learned to unicycle in a week or two. It consists of hacks, concepts, and fundamentals just like most seemingly complex tasks.
But what if you don't have legs?
Then you have an advantage!
http://blog.ted.com/2009/03/11/aimee_mullins_12/
http://blog.ted.com/2009/03/11/aimee_mullins_12/
'hard' is best defined as 'requiring a skill a smaller percentage of the population possess
I disagree about the 'skill' bit. Skill can be acquired. There are many skills that few possess that many could acquire, if they wanted to. For examples, consult the Guinness book of world records.
I disagree about the 'skill' bit. Skill can be acquired. There are many skills that few possess that many could acquire, if they wanted to. For examples, consult the Guinness book of world records.
Programming is hard, period. Knuth has noted that its so difficult for him that when he is programming he can't teach courses, and he's among the best programmers in history.
Jon Skeet wrote a blog on the topic: http://msmvps.com/blogs/jon_skeet/archive/2009/01/29/program...
Jon Skeet is right. Programming is hard, except the most trivial tasks. And anything that is not trivial is probably broken. But we're OK with things being a little broken, and we've made users bend to our will sufficiently now that we have pushed much of the cognitive load to the users.
Jon Skeet wrote a blog on the topic: http://msmvps.com/blogs/jon_skeet/archive/2009/01/29/program...
Jon Skeet is right. Programming is hard, except the most trivial tasks. And anything that is not trivial is probably broken. But we're OK with things being a little broken, and we've made users bend to our will sufficiently now that we have pushed much of the cognitive load to the users.
"Programming is hard, period. Knuth has noted that its so difficult for him that when he is programming he can't teach courses, and he's among the best programmers in history."
This reminds me of something I've read about writing:
"A writer is someone for whom writing is more difficult than it is for other people." -- Thomas Mann
I wonder if this also applies to programming.
That is, perhaps the reason programming for Knuth is so hard is that he has such high standards and that he's working on such difficult problems.
This reminds me of something I've read about writing:
"A writer is someone for whom writing is more difficult than it is for other people." -- Thomas Mann
I wonder if this also applies to programming.
That is, perhaps the reason programming for Knuth is so hard is that he has such high standards and that he's working on such difficult problems.
I will go ahead and claim, that even seemingly trivial programming tasks are astonishingly difficult.
http://www.cs.princeton.edu/introcs/42sort/
According to Knuth, the first binary search algorithm was published in 1946, but the first published binary search without bugs did not appear until 1962.
http://googleresearch.blogspot.com/2006/06/extra-extra-read-...
http://www.cs.princeton.edu/introcs/papers/bentley-binarysea...
http://www.cs.princeton.edu/introcs/42sort/
According to Knuth, the first binary search algorithm was published in 1946, but the first published binary search without bugs did not appear until 1962.
http://googleresearch.blogspot.com/2006/06/extra-extra-read-...
http://www.cs.princeton.edu/introcs/papers/bentley-binarysea...
Programming is hard for Knuth because his standard is that his programs should be correct. That would mean that they would contain no bugs. There are very, very few pieces of production software that might plausibly contain no bugs. TeX/METAFONT is one; qmail is another. I don't know of any others.
Programming is sometimes hard and sometimes easy. One of the things that makes it very hard is having a standard that demands the complete absence of bugs.
Fortunately, sometimes buggy programs are useful anyway.
Programming is sometimes hard and sometimes easy. One of the things that makes it very hard is having a standard that demands the complete absence of bugs.
Fortunately, sometimes buggy programs are useful anyway.
One interesting possibility to just play with...
Perhaps programming is so hard ... that teaching it is easy.
If programming is so hard that an older programmer has little teacher younger programmers, then everyone is equal when trying to the mountain.
Charging a machine-gun nest with only bayonet is incredibly hard. Learning all you can learn in attempting this is fairly easy...
Probably not true but worth tossing around in your mind.
Perhaps programming is so hard ... that teaching it is easy.
If programming is so hard that an older programmer has little teacher younger programmers, then everyone is equal when trying to the mountain.
Charging a machine-gun nest with only bayonet is incredibly hard. Learning all you can learn in attempting this is fairly easy...
Probably not true but worth tossing around in your mind.
I would note that the author jumps between "teaching programming is hard", "programming is hard" and "learning programming is hard". None of these are equivalent statements about a field in general (even if they're all true here).
Still, it seems like in fact saying things about "programming" might also being inherently hard!
I mean, we can say that the halting problem is inherently but the halting problem doesn't reflect the day-to-day practices of the working programmer. Yet how do we characterize what does? The boundary between programming and using computers is fuzzy and given Church-Turing, just about defined activity can be encompassed in using a computer (a lot of machinists have become "programmers" of numerically controlled machines but this use is more similar to artists using Photoshop than software engineers using c++). One might argue that the advance of computer technology will create more and more professions which involve the high-level use of computers but won't be "programming as such" (spread-sheet use, UI design, etc).
By that token, if "real programming" is what's left when you've codified the other occupations, one could argue that it is inherently hard. But we're still a bit at the level of tautology.
Still, it seems like in fact saying things about "programming" might also being inherently hard!
I mean, we can say that the halting problem is inherently but the halting problem doesn't reflect the day-to-day practices of the working programmer. Yet how do we characterize what does? The boundary between programming and using computers is fuzzy and given Church-Turing, just about defined activity can be encompassed in using a computer (a lot of machinists have become "programmers" of numerically controlled machines but this use is more similar to artists using Photoshop than software engineers using c++). One might argue that the advance of computer technology will create more and more professions which involve the high-level use of computers but won't be "programming as such" (spread-sheet use, UI design, etc).
By that token, if "real programming" is what's left when you've codified the other occupations, one could argue that it is inherently hard. But we're still a bit at the level of tautology.
As a 'business' guy, I taught myself to program so that I could communicate effectively with my team. It was damned hard - partly because I was doing it on an evening and (if I'm honest) I wasn't that interested in it... at first. The more I learned though, the more that I understood that its about solving problems and as soon as my brain understood that it was a challenge it became more fun. I will admit that I am still not a very good programmer. I'm slow, but I treat it as a hobby now and whilst its probably amusing for the people on my team I enjoy the feeling I get when I create something.
To any of the non-programmers on who read HN a lot, I'd recommend doing what I did
To any of the non-programmers on who read HN a lot, I'd recommend doing what I did
I've thought about this for a while. Where did you start, and what languages are best for this kind of toe-dipping? Also, what kind of time investment did you have to put in?
Well, I've been in business a while, so the first language I learned was called Cold Fusion (I think now owned by Adobe). I then tried learning PHP, but there was some kind of mental barrier there unfortunately for me, though I think I'd be OK with it these days. I then moved to Python which I've found to be a great language. There are a lot of free online books out there. In terms of investment in time, I just started off doing an hour a day. As I did not have anything specific to do, with any timeframe, this worked well for me and did not impact on the day-to-day activities. I will say though that you need to set yourself a challenge fairly quickly as this is the only real way to solidify the theory in your mind. The first one for me was a small crawler to screen scrape some data from a site, put it into a database and search it. One of my team could have done it much quicker of course, but the sense of achievement when it (finally!) worked was great. Hope this helps
learning to program is deceptively hard.
First you think it hard,
then you think its not,
then you think its hard,
then you think its not,
...I think what makes programming particularly hard is that there is such a large space of possibilities. There's pretty good research out there that people flounder when there are too many choices. When I was first starting out I remember being paralyzed by that; I could think of several ways to write this one algorithm, and how did I choose? What helped was learning about efficiency in programming, simply because learning "best" practices was a way to limit the space of possibilities.
There are, of course, parallel examples of open problems- writing a novel is much the same way, I think. And I think most would agree that writing a novel is also hard. And doing original research also falls under this umbrella.
There are, of course, parallel examples of open problems- writing a novel is much the same way, I think. And I think most would agree that writing a novel is also hard. And doing original research also falls under this umbrella.
Hard? It's easy to write one line of code that works. Anyone can do that. It's easy to write two lines of codes that works. Anyone can do that. Now you just continue. See, not too hard!
No, of course the complexity grows for each new instruction - and that's why it's hard. Software engineering is about managing this complexity. Programming is the easy part.
No, of course the complexity grows for each new instruction - and that's why it's hard. Software engineering is about managing this complexity. Programming is the easy part.
Programming is probably as challenging as any other intellectually demanding task, but it does have one advantage to other skills: it can be done fairly cheaply. It doesn't require any sort of capital investment other than a cheap netbook (or someone could probably even learn on machines in the library), there are tons of high quality tools and tutorials out there that are completely free, and there is a large community of people that are very accessible and actually like helping other people.
I think he got it spot on with the mental model stuff. People fail at programming because they've learned to always use plug-and-play formulas instead of properly understanding what's going on. This approach fails absolutely with programming. There are no shortcuts.
I don't fully understand what's going on. However, as long as someone design the black box carefully, I can figure out what it can't and can do.
Thanks to the law of leaky abstractions, that will always bite you in the end (provided your are doing something complicated enough).
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
You still have to have a mental model of how the box works. A for loop is effectively a black box too.
It's not about knowing all the details of how it works, it's about making a mental model.
It's not about knowing all the details of how it works, it's about making a mental model.
I found programming WAY easier than learning the guitar. 'Course I was 13 at the time, and the latter involved "practice". Practice was boring, yet learning things like ASCII, how to toggle a PDP-8, Hammurabi, ... Those weren't "practice".
As everybody knows, doing what you like to do is easy. Doing other stuff is not.
As everybody knows, doing what you like to do is easy. Doing other stuff is not.
> Practice was boring, yet learning things like ASCII, how to toggle a PDP-8, Hammurabi, ... Those weren't "practice".
I get better at programming as I do it more. I think you're correct that individual knowledge points aren't "practice" per se, but practice definitely factors into skill over time. Just like I imagine it does with the guitar.
I get better at programming as I do it more. I think you're correct that individual knowledge points aren't "practice" per se, but practice definitely factors into skill over time. Just like I imagine it does with the guitar.
I think the essential difference is that practicing the guitar involves doing the same thing over and over until you get it right/fast, whereas practicing programming involves doing different things.
I would think to a guitarist, what we do when programming is "all the same". Just like we think guitar practice is all the same. No, the guitarist would say, there's real differences between flamenco, jazz, prog rock, ...
If you support the 10K hours argument, some things are willingly done and others less so. I make coin with programming, yet people pay to see guitarists.
If you support the 10K hours argument, some things are willingly done and others less so. I make coin with programming, yet people pay to see guitarists.
Guitarists definitely do engage in some 'mindless' practice where they're essentially just building dexterity/muscle-memory by playing the same thing over and over. I don't think there's anything like that in programming... unless you count trying to get used to emacs key bindings.
But obviously some guitar practice is more involved. It's something I think about a lot actually, as when I need a break from programming first thing I do is pick up my guitar. My musical goal is to be able to improvise on the guitar using jazz theory. To do that you need to internalize abstractions like scales/modes and chord progressions. You need to be able to transpose the same abstraction/pattern to different notes (on the most basic level this would just mean sliding further up the neck and using the same shape for fingering), and you need to be able to 'search' your options (some chords can substitute for other chords, which might then allow a whole new path of music) on the fly.
In programming you don't need to wrangle all these abstractions in a strictly timed performance, and there's no physical component to the challenge. But still, I often think about the similarities. I guess playing jazz guitar, while complex, can still be kept within a manageable scope of permutations and ultimately 'mastered'. But with programming you can't tame the complexity, you just get good at dodging it.
But obviously some guitar practice is more involved. It's something I think about a lot actually, as when I need a break from programming first thing I do is pick up my guitar. My musical goal is to be able to improvise on the guitar using jazz theory. To do that you need to internalize abstractions like scales/modes and chord progressions. You need to be able to transpose the same abstraction/pattern to different notes (on the most basic level this would just mean sliding further up the neck and using the same shape for fingering), and you need to be able to 'search' your options (some chords can substitute for other chords, which might then allow a whole new path of music) on the fly.
In programming you don't need to wrangle all these abstractions in a strictly timed performance, and there's no physical component to the challenge. But still, I often think about the similarities. I guess playing jazz guitar, while complex, can still be kept within a manageable scope of permutations and ultimately 'mastered'. But with programming you can't tame the complexity, you just get good at dodging it.
It is all 1's and 0's.
Learned to program when I was around five or six years old, by picking up a book of prewritten programs in BASIC for a Sinclair ZX80 (or ZX81? not sure), figuring out how they worked and writing my own.
I am not sure what the term "inherently hard" is supposed to mean in this context.
I am not sure what the term "inherently hard" is supposed to mean in this context.
Come on. I think the context is pretty clear. If a group of novelists are discussing how writing is inherently hard, would you let them know you don't understand how they can say writing is hard? After all, you learned how to write when you were five or six by picking up "See Spot Run" and then stringing together some nouns and verbs of your own...
If something is "inherently hard", not just "hard", it seems that it should be hard for everyone, which is clearly not the case with programming for some geniuses out there. There are people who don't blink an eye at mastering any data structure or algorithm, don't sweat when it comes to actually coding, and they're human just like you. Plus what if programming became really simple for some AI to do? You ask it "Make me a triple-A style video game I might enjoy" and it does so after a short while. I believe Eliezer is pointing out that programming being inherently hard is a mind-projection fallacy.
I assume as a 5 or 6 year old, you did not have as many responsibilities or obligations as an older person. Perhaps if you had not learned until later in life, the learning curve would be steeper?
Programming is like most things in life: hard if you have no affinity for it, much easier (but not necessarily easy) if you do.
I see programming to have a lot of parallels with being a combination mechanic and automotive engineer.
A mechanic fixes cars, diagnoses problems, tunes a car and so on. It's really a lot like (code) reading, testing, debugging and maintenance--all key programming skills.
An automotive engineer will actually a design a car, design and various components, model how it should work and so on. This is really program design and programming specifically.
The thing about programming is that involve perhaps the most tractable medium humans have ever used. It takes a long time to design and build a car. It still takes a long time to make significant changes to that car. Now compare that to software, which is easily changeable with a feedback loop that can be measured in as little as a few seconds (edit code, save, reload page in browser).
Of course some software has a longer feedback loop but at worst it tends to be in hours, possibly days. It's a different order of magnitude.
Cars can be adjusted within fairly tight limits (meaning you can make the engine more efficient or make the brakes work better or not at all but you can't easily make that car float or fly).
Is programming harder than being a mechanic and/or automotive engineer? Empirically I can't answer that question. I would be useless as a mechanic. Could I learn? Possibly. Would I be as good as those with a natural affinity? Absolutely not.
One thing I'll add is that the barrier to entry for programming is probably higher but this might simply be an issue of complexity.
Consider a car from 40-50 years ago. It wasn't that complicated. Now? Cars have dozens of computing units in them and qualified mechanics have to use computer systems to interface with them. So perhaps modern software is more like a modern car than a car from the 70s.
Now consider another discipline like medicine. Is medicine hard? It certainly requires a lot of knowledge. Part of many medical disciplines it appears involve a significant amount of rote learning. Bone names, nerves, diseases and so on.
Some have an affinity for rote learning and some don't. I know I don't.
The other part of medicine is the mental attitude required. Not everyone is psychologically capable of dealing with a patient who is dying or has the mental endurance to perform a 12 hour heart transplant. It's very exact.
But is it harder?
My own theory is that some people can become programmers and others can't. Some of the ones who can't sadly are employed as programmers.
Programming requires an extremely high level of abstract thought. I remember demonstrating to my sister how I used Splashtop on my iPad to connect to my PC at home to start it doing something. To her, it was for all intents and purposes magic (to paraphrase one of Arthur C. Clarke's laws).
To me--and anyone reading this--there's nothing magical about it. It's simply a system of concepts built on top of other concepts.
This also changes my thinking. I see (human) language much like a network protocol. Letters are merely agreed-upon symbols that, when combined, form sounds (most) humans are capable of making. Combine those sounds (or groups of letters) into words and you have a another layer of agreed-upon concepts (or definitions).
Network protocols work much the same way. Ultimately there is a physical layer where certain voltage differences equate to 1s and 0s. Once you have the concepts of transmitting bits, you arrange them into bytes. Certain bytes or byte sequences resolve to characters. Combine those characters and you have a message.
It's systems built on systems. Do non-programmers see language that way? Unless they're linguists, probably not.
So I guess my point is that programming (or anything for that matter) may simply look hard because the foundation in concepts simply isn't there. Whether or not someone can learn those concepts and whether or not that makes programming qualitatively hard is another matter.
I see programming to have a lot of parallels with being a combination mechanic and automotive engineer.
A mechanic fixes cars, diagnoses problems, tunes a car and so on. It's really a lot like (code) reading, testing, debugging and maintenance--all key programming skills.
An automotive engineer will actually a design a car, design and various components, model how it should work and so on. This is really program design and programming specifically.
The thing about programming is that involve perhaps the most tractable medium humans have ever used. It takes a long time to design and build a car. It still takes a long time to make significant changes to that car. Now compare that to software, which is easily changeable with a feedback loop that can be measured in as little as a few seconds (edit code, save, reload page in browser).
Of course some software has a longer feedback loop but at worst it tends to be in hours, possibly days. It's a different order of magnitude.
Cars can be adjusted within fairly tight limits (meaning you can make the engine more efficient or make the brakes work better or not at all but you can't easily make that car float or fly).
Is programming harder than being a mechanic and/or automotive engineer? Empirically I can't answer that question. I would be useless as a mechanic. Could I learn? Possibly. Would I be as good as those with a natural affinity? Absolutely not.
One thing I'll add is that the barrier to entry for programming is probably higher but this might simply be an issue of complexity.
Consider a car from 40-50 years ago. It wasn't that complicated. Now? Cars have dozens of computing units in them and qualified mechanics have to use computer systems to interface with them. So perhaps modern software is more like a modern car than a car from the 70s.
Now consider another discipline like medicine. Is medicine hard? It certainly requires a lot of knowledge. Part of many medical disciplines it appears involve a significant amount of rote learning. Bone names, nerves, diseases and so on.
Some have an affinity for rote learning and some don't. I know I don't.
The other part of medicine is the mental attitude required. Not everyone is psychologically capable of dealing with a patient who is dying or has the mental endurance to perform a 12 hour heart transplant. It's very exact.
But is it harder?
My own theory is that some people can become programmers and others can't. Some of the ones who can't sadly are employed as programmers.
Programming requires an extremely high level of abstract thought. I remember demonstrating to my sister how I used Splashtop on my iPad to connect to my PC at home to start it doing something. To her, it was for all intents and purposes magic (to paraphrase one of Arthur C. Clarke's laws).
To me--and anyone reading this--there's nothing magical about it. It's simply a system of concepts built on top of other concepts.
This also changes my thinking. I see (human) language much like a network protocol. Letters are merely agreed-upon symbols that, when combined, form sounds (most) humans are capable of making. Combine those sounds (or groups of letters) into words and you have a another layer of agreed-upon concepts (or definitions).
Network protocols work much the same way. Ultimately there is a physical layer where certain voltage differences equate to 1s and 0s. Once you have the concepts of transmitting bits, you arrange them into bytes. Certain bytes or byte sequences resolve to characters. Combine those characters and you have a message.
It's systems built on systems. Do non-programmers see language that way? Unless they're linguists, probably not.
So I guess my point is that programming (or anything for that matter) may simply look hard because the foundation in concepts simply isn't there. Whether or not someone can learn those concepts and whether or not that makes programming qualitatively hard is another matter.
I would be useless as a mechanic.
90% of being a good mechanic, just as 90% of being a good programmer or a good doctor, is debugging. If you're a good debugger, you can damn well do anything.
90% of being a good mechanic, just as 90% of being a good programmer or a good doctor, is debugging. If you're a good debugger, you can damn well do anything.
As a mechanic, you also need good grip strength and not be afraid to bloody your knuckles.
That's the 10%.
Seems like debugging to me, well at least the bloody knuckles part...
I propose using the term debuggist for a human operating a debugger, as in typist and typewriter.
What is affinity?
I just learned programming just like how I learn the artistic craft: Through sheer practice.
(Now, ironically, I actually make more money doing my lesser skill in art than I do in programming)
I just learned programming just like how I learn the artistic craft: Through sheer practice.
(Now, ironically, I actually make more money doing my lesser skill in art than I do in programming)
I think practice and patience can overcome the affinity issue. I think what stops most of the population from programming is zero interest or a low tolerance to getting frustrated and quitting.
At the same time though I do think there is a class of people for which programming comes very naturally.
At the same time though I do think there is a class of people for which programming comes very naturally.
[deleted]
You need to have a real interest in the subject. Anyone that wants to learn programming can do so but you can't take a random person and force them to learn in and get good results.
You can still get rapid feedback with a computer simulation tool for automotive engineers (of which I have no specific knowledge, though!).
"... Is programming harder than being a mechanic and/or automotive engineer? Empirically I can't answer that question. ..."
My old CompSci lecturer answered the question this way. In most fields of engineering, mechanical, electrical, chemical you can design knowing you can build with certain tolerances in mind. In software engineering you have zero tolerance.
My old CompSci lecturer answered the question this way. In most fields of engineering, mechanical, electrical, chemical you can design knowing you can build with certain tolerances in mind. In software engineering you have zero tolerance.
I've said it before, and I'll say it again. In my experience, the problems that students have ultimately fall into one of two categories:
1. Learning to think algorithmically; 2. Abstraction.
What do I mean by these? By "thinking algorithmically," I really mean "taking a large problem and breaking it up into an ordered series of steps or sub-problems." This is surprisingly hard for a lot of people, in part because the correct "size" of steps or sub-problem can change from problem to problem and from language to language. This can absolutely be taught, though. Some students have an easier time of this than others, but eventually (in my experience) they all get there in the end, and develop an intuitive sense of how to do it... at which point 99% of people immediately "forget" what it was like to not be able to do it, and become incapable of recognizing and dealing with students who haven't gotten there yet. :-) Most programmers (myself included, at least until my dozenth or so student, at which point I figured out what was going on) fall into this category: thinking in this manner is so deeply imprinted into our cognitive processes that we typically have a very difficult time visualizing what it's like to not be there. We're sort of like fish and water, if you know what I mean.
The second problem is much more difficult to address. Abstraction is one of those things that, I'm convinced, some (most) people can "get" and others simply can't. For example, I've had students who seemed to understand arrays perfectly, including the idea of using an integer subscript to refer to the value at an array index such that if you showed them the following code:
<pre>
myList = ['monkeys', 'elephants', 'giraffes'] print myList[1]
</pre>
they'd easily tell you that it would print 'elephants' (yes, they can usually get their heads around zero-indexing without issues). If, however, you showed them this code:
<pre>
myList = ['monkeys', 'elephants', 'giraffes'] idx = 1 print myList[idx]
</pre>
a lot of them would be more than a little bit lost. Even worse would be if you showed them this code:
<pre>
for i in [0, 1, 2] print myList[i]
</pre>
They'd be really lost, then. Even if you walk through it line by line, with lots of extraneous print statements, there is a certain sub-type of (otherwise perfectly capable) student that just isn't gonna get it. I'm convinced that this problem--- lack of abstraction ability--- is also why so many students have problems with loops. Dealing with loop counter variables (and the things that you usually want to do with them--- array indexing, printing, doing math, etc.) is very hard if your brain isn't able to think in this abstract manner.
It's worse in Java than it is in Python, just 'cause there's so much more code involved (meaning that it's harder to pinpoint exactly where the confusion is coming from), but the problem totally persists even in sane teaching languages. I've talked to a lot of other CS educators who've noticed the same thing- no matter how you approach it, this level of abstraction is just beyond some students' reach. It gets worse once you try and teach them about object/class distinctions, and so on. It's not that they're stupid- my students are usually MDs working on their masters' degrees. It's just that some people's brains don't work that way. And it's not that they can't do other computer stuff- some of these students have gone on to become pretty good at SQL and even relational data modeling, which you'd think would use some of the same cognitive patterns, but apparently is different enough that it's doable.
I don't know if the problem would be better or worse teaching with a purely functional language; my gut says "worse," but I haven't tried it so I don't know, and the fact that many students with this problem go on to handle declarative languages pretty well gives me pause.
1. Learning to think algorithmically; 2. Abstraction.
What do I mean by these? By "thinking algorithmically," I really mean "taking a large problem and breaking it up into an ordered series of steps or sub-problems." This is surprisingly hard for a lot of people, in part because the correct "size" of steps or sub-problem can change from problem to problem and from language to language. This can absolutely be taught, though. Some students have an easier time of this than others, but eventually (in my experience) they all get there in the end, and develop an intuitive sense of how to do it... at which point 99% of people immediately "forget" what it was like to not be able to do it, and become incapable of recognizing and dealing with students who haven't gotten there yet. :-) Most programmers (myself included, at least until my dozenth or so student, at which point I figured out what was going on) fall into this category: thinking in this manner is so deeply imprinted into our cognitive processes that we typically have a very difficult time visualizing what it's like to not be there. We're sort of like fish and water, if you know what I mean.
The second problem is much more difficult to address. Abstraction is one of those things that, I'm convinced, some (most) people can "get" and others simply can't. For example, I've had students who seemed to understand arrays perfectly, including the idea of using an integer subscript to refer to the value at an array index such that if you showed them the following code:
<pre>
myList = ['monkeys', 'elephants', 'giraffes'] print myList[1]
</pre>
they'd easily tell you that it would print 'elephants' (yes, they can usually get their heads around zero-indexing without issues). If, however, you showed them this code:
<pre>
myList = ['monkeys', 'elephants', 'giraffes'] idx = 1 print myList[idx]
</pre>
a lot of them would be more than a little bit lost. Even worse would be if you showed them this code:
<pre>
for i in [0, 1, 2] print myList[i]
</pre>
They'd be really lost, then. Even if you walk through it line by line, with lots of extraneous print statements, there is a certain sub-type of (otherwise perfectly capable) student that just isn't gonna get it. I'm convinced that this problem--- lack of abstraction ability--- is also why so many students have problems with loops. Dealing with loop counter variables (and the things that you usually want to do with them--- array indexing, printing, doing math, etc.) is very hard if your brain isn't able to think in this abstract manner.
It's worse in Java than it is in Python, just 'cause there's so much more code involved (meaning that it's harder to pinpoint exactly where the confusion is coming from), but the problem totally persists even in sane teaching languages. I've talked to a lot of other CS educators who've noticed the same thing- no matter how you approach it, this level of abstraction is just beyond some students' reach. It gets worse once you try and teach them about object/class distinctions, and so on. It's not that they're stupid- my students are usually MDs working on their masters' degrees. It's just that some people's brains don't work that way. And it's not that they can't do other computer stuff- some of these students have gone on to become pretty good at SQL and even relational data modeling, which you'd think would use some of the same cognitive patterns, but apparently is different enough that it's doable.
I don't know if the problem would be better or worse teaching with a purely functional language; my gut says "worse," but I haven't tried it so I don't know, and the fact that many students with this problem go on to handle declarative languages pretty well gives me pause.
I'd honestly go ahead and bite the bullet and say these students are lacking in an important intellectual capacity if they can't handle that extremely modest amount of abstraction. If they are successful it is probably due to a solid work ethic.
You know, that's what I thought for the longest time, but I eventually saw enough otherwise-perfectly-normal adults get hung up on the same problem--- and talked to enough other teachers who reported the same thing--- that I came to believe that there was something fundamentally different going on, and that it wasn't just a few tough students.
As somebody who's been programming for most of my life, it was really hard for me to learn to think about this stuff from the perspective of somebody who'd never seen it before. Many thought patterns and cognitive skills that are second nature to us programmers are, for a lot of people, very difficult to learn.
As somebody who's been programming for most of my life, it was really hard for me to learn to think about this stuff from the perspective of somebody who'd never seen it before. Many thought patterns and cognitive skills that are second nature to us programmers are, for a lot of people, very difficult to learn.
The idea of abstractions has really been nagging at me lately. Specifically the abstractions that other people use to understand the world.
I know that personally I enjoy conversing at least specific level of detail that includes only the subset of things that are relevant, while my wife will enumerate all the elements in a set even if there is a perfectly good description or name for that set.
I really just want to tap people on the shoulder and ask them, "excuse me, how do you think that thing you're doing works?". Unfortunately I haven't found a setting where that is socially or professionally appropriate, and includes people that would give interesting replies.
Conversely I know just enough about cars to be dangerous, I'm sure there's a mechanic out there that would find my explanation of the workings of an engine interesting.
I know that personally I enjoy conversing at least specific level of detail that includes only the subset of things that are relevant, while my wife will enumerate all the elements in a set even if there is a perfectly good description or name for that set.
I really just want to tap people on the shoulder and ask them, "excuse me, how do you think that thing you're doing works?". Unfortunately I haven't found a setting where that is socially or professionally appropriate, and includes people that would give interesting replies.
Conversely I know just enough about cars to be dangerous, I'm sure there's a mechanic out there that would find my explanation of the workings of an engine interesting.
The word you're looking for might be "metacognition" ("thinking about thinking"), and I agree that it's a fascinating concept. We spend our whole lives locked inside our skulls looking out, and it can be fascinating to imagine or learn about how others experience their cognitive worlds.
To me, that's one thing I enjoy about teaching- a lot of the time, you're having to try and figure out how a student is perceiving the subject or lecture. In essence, you're constantly reverse-engineering your students' perceptions of what you're telling them.
To me, that's one thing I enjoy about teaching- a lot of the time, you're having to try and figure out how a student is perceiving the subject or lecture. In essence, you're constantly reverse-engineering your students' perceptions of what you're telling them.
You can simulate <pre>
by
indenting
four spaces inAh, thanks! I'd been trying to figure out how to do that. I missed the memo on how to use HN's comment formatting system. Now, if I could just figure out how to edit a comment...
Huh. OK, I can edit this comment's parent comment ("Ah, thanks!...") but not my original comment. Is there something going on whereby comments older than a certain number of hours can't be edited?
[deleted]
It’s a lot like Chess or Poker, you can teach anyone the basic rules in a few minutes and they will be able to have some level of success, but it can take you a lifetime to master
Learning the language of programming is easy (like learning the chords on a guitar) but combining the elements of programming into a working solution to a problem is an entirely different thing. Like any other skill the amount of labor required to go from novice to master grow exponentially over the course of learning.
"The contraints imposed in building large software systems are the limitations of our own minds. In that sense computer science is like an abtract form of engineering; it's the kind of engineering where you ignore the constraints that are imposed by reality." - Harold Abelson in SICP lectures
I've always thought it was pretty easy. But you can't judge that kind of stuff in a vacuum - maybe if the people around me were demonstrably better programmers I would have a hard time trying to close the gap.
I think programming is a vague term. If programming just means rigorously encoding an imprecise set of instructions then while not easy I cannot say it is especially difficult.
But if your programming involves complex mathematics,physics, linguistics, biological, intricate interactions with the world, heck even philosophical concepts then programming is in the cartesian product of the domain and field and is as hard as the toughest problem you are attacking, judged with respect, also to the source field. The true difficulty is in balancing multiple species of abstraction, domain knowledge, device knowledge and encoding instruction in a way that satisfies all of these.
So there is the base difficulty of abstracting and then converting mental concepts to a set of computations compounded with the difficulty of getting the abstractions of your domain knowledge to transfer to a set of mental concepts that are transferable to a set of computations. heh. If the field you are dealing with is easy And Or you are continually dealing with the same problem more or less (just different facets) such that you had internalized most of the process to automated subthought (mastery) then yes it will appear easy.
Programming then, would only be bounded by its own internal difficulty, which gets easier the more you explore it and learn widely applicable abstractions. Once you mix in the difficulty of the field the same applies till you have reduced the interactions of field+programming to mastered concepts. If the field has a high minimum then this reduction may still always remain extremely difficult. So if one finds programming easy it could also be a sign that you are not challenging yourself enough, not pushing your boundaries sufficiently.
My theory is that those of the greatest skill have burning curiosity and will to improve, respond positively to challenge, and have great ability to focus - together this allows them to hold on to and continually attack a problem to a greater depth than most. You need only pick 3, maybe only 2. If there is any inherent genetic advantage held by some - greater ability to focus, efficient use of nutrients, quicker and more enduring synaptic connections, whatever - for the rest of us, I feel the brain is marvellously malleable and can be tuned down another set of dimensions. The space of intelligence is gigantic and non euclidean and likely with no concept of a global maximum. If the person is so determined they will work around their deficiencies and or train their mental processes stronger so that any "lack" of inherent skill does not get in the way of what they wish to do. This is what I believe I do and did. I do be slow as molasses.
But if your programming involves complex mathematics,physics, linguistics, biological, intricate interactions with the world, heck even philosophical concepts then programming is in the cartesian product of the domain and field and is as hard as the toughest problem you are attacking, judged with respect, also to the source field. The true difficulty is in balancing multiple species of abstraction, domain knowledge, device knowledge and encoding instruction in a way that satisfies all of these.
So there is the base difficulty of abstracting and then converting mental concepts to a set of computations compounded with the difficulty of getting the abstractions of your domain knowledge to transfer to a set of mental concepts that are transferable to a set of computations. heh. If the field you are dealing with is easy And Or you are continually dealing with the same problem more or less (just different facets) such that you had internalized most of the process to automated subthought (mastery) then yes it will appear easy.
Programming then, would only be bounded by its own internal difficulty, which gets easier the more you explore it and learn widely applicable abstractions. Once you mix in the difficulty of the field the same applies till you have reduced the interactions of field+programming to mastered concepts. If the field has a high minimum then this reduction may still always remain extremely difficult. So if one finds programming easy it could also be a sign that you are not challenging yourself enough, not pushing your boundaries sufficiently.
My theory is that those of the greatest skill have burning curiosity and will to improve, respond positively to challenge, and have great ability to focus - together this allows them to hold on to and continually attack a problem to a greater depth than most. You need only pick 3, maybe only 2. If there is any inherent genetic advantage held by some - greater ability to focus, efficient use of nutrients, quicker and more enduring synaptic connections, whatever - for the rest of us, I feel the brain is marvellously malleable and can be tuned down another set of dimensions. The space of intelligence is gigantic and non euclidean and likely with no concept of a global maximum. If the person is so determined they will work around their deficiencies and or train their mental processes stronger so that any "lack" of inherent skill does not get in the way of what they wish to do. This is what I believe I do and did. I do be slow as molasses.
I am new here and so do not understand the intricacies of this community. Is there anything particularly offensive or especially stupid about my comment? I tried to be careful but perhaps I failed and so would appreciate any insight for further edification.
Don't worry about it. Your comment was fine. People sometimes downvote for idiosyncratic reasons but someone else usually comes along and neutralizes that (as I just did). The main thing is to keep the discussion on-topic and not go meta.
You make an excellent point: the difficulty of programming is not only that of instructing the computer but also that of the problem the program is to solve. I agree.
(As an aside, the main problem with your comment is that it was rambling. This obscures your otherwise valuable insights. I recommend a course of obsessive-compulsive editing :))
You make an excellent point: the difficulty of programming is not only that of instructing the computer but also that of the problem the program is to solve. I agree.
(As an aside, the main problem with your comment is that it was rambling. This obscures your otherwise valuable insights. I recommend a course of obsessive-compulsive editing :))
Thanks, that was helpful. I'll have to take on that course as I do need to work on communicating clearly. The unedited stream of thought thing does a good job of hiding what I am trying to say. counter-productive.
The percentages of people with specific inherent skill sets will vary widely in society, so 'hard' is best defined as 'requiring a skill a smaller percentage of the population possess'. Good programming does require specific skills, but I don't see it as being any more difficult than other specialized tasks.
I don't find programming hard at all... perhaps that is because I started very young, perhaps it is just a 'natural' ability to understand and evaluate systems. To me it's second nature. However when I watch an artist form a mental image then extract it from a block of stone, or I watch my math PhD friend throw around set theory and abstract dimensions like cake recipes... I am fascinated.... and lost.
Hard is relative.