[NAFV_P]

Harold Abelson, yeah? I was wondering what an assembly programmer would say to this.

> 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.

[lliwta]

> 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".

(this comment was massaged, sorry for the edits.)

[NAFV_P]

> 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:

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.

[lliwta]

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.

[NAFV_P]

> 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?

[lliwta]

> 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.

[NAFV_P]

> I'm confused. Maybe you posted the wrong link?

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.