| HN Mirror

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

> Is there a particularly pressing reason to teach students who to translate pseudo-code from Wikipedia into <insert favorite language>?

Yes, an avl balanced binary search tree can run faster on an artificial computer than on a natural one.

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;

Then I realised that using this algorithm:

  avl_node *search_index(avl_node *node, int index) {
    int x=0;
    if(node->left)
      x=node->left->population;
    if(index>x)
      return search_index(node->right, index-x-1);
    else if(index<x)
      return search_index(node->left, index);
    else
      return 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.

No one is denying the notion that coding can be helpful when writing algorithms.

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.

DanBC 4337 days ago

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

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

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

https://news.ycombinator.com/item?id=8126115

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