Hacker News new | ask | show | jobs
Ask HN: What's your view about learning how to program on paper?
5 points by jeira 5374 days ago
Hi hackers, how are you doing?

I have just started Computer Science at college and I will have a class named "Programming Fundamentals" where all our practice questions and exams are to be made on paper, instead of a computer.

This is supposed to be an introduction to programming and yet, we have close to no contact to actually programming on a computer. The teacher's logic is that we first need to learn how to "think like a programmer" but is paper a better way of achieving that?

What's your view on this?

6 comments

I've lectured for a few years. Classes like intro to IT, Software Engineering Fundamentals and a few other similar classes.

I think Programming Fundamentals should focus on teaching students how to visual systems (stuff) in the real world and how to make that stuff work in a computer. Basically, the job of a programmer is to take some manual process we do in the real world and automate it in a computer.

But the way the real world works and how you represent that real world in a computer are really different.

I think it is a wrong approach to learn how to do this by learning to code first. That being said....

I would recommend hacking stuff out on paper. Not necessarily the source code though. I wrote a book that tries to explain this stuff without using source code. I think drawing out your ideas using diagrams is a great first start (even UML diagrams can be helpful for this). I'm not saying you should program like this. Diagrams do help you take something in the real world and start to transform it to something more abstract: something that can eventually work in a computer.

Anyway, I'll be happy to give you a free copy of the book (I've given it away a few people on HN who are new to programming).

Also hope this helps answer your question.

Thanks Eric, really appreciated for your offer. I don't know how you generally approach this but I've updated my HN account with my email.

I will continue attending the class and see if it is indeed more abstract and focused on topics like logic and visual stuff. I'll also ask a friend of mine about her experience with the class and the teacher about how the exams are handled.

Once again, thank you for your help. Really appreciated :)

Only mods can see what you put in the "email" field. If you want people to see your email address, put it in the "about" box on your profile.
Done. Thanks for the help.
Done
I'd love to check it out too, Eric.
That's the way i did it fifteen or so years ago and it's the method i'll use if i had to teach an introductory course.

Pros:

- Using the trial&error approach to solve a problem is not efficient without a compiler, this forces you to think more carefully about the algorithm (and corner cases) instead of just typing out stuff until your algorithm "appears" to work.

- You'll learn to debug/test on paper, a skill that everyone must have.

Cons:

- Harder to learn the proper syntax without something that automatically shows errors? I'm not sure that this is a real issue...

What I meant by learning syntax is that you have to think more about syntax when you're writing it on paper. When you're typing C++, you're not really thinking about where all the semicolons and braces go, it's all pretty automatic. If you want to learn to "think like a programmer" that means being able to forget about the syntax and focus on your problem.

That said, I have to agree that bench testing is an invaluable skill. I was able to impress a lot of my classmates by simply glancing at a program listing and pointing out the bug.

But why only paper?

I am not against using paper to do things like doing a diagram so you can understand your algorithm better and its shortcomings, and you're right, knowing how to debug on paper is important, but how do you know you have a bug if you can't test the code in a computer?

Our practice classes don't have computers on the classroom. This is not to say you can't do that at home, of course)

>how do you know you have a bug if you can't test the code in a computer?

Exactly. The idea with paper is that you need to get to the point where you go knowing what you're doing. If, like you said in the OP this is just for quizzes/tests, paper is a good way for a professor to see what you know when you sat down for a test, not what you were able to massage into compiling during the exam period. In 4 years of college, I the vast majority (all?) of my tests, exams, quizzes were on paper unless it was a project to do at home. For the most part, on-paper tests are about showing you understand the concept at hand, not that you dot every I and cross every T. If one of the concepts a test is going to test you on is that you have semicolons at the end of lines, you're going to get docked for it on that one, but every test after that it will be at worst a tiny deduction. They know what writing code on paper is like, just show them what they're looking for, and you'll be good.

