This is like asking an un-experienced driver to drive fast. Or an un-exprerience scuba diver to go deeper.
I remember that I didn't code fast in my CS1 classes. The reason was because it was scary. The compiler and all syntax errors seemed cryptic.
Now one of the goals of the class should be to make students not afraid of trying things out. To get there they have to understand the tools and the basics.
Having a good langauge + compiler/interpreter definetly helps. For example, Python's REPL is a way to try things fast. Especially when used with something like ipython, where you can explore an object's methods as you type.
C/C++ and gcc is not so great in this respect. You get a segementation fault, and the next thing you do is pepper code with print statements or fire up gdb. Now they have another problem to solve -- how to use gdb. Very useful, but perhaps not for someone in CS1, unless CS1 as a filter and its purpose is to scare everyone away.
One intermediate solution is to ask people to code everything out in pseudo-code. Think about what it would do. Then when they are happy about it comment it all out, and below each line of pseudo-code write real code doing the same thing.
This lets you do exploratory programming, and also generates verbose comments for the TA to look at.
That's true. But it (generally) doesn't let you discard your wrong ideas quickly, which is where the approach I was trying to describe gets most of its benefit. What you describe is much more akin to a waterfall model with a bunch of pseudocode and design up front but without an automated tool (the computer) actually able to run your program and tell you if it is going well.
That depends on which wrong ideas you're thinking about.
Actually writing down pseudo-code is good at flushing out hidden assumptions, points of confusion, etc. I've found that tracing through pseudo-code can help identify bottlenecks and design flaws. And it is all much cheaper than a real program. So you get to discard a lot of wrong ideas quickly.
However coding up a test program and being able to run through cases quickly on a computer catches slightly different classes of mistakes. You might not catch a logic error in your code, but you are more likely to figure out how an external API works.
I think that both skills are valuable, and both let you discard wrong ideas quickly. They just catch different kinds of wrong ideas. :-)
I remember that I didn't code fast in my CS1 classes. The reason was because it was scary. The compiler and all syntax errors seemed cryptic.
Now one of the goals of the class should be to make students not afraid of trying things out. To get there they have to understand the tools and the basics.
Having a good langauge + compiler/interpreter definetly helps. For example, Python's REPL is a way to try things fast. Especially when used with something like ipython, where you can explore an object's methods as you type.
C/C++ and gcc is not so great in this respect. You get a segementation fault, and the next thing you do is pepper code with print statements or fire up gdb. Now they have another problem to solve -- how to use gdb. Very useful, but perhaps not for someone in CS1, unless CS1 as a filter and its purpose is to scare everyone away.