> Broad computer-science skills that include technological awareness and analytical thinking are more important than narrow programming skills, Hartovi said.
"Learning how to code in any one particular [computer] language is not going to be worthwhile beyond 10 or 20 years," he said. "Learning how to problem-solve using algorithms and how technology works and how it's built is going to last a century at least."
I fail to see how you could write an algorithm if you don't know how to code.
> You never followed directions until you learned how to program?
Of course I did (sometimes reluctantly). Before I learned programming, I couldn't 'write' an algorithm in a file and get a computer to follow those directions instead.
> I learned addition, multiplication and division algorithms before I even got a computer.
I know, subtraction is so damn hard to get right isn't it.
>I fail to see how you could write an algorithm if you don't know how to code.
I teach introductory programming to college freshmen. We usually spend the first few classes talking about, writing, and refining algorithms in clear and simple English before we even start talking about the programming language they're to learn.
> I teach introductory programming to college freshmen. We usually spend the first few classes talking about, writing, and refining algorithms in clear and simple English before we even start talking about the programming language they're to learn.
Explaining algorithms to someone in clear and simple English will enable them to understand those algorithms, but a computer does not understand English. To 'write' an algorithm for a computer to perform, you need to code.
There seems to be a misunderstanding of the word algorithm here. "Algorithm" refers to a set of instructions/operations that do not necessarily occur on a computer. You may know non-computer algorithms as "routines" or "procedures".
> I fail to see how you could write an algorithm if you don't know how to code.
Algorithms have existed for centuries. Computer programs have meaningfully existed for 100 years, if we're generous. And for a lot of that time, you had to design the entire algorithm correctly before running to code, or else you'd have to wait a day or two and try again (unless you were important).
Even today, if you're designing a truly novel algorithm, you're very likely to spend the bulk of your time not coding, and then coding only at the end as a sort of check to make sure you ideas work out. Of course everyone has different processes and YMMV, but mt general impression is that most people who design significant (read publication worthy) algorithms do the bulk of their work away from the keyboard.
And honestly, having taught high school cs students, the best students have this process: 1) try a niave solution, notice it won't work before they even compile. Maybe finish the program just to confirm their suspicion that it's wrong; 2) go to the white board for a while, and probably talk with their friends about potential solutions and pitfalls; 3) design the algorithm, and then code it up. Usually there's no pseudo-code before they start programming, but they have a pretty clear idea of the general structure of the algorithm; 4) test on inputs that they identified as reasons the niave solution(s) discussed at the board didn't work.
edit: the very worst students are the ones who sit in isolation hacking away at iterative improvements on a fundamentally flawed idea. Usually they're trying to get their for loops sorted out and working correctly so that the program actually gets around to giving them any answer, and don't even get around to noticing their solution is completely and fundamentally broken until the end of class.
Which is to say, from my observation, coding-as-problem-solving is not very effective until after you've thought things through in more general, mathematical terms.
> Even today, if you're designing a truly novel algorithm, you're very likely to spend the bulk of your time not coding, and then coding only at the end as a sort of check to make sure you ideas work out.
If you cannot code, you cannot check that your ideas work out on a computer.
> Which is to say, from my observation, coding-as-problem-solving is not very effective until after you've thought things through in more general, mathematical terms.
I don't see how that relates to my comment, I specifically referred to 'writing' an algorithm, as in implementing the algorithm in code, not devising the algorithm in the first place.
> I specifically referred to 'writing' an algorithm, as in implementing the algorithm in code, not devising the algorithm in the first place.
That's confusing usage of "write an algorithm". There used to be a distinction between "programming" (creatig program structure; sequence selection iteration and all tha stuff) qnd "coding" (taking those paper notes and translating them into the particular programming language being used).
It's easy to find people who could create an algorithm but who cannot also code. For example, you can create an algorithm, but you know nothing about {insert the name of a language which you know nothing about here}.
> That's confusing usage of "write an algorithm". There used to be a distinction between "programming" (creatig program structure; sequence selection iteration and all tha stuff) qnd "coding" (taking those paper notes and translating them into the particular programming language being used).
Apologies for being vague, I presumed the phrase 'writing an algorithm' was sufficiently precise.
> It's easy to find people who could create an algorithm but who cannot also code.
I rephrase that: It's easy to find people who could create an algorithm but can only target a specific architecture, human grey matter.
> It's easy to find people who could create an algorithm but can only target a specific architecture, human grey matter.
"Programs should be written for people to read, and only incidentally for machines to execute."
The key difference is that if the skill of implementing an algorithm in <insert programming language> code can be learned in a few weeks max. It's a matter of whether you've bothered to learn the skill, not whether you're capable of learning the skill.
Learning the problem solving skills to create new algorithms is not so trivial, and often can't be self-taught.
> Harold Abelson, yeah? I was wondering what an assembly programmer would say to this.
Taking my comment within the wider context of the conversation, and the general conflation of "writing an algorithm" with "copying down into a programming language from existing pseudocode", I like to think most notable computer scientists would agree with the sentiment that we should be prioritizing the teaching of algorithms over the teaching of programming.
edit: Most importantly, no one is claiming that these two are somehow mutually exclusive. Only that the latter should be in service to the former, and not the other way around.
That is, when teaching CS, we should teach concepts, and include instruction on how to implement programs because it's a useful tool for learning CS. "Turtle Geometry" is a fantastic example of this, BTW. The focus is on the concepts, with programming as a tool for understanding them. But -- to the refutation of your core argument -- it's definitely never insinuated in TG that the ideas don't exist independently of the programming. Such an insinuation, that geometry does not exist independently of a programming environment, is as absurd as the notion that algorithms can't be written without a machine.
But anyways, your initial claim was that you need to be able to program in order to write algorithms. Which, aside from your highly non-standard use of the phrase, is just clearly not the case.
Also, of course programming has its own set of hurdles. But there's a difference between writing highly optimized assembly and copying an algorithm into Python.
> Getting someone to put themselves 'in the shoes of a computer', is just as difficult.
In my experience teaching, this isn't the case.
If you can teach the student to think precisely and unambiguously about a single algorithm, the unrelenting logic of the machine is no stumbling block; quite the opposite, actually.
It's far more effective and less degrading than having students fight with the machine and get confused about why it won't "do what they want it to do".
> But -- to the refutation of your core argument -- it's definitely never insinuated in TG that the ideas don't exist independently of the programming. Such an insinuation, that geometry does not exist independently of a programming environment, is as absurd as the notion that algorithms can't be written without a machine.
Was that my core argument? My original comment (as pointed out by the omnipresent DanBC) was poorly phrased, and was rephrased as:
> If you can teach the student to think precisely and unambiguously about a single algorithm, the unrelenting logic of the machine is no stumbling block; quite the opposite, actually.
Of course it isn't a stumbling block, logical thinking is required for both, which would also explain why they are both difficult.
Both of the statements in that link are just tautologies...
You can teach computer science without teaching coding. And you can write algorithms without testing them on a computer.
So the tautology that "you can't code if you can't code" isn't a particularly important pedagogical insight when it comes to teaching CS, since CS != coding.
> Of course it isn't a stumbling block, logical thinking is required for both, which would also explain why they are both difficult.
Right. And I'm saying that, in my experience teaching, it's better to teach CS and then let programming be something that kind of just falls out of that naturally, as opposed to focusing on programming itself.
> Both of the statements in that link are just tautologies...
I do not understand, and there are four statements, not two.
> Right. And I'm saying that, in my experience teaching, it's better to teach CS and then let programming be something that kind of just falls out of that naturally, as opposed to focusing on programming itself.
Where did I say that the focus should purely be on programming?
> Where did I say that the focus should purely be on programming?
If you'd be okay with teaching a CS course without programming, we might be talking past one another.
> I do not understand, and there are four statements, not two.
I'm confused. Maybe you posted the wrong link?
Here are the two comments from the linked post:
> If you cannot code, you cannot check that your ideas work out on a computer.
This is only true when it just reduces to "if you cannot code, you cannot code".
Taken literally, the statement is just blatantly false. You could use a computer to figure out properties of your algorithm or for designing an algorithm without actually implementing and running the algorithm; e.g. for getting closed forms of sums, or for finding/verifying the convergent behavior of a series which the algorithm relies on.
So the statement really is only true if it's a tautology.
> I don't see how that relates to my comment, I specifically referred to 'writing' an algorithm, as in implementing the algorithm in code, not devising the algorithm in the first place.
'writing' an algorithm = implement the algorithm in code
So, substituting into your original statement:
"I fail to see how you could implement the algorithm in code if you don't know how to code."
No, you're just confused. You mentioned the two statements in that link, but you have only described one. The other statement you referred to is from my original comment.
Do you have a point, or are you just being pedantic? That is, is there some essence of your position which I haven't adequately addressed? If so, what is that essence?
FWIW Your original statement is referentially transparent wrt the meaning of 'writing' an algorithm ("I specifically referred..."). You were clarifying what you meant by this phrase. So the substitution of your intended meaning into your original statement is justified; in fact, is the entire purpose of your clarification. Otherwise you're just giving a definition with absolutely no context or purpose.
> That is, is there some essence of your position which I haven't adequately addressed? If so, what is that essence?
That essence is something you and I have in common. I believe this thread sprouted because of how my original comment was interpreted. I think you are the first HN reader to actually give a decent word for word analysis of my comments. A lot of the time I just have to endure obvious misinterpretations, elaborations, misquotes or sometimes just plain fabrications. It's good to come across someone who takes time to read boring old English.
> If you cannot code, you cannot check that your ideas work out on a computer.
Believe it or not, it's possible to write provable correct algorithms without writing a single test case :-)
Of course implementing is a useful sanity check. But it's not the important part -- it's not the skill set we should most emphasize in education.
> as in implementing the algorithm in code, not devising the algorithm in the first place.
Is there a particularly pressing reason to teach students who to translate pseudo-code from Wikipedia into <insert favorite language>? Sounds like a perhaps useful but pretty menial skill to me. Not the sort of core skill you'd organize a curriculum revision around for sure.
My point was that "copy an algorithm into programming language X" isn't something which needs to be taught in the first place, and isn't an economically valuable skill because literally anybody can be taught this skill in a few weeks.
If I had to choose between teaching why an avl balanced binary search tree works and forcing students to implement in a chosen programming language from pseudocode, I would choose the former every time. The intellectual maturity is far more valuable -- and harder to acquire -- than the rote skill.
> My point was that "copy an algorithm into programming language X" isn't something which needs to be taught in the first place, and isn't an economically valuable skill because literally anybody can be taught this skill in a few weeks.
That depends on the language, I doubt you could learn much about programming in a few weeks, it requires lots of practise.
> If I had to choose between teaching why an avl balanced binary search tree works and forcing students to implement in a chosen programming language from pseudocode, I would choose the former every time. The intellectual maturity is far more valuable -- and harder to acquire -- than the rote skill.
You are giving yourself a hard choice, just demonstrate both sides.
From personal experience, I've been looking at bst's recently. While messing around in my code, out of the blue I decided to write the struct for the node like this:
typedef struct avl_node_typed {
avl_node_typed *left, *right;
void *data;
unsigned height, population; /* avl algorithm requires height, not number of nodes */
}avl_node;
I could access the nth node in a tree. I had rediscovered the algorithm of order statistic trees, which can be treated syntactically like an array (this can be applied to all ordered trees, not just avl). During this time I was looking up knowledge on avl trees and coding away on my machine. If I was purely focused on the algorithmic side, I don't think I would have found it.
Ok, fine "algorithms" have been around for centuries. There is no disputing that. But without the notion of "programming," you're missing an entire style and class of algorithms.
Generally, algorithms are described in terms of pseudo code using programmatic language as well as terms of set theory or graph theory.
That said, I don't see why it is shocking to people that 12 year olds aren't learning CS in school.
> But without the notion of "programming," you're missing an entire style and class of algorithms.
And if you focus on programming, you miss the forest for the trees.
You can teach CS without teaching programming, and it will still be valuable.
You can teach programming without CS, but the skills you end up teaching will just be skills -- they're non-transferable and aren't going to be useful in 10 years.
> Generally, algorithms are described in terms of pseudo code using programmatic language as well as terms of set theory or graph theory.
I think the latter semantic descriptions are almost always the more important ones.
I hope I'm not at the age of being just on the cusp of the time when the salary starts to decrease when I get in the field. Probably unlikely though right?
IMHO, the whole process has been going on for quite some time. For freelancer's, there's the ever increasing competition from Asia/India/low living costs region which leads to less profit (arguably, most code coming from those regions is bad but even that will increase eventually).
As for "proper" jobs ... well... given that you see more and more articles about people finishing up college without being able to code at all, the salary gap is probably only going to increasFor desk jobs / 8-to-5 jobs in mainland US... e. There'll probably be those coders that learn how to code pre-college and are then able to translate their experience post-college, whereas there'll always be those who are good at social things & buzzwords. Distinguishing yourself from the mass early on will probably make a big change regarding your target salary.
In the end, I'm constantly reminded of my IT teacher's saying from high school (loosely translated from German): becoming a programmer just requires training. becoming a computer scientist / engineer, however, requires far more/university. (please keep in mind that CS in Germany is far more theoretically oriented than CS in the US)
I think in this day and age to actually be a good software engineer you need to keep advancing and learning new skills. If you sit back with what you learned in uni and don't actively seek out more knowledge you will fall behind into the category of just a programmer.
Credentialist elitism seems to have a stronger hold in Germany than in the US. To be sure, it exists everywhere to some degree or another, but the US also respects those who perform even if they don't have the paper (e.g. Steve Wozniak, John Carmack, etc).
I've been teaching a 12-yo kid python programming and the surprising thing is that none of his friends (nor him) learn any programming in school. As per him, most public schools in his area (Boston) don't have any programming work in their regular curriculum, despite the fact that one keeps seeing such articles popping up often.
When I was in mid-school, a decade back (in India) we had regular classes on Basic and C++ in high school. I might be completely wrong in generalizing but haven't the schools in US picked up on this trend?
> I might be completely wrong in generalizing but haven't the schools in US picked up on this trend?
There are lots of reasons, but I think the largest contributing factor is that these teaching staff doesn't exist.
In most high schools, there is no dedicated "programming" or "CS" teacher. Often these courses of off-loaded to a business-y person. In my experience, these were pretty useless and sometimes worse than useless. E.g. in one case this person was a retired math teacher who was tenured but awful, and "computer class" seemed like a low-impact place to put them.
If a Math or Science teacher wanted to teach a programming class and had been around for a few years (and got along with their administrators), they could probably get away with teaching one section a year. Maybe scale up if there's demand and the department isn't under-staffed. But that's fairly rare, because lots of math people don't really "get" CS.
I think what worked in our (India) favor, despite the dearth of good teachers was the fact that Computers was an available subject in the nationwide standardised exams. Most of students who wanted to pursue Engineering loaded up on computers because it was easy (& fun) to score (compared with languages at the very least).
1) I do not believe the school administrators "get" computers beyond knowing how to use things like a web browser, email, MS Office, or education databases for K-12 research projects. They cannot set effective policy and direction because they do not have a clue what it is they need to do.
2) Many (most?) parents do not know or care about what programming entails or do not understand how computer programming might be extremely beneficial for their kid. Without parents pushing for these courses nothing is going to change since groups of vocal parents are the one thing that school administrators generally act for.
3) Finding qualified individuals is going to be tough. People who do not understand programming cannot teach kids to program. People who understand how to program AND are good at teaching are an extremely rare commodity. You can find lots of one or the other, but the ones who can do both are probably already employed doing something more rewarding (personally or economically).
4) We, as a society, need to determine what is important to teach. Is it computer science or is it programming? You can get a lot of mileage out of just teaching programming, but CS is a beautiful thing that fits more in line with a true academic mission - but CS does not imply any programming.
the surprising thing is that none of his friends (nor him) learn any programming in school
Why is that surprising? I am a professional programmer and frankly, it's a trade skill. Teaching kids at school how to program is like teaching them plumbing or how to be an electrician. To specialise that early is just crazy. Sure, teach general logical problem solving, but to specialise as far as what is a niche skill?
Sure, this is an unpopular viewpoint on Hacker News, where the audience is self-selecting to the viewpoint that programming is the most important life skill there is and that 90 percent of the population should learn to program, but that's just the typical nonsense any self-selecting audience ends up groupthinking. If this were a farming forum, people would be shouting "why aren't we teaching children how to grow turnips?".
The problem isn't that everyone doesn't learn it, but that noone learns it.
It wouldn't be a big deal if the elective were available but not taken by everyone. The problem is that in most cases, there isn't a programming class. Period. Ever.
> "why aren't we teaching children how to grow turnips?".
Why wouldn't we want to teach kids the basics of gardening? I was taught in elementary school, as part of our unit on "Biology" in second and third grade.
Playing the violin is also a trade skill. I don't think the job market implications of programming need to be a deterrent. Programming can simply be taught as a creative activity. I learned programming because it was interesting and fun.
In fact, teaching programming to kids as a trade skill is likely to turn them off.
43 comments
[ 3.5 ms ] story [ 112 ms ] thread"Learning how to code in any one particular [computer] language is not going to be worthwhile beyond 10 or 20 years," he said. "Learning how to problem-solve using algorithms and how technology works and how it's built is going to last a century at least."
I fail to see how you could write an algorithm if you don't know how to code.
You never followed directions until you learned how to program?
I learned addition, multiplication and division algorithms before I even got a computer.
Of course I did (sometimes reluctantly). Before I learned programming, I couldn't 'write' an algorithm in a file and get a computer to follow those directions instead.
> I learned addition, multiplication and division algorithms before I even got a computer.
I know, subtraction is so damn hard to get right isn't it.
I teach introductory programming to college freshmen. We usually spend the first few classes talking about, writing, and refining algorithms in clear and simple English before we even start talking about the programming language they're to learn.
Explaining algorithms to someone in clear and simple English will enable them to understand those algorithms, but a computer does not understand English. To 'write' an algorithm for a computer to perform, you need to code.
I can assure you there is none , the misunderstanding is with my original comment: 'writing an algorithm'.
> You may know non-computer algorithms as "routines" or "procedures".
Like the algorithm "make a nice, hot cup of coffee", which is executed billions of times each day by biological computers known as humans.
EDIT: wrt my naff spelling.
Algorithms have existed for centuries. Computer programs have meaningfully existed for 100 years, if we're generous. And for a lot of that time, you had to design the entire algorithm correctly before running to code, or else you'd have to wait a day or two and try again (unless you were important).
Even today, if you're designing a truly novel algorithm, you're very likely to spend the bulk of your time not coding, and then coding only at the end as a sort of check to make sure you ideas work out. Of course everyone has different processes and YMMV, but mt general impression is that most people who design significant (read publication worthy) algorithms do the bulk of their work away from the keyboard.
And honestly, having taught high school cs students, the best students have this process: 1) try a niave solution, notice it won't work before they even compile. Maybe finish the program just to confirm their suspicion that it's wrong; 2) go to the white board for a while, and probably talk with their friends about potential solutions and pitfalls; 3) design the algorithm, and then code it up. Usually there's no pseudo-code before they start programming, but they have a pretty clear idea of the general structure of the algorithm; 4) test on inputs that they identified as reasons the niave solution(s) discussed at the board didn't work.
edit: the very worst students are the ones who sit in isolation hacking away at iterative improvements on a fundamentally flawed idea. Usually they're trying to get their for loops sorted out and working correctly so that the program actually gets around to giving them any answer, and don't even get around to noticing their solution is completely and fundamentally broken until the end of class.
Which is to say, from my observation, coding-as-problem-solving is not very effective until after you've thought things through in more general, mathematical terms.
If you cannot code, you cannot check that your ideas work out on a computer.
> Which is to say, from my observation, coding-as-problem-solving is not very effective until after you've thought things through in more general, mathematical terms.
I don't see how that relates to my comment, I specifically referred to 'writing' an algorithm, as in implementing the algorithm in code, not devising the algorithm in the first place.
That's confusing usage of "write an algorithm". There used to be a distinction between "programming" (creatig program structure; sequence selection iteration and all tha stuff) qnd "coding" (taking those paper notes and translating them into the particular programming language being used).
It's easy to find people who could create an algorithm but who cannot also code. For example, you can create an algorithm, but you know nothing about {insert the name of a language which you know nothing about here}.
Apologies for being vague, I presumed the phrase 'writing an algorithm' was sufficiently precise.
> It's easy to find people who could create an algorithm but who cannot also code.
I rephrase that: It's easy to find people who could create an algorithm but can only target a specific architecture, human grey matter.
"Programs should be written for people to read, and only incidentally for machines to execute."
The key difference is that if the skill of implementing an algorithm in <insert programming language> code can be learned in a few weeks max. It's a matter of whether you've bothered to learn the skill, not whether you're capable of learning the skill.
Learning the problem solving skills to create new algorithms is not so trivial, and often can't be self-taught.
> Learning the problem solving skills to create new algorithms is not so trivial, and often can't be self-taught.
Getting someone to put themselves 'in the shoes of a computer', is just as difficult.
Taking my comment within the wider context of the conversation, and the general conflation of "writing an algorithm" with "copying down into a programming language from existing pseudocode", I like to think most notable computer scientists would agree with the sentiment that we should be prioritizing the teaching of algorithms over the teaching of programming.
edit: Most importantly, no one is claiming that these two are somehow mutually exclusive. Only that the latter should be in service to the former, and not the other way around.
That is, when teaching CS, we should teach concepts, and include instruction on how to implement programs because it's a useful tool for learning CS. "Turtle Geometry" is a fantastic example of this, BTW. The focus is on the concepts, with programming as a tool for understanding them. But -- to the refutation of your core argument -- it's definitely never insinuated in TG that the ideas don't exist independently of the programming. Such an insinuation, that geometry does not exist independently of a programming environment, is as absurd as the notion that algorithms can't be written without a machine.
But anyways, your initial claim was that you need to be able to program in order to write algorithms. Which, aside from your highly non-standard use of the phrase, is just clearly not the case.
Also, of course programming has its own set of hurdles. But there's a difference between writing highly optimized assembly and copying an algorithm into Python.
> Getting someone to put themselves 'in the shoes of a computer', is just as difficult.
In my experience teaching, this isn't the case.
If you can teach the student to think precisely and unambiguously about a single algorithm, the unrelenting logic of the machine is no stumbling block; quite the opposite, actually.
It's far more effective and less degrading than having students fight with the machine and get confused about why it won't "do what they want it to do".
(this comment was massaged, sorry for the edits.)
Was that my core argument? My original comment (as pointed out by the omnipresent DanBC) was poorly phrased, and was rephrased as:
https://news.ycombinator.com/item?id=8126115
> If you can teach the student to think precisely and unambiguously about a single algorithm, the unrelenting logic of the machine is no stumbling block; quite the opposite, actually.
Of course it isn't a stumbling block, logical thinking is required for both, which would also explain why they are both difficult.
You can teach computer science without teaching coding. And you can write algorithms without testing them on a computer.
So the tautology that "you can't code if you can't code" isn't a particularly important pedagogical insight when it comes to teaching CS, since CS != coding.
> Of course it isn't a stumbling block, logical thinking is required for both, which would also explain why they are both difficult.
Right. And I'm saying that, in my experience teaching, it's better to teach CS and then let programming be something that kind of just falls out of that naturally, as opposed to focusing on programming itself.
I do not understand, and there are four statements, not two.
> Right. And I'm saying that, in my experience teaching, it's better to teach CS and then let programming be something that kind of just falls out of that naturally, as opposed to focusing on programming itself.
Where did I say that the focus should purely be on programming?
If you'd be okay with teaching a CS course without programming, we might be talking past one another.
> I do not understand, and there are four statements, not two.
I'm confused. Maybe you posted the wrong link?
Here are the two comments from the linked post:
> If you cannot code, you cannot check that your ideas work out on a computer.
This is only true when it just reduces to "if you cannot code, you cannot code".
Taken literally, the statement is just blatantly false. You could use a computer to figure out properties of your algorithm or for designing an algorithm without actually implementing and running the algorithm; e.g. for getting closed forms of sums, or for finding/verifying the convergent behavior of a series which the algorithm relies on.
So the statement really is only true if it's a tautology.
> I don't see how that relates to my comment, I specifically referred to 'writing' an algorithm, as in implementing the algorithm in code, not devising the algorithm in the first place.
'writing' an algorithm = implement the algorithm in code
So, substituting into your original statement:
"I fail to see how you could implement the algorithm in code if you don't know how to code."
which is a tautology.
No, you're just confused. You mentioned the two statements in that link, but you have only described one. The other statement you referred to is from my original comment.
FWIW Your original statement is referentially transparent wrt the meaning of 'writing' an algorithm ("I specifically referred..."). You were clarifying what you meant by this phrase. So the substitution of your intended meaning into your original statement is justified; in fact, is the entire purpose of your clarification. Otherwise you're just giving a definition with absolutely no context or purpose.
That essence is something you and I have in common. I believe this thread sprouted because of how my original comment was interpreted. I think you are the first HN reader to actually give a decent word for word analysis of my comments. A lot of the time I just have to endure obvious misinterpretations, elaborations, misquotes or sometimes just plain fabrications. It's good to come across someone who takes time to read boring old English.
Believe it or not, it's possible to write provable correct algorithms without writing a single test case :-)
Of course implementing is a useful sanity check. But it's not the important part -- it's not the skill set we should most emphasize in education.
> as in implementing the algorithm in code, not devising the algorithm in the first place.
Is there a particularly pressing reason to teach students who to translate pseudo-code from Wikipedia into <insert favorite language>? Sounds like a perhaps useful but pretty menial skill to me. Not the sort of core skill you'd organize a curriculum revision around for sure.
Yes, an avl balanced binary search tree can run faster on an artificial computer than on a natural one.
If I had to choose between teaching why an avl balanced binary search tree works and forcing students to implement in a chosen programming language from pseudocode, I would choose the former every time. The intellectual maturity is far more valuable -- and harder to acquire -- than the rote skill.
That depends on the language, I doubt you could learn much about programming in a few weeks, it requires lots of practise.
> If I had to choose between teaching why an avl balanced binary search tree works and forcing students to implement in a chosen programming language from pseudocode, I would choose the former every time. The intellectual maturity is far more valuable -- and harder to acquire -- than the rote skill.
You are giving yourself a hard choice, just demonstrate both sides.
From personal experience, I've been looking at bst's recently. While messing around in my code, out of the blue I decided to write the struct for the node like this:
Then I realised that using this algorithm: I could access the nth node in a tree. I had rediscovered the algorithm of order statistic trees, which can be treated syntactically like an array (this can be applied to all ordered trees, not just avl). During this time I was looking up knowledge on avl trees and coding away on my machine. If I was purely focused on the algorithmic side, I don't think I would have found it.But it doesn't follow that programming a machine is necessary for writing algorithms.
The machine can be and often is as much of a distraction as it is a tool when teaching CS.
Generally, algorithms are described in terms of pseudo code using programmatic language as well as terms of set theory or graph theory.
That said, I don't see why it is shocking to people that 12 year olds aren't learning CS in school.
And if you focus on programming, you miss the forest for the trees.
You can teach CS without teaching programming, and it will still be valuable.
You can teach programming without CS, but the skills you end up teaching will just be skills -- they're non-transferable and aren't going to be useful in 10 years.
> Generally, algorithms are described in terms of pseudo code using programmatic language as well as terms of set theory or graph theory.
I think the latter semantic descriptions are almost always the more important ones.
IMHO, the whole process has been going on for quite some time. For freelancer's, there's the ever increasing competition from Asia/India/low living costs region which leads to less profit (arguably, most code coming from those regions is bad but even that will increase eventually).
As for "proper" jobs ... well... given that you see more and more articles about people finishing up college without being able to code at all, the salary gap is probably only going to increasFor desk jobs / 8-to-5 jobs in mainland US... e. There'll probably be those coders that learn how to code pre-college and are then able to translate their experience post-college, whereas there'll always be those who are good at social things & buzzwords. Distinguishing yourself from the mass early on will probably make a big change regarding your target salary.
In the end, I'm constantly reminded of my IT teacher's saying from high school (loosely translated from German): becoming a programmer just requires training. becoming a computer scientist / engineer, however, requires far more/university. (please keep in mind that CS in Germany is far more theoretically oriented than CS in the US)
When I was in mid-school, a decade back (in India) we had regular classes on Basic and C++ in high school. I might be completely wrong in generalizing but haven't the schools in US picked up on this trend?
There are lots of reasons, but I think the largest contributing factor is that these teaching staff doesn't exist.
In most high schools, there is no dedicated "programming" or "CS" teacher. Often these courses of off-loaded to a business-y person. In my experience, these were pretty useless and sometimes worse than useless. E.g. in one case this person was a retired math teacher who was tenured but awful, and "computer class" seemed like a low-impact place to put them.
If a Math or Science teacher wanted to teach a programming class and had been around for a few years (and got along with their administrators), they could probably get away with teaching one section a year. Maybe scale up if there's demand and the department isn't under-staffed. But that's fairly rare, because lots of math people don't really "get" CS.
This would certainly help.
1) I do not believe the school administrators "get" computers beyond knowing how to use things like a web browser, email, MS Office, or education databases for K-12 research projects. They cannot set effective policy and direction because they do not have a clue what it is they need to do.
2) Many (most?) parents do not know or care about what programming entails or do not understand how computer programming might be extremely beneficial for their kid. Without parents pushing for these courses nothing is going to change since groups of vocal parents are the one thing that school administrators generally act for.
3) Finding qualified individuals is going to be tough. People who do not understand programming cannot teach kids to program. People who understand how to program AND are good at teaching are an extremely rare commodity. You can find lots of one or the other, but the ones who can do both are probably already employed doing something more rewarding (personally or economically).
4) We, as a society, need to determine what is important to teach. Is it computer science or is it programming? You can get a lot of mileage out of just teaching programming, but CS is a beautiful thing that fits more in line with a true academic mission - but CS does not imply any programming.
Why is that surprising? I am a professional programmer and frankly, it's a trade skill. Teaching kids at school how to program is like teaching them plumbing or how to be an electrician. To specialise that early is just crazy. Sure, teach general logical problem solving, but to specialise as far as what is a niche skill?
Sure, this is an unpopular viewpoint on Hacker News, where the audience is self-selecting to the viewpoint that programming is the most important life skill there is and that 90 percent of the population should learn to program, but that's just the typical nonsense any self-selecting audience ends up groupthinking. If this were a farming forum, people would be shouting "why aren't we teaching children how to grow turnips?".
The problem isn't that everyone doesn't learn it, but that noone learns it.
It wouldn't be a big deal if the elective were available but not taken by everyone. The problem is that in most cases, there isn't a programming class. Period. Ever.
> "why aren't we teaching children how to grow turnips?".
Why wouldn't we want to teach kids the basics of gardening? I was taught in elementary school, as part of our unit on "Biology" in second and third grade.
In fact, teaching programming to kids as a trade skill is likely to turn them off.