>Our practice classes don't have computers on the classroom

This is what concerns me. Are you saying you don't have computers during you lecture, or is this a lab-type period where you're still working on paper?

It's a lab-type period (I don't know how you call these in the States) where we are still working on paper.

At least I assume we are since we didn't had this week's class, but I went to the classroom and it was an ordinary one.

I've just read below that it's a scheme course, i did a few lessons on that too and the approach was similar to what you describe. If with "bug" you are referring to syntax errors (being scheme, missing or wrong parenthesis), yeah, without a compiler/syntax checker it will be a bit hard to spot them sometimes. For algorithm testing, it's not different than what you'll do using a compiler, only slower (considering that testing usually involves testing various input combinations). Will, in this case, be a better course with the use of a compiler? Hard to tell, my impression is just that using only paper will make you focus more on the code you are writing, but this could not work for everyone.
Because it's not about code really, it's about design of the solution.

PSP (Personal Software Process) encourages the same thing: do your design on paper and debug it, then write the code, do a visual run through of the code, then run it. For short routines, it actually works very well. The problem is that if you've been programming for years, it feels very unnatural and requires a lot of discipline.

I suck at programming on paper or whiteboard. For some reason it feels very unnatural to me. What feels more natural is diagramming and visualization on a whiteboard.

A lot of coding questions can often be sketched out in a few pictures. This is how I like to code. I like to visualize arrays, pointers, and circles/sets. Translating that visual representation of code is much easier for me.

I would say 'Programming Fundamentals' includes topics such as logic and problems solving. There is a lot of ground you can cover on these without requiring writing code, or even using a computer.

I would expect the class to be fairly abstract like that for a while, maybe getting into the basics of some specific language about half way through the semester.

It's OK if you're only learning concepts and not syntax. Also if you're allowed to draw pictures, that will help a lot.

Obviously there's no replacement for the immediate feedback you can get by exploring with a real live computer. And you won't learn what is easy for a computer to do that might be hard for you to think about. I.e. you won't learn what a computer "feels" like or how it reacts to your input. I think this is a bad idea for a beginning class. Maybe some theory class later would be better.

"Always yield to the hands-on imperative!"

Yes, I should have said something about it, but it is not, at least from what I've been told, about drawing boxes and having a visual representation of your algorithm, but actually writing it on Scheme. On a piece of paper.

What if I have a small bug, like a comma, or something small like that, out of place? I'll have to ask the teacher about it.

I'm thinking of just skipping this class and learn from OpenCourseware.

Thanks for your thoughts.

From my experience, teachers are pretty forgiving about "typos" in paper programming. They just want to make sure your thinking is good. Of course I can't vouch for your teacher in particular.
Not mine! I've got a story that my college buddies continue to tease me about, almost a decade later.

I was doing a test where we needed to write some computer code on paper. Somewhere in this code was a point that called for multiplication. No big deal. I drew my dot that I'd been taught in all of my math classes and continued on with the test.

When we got the results back, I noticed that he had marked me off for this particular part. Thinking that he had mistaken my dot for a decimal rather than a multiplication sign, I waited until after the class was over and approached him to let him know that I knew the right thing to do and was conveying it with my dot. Apparently he was looking for an asterisk to be drawn. I brought up that it was the same thing, but he would hear none of it. Out of seemingly nowhere he had become infuriated with the fact that I'd questioned him and started repeatedly asking "Will it compile? Will it compile?!" before eventually adding "Minus 10! Thank you Mr. Rose!" A whole letter grade on a test lost because I drew a dot rather than an asterisk. Oh well. At least my friends enjoy laughing it up.

I'll ask him what he thinks about that. Thanks, really appreciated.
As a Programmer I am agree with your teacher. yes it is good if you can write a program on computer. But that's not the case in every scenario. Suppose your are building a complex software at that time you have to foresee the potential breaking points before you start writing your code so you can avoid the bugs at that time code or logic on paper will help you.