5 ms·
> 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 exis
by lliwta 12y ago
> 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.
- NAFV_P 12y ago> 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.
- DanBC 12y 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}.
- NAFV_P 12y ago> 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.
- lliwta 12y ago> 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.
- NAFV_P 12y agoHarold 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.
- dinkumthinkum 12y agoOk, 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.
- lliwta 12y ago> 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.