Programmers: Do you hate pseudo-code?

[Sarevok]

Pseudocode has it's uses. I use it when writting complex algorithoms.

[EmperorMing]

For an introductory level course where the profs are trying to get the students used to actual code it does make sense. Pseudocode along with flowcharts and block diagrams really helped me get the hang of things in first year Computer Science since I had no formal experience with programming prior to that. But by the time 1st semester was over pseudocode was becoming more of pain in the ass than a help, and I was using flowcharts & diagrams to layout my programs and writing up the required pseudocode after after the actual program itself was done.

This is the same thing I am seeing with my first C++ course.

[aerius]

That's the problem with introductory programming courses. They're geared toward people who don't already think "in that way." But for those of us who already do, it tends to not only infuriate, but dampen enthusiasm for the class.

Seriously. I attack programming assignments like nothing else. I go out of my way to find different methods of doing things and go ahead of what we're supposed to do. I like the challenge. But then I get my grade back and find that I've received a 28/50 purely because she didn't like my presentational materials (the code compiled and produced the correct output), and I get cynical about the class.

The problem with my computer science curriculum in general is that the introductory courses are basically mechanized. They're taught by part-time teachers who work for State Farm, and the introductory C++ class is completely inflexible. So when you get students who want to do things differently, they're not rewarded or supported. Everything has to be done by the book, no exceptions, and that's a horrid way to approach programming, especially in the beginning sections.

Well, I guess I got lucky, that and we had the best computers prof in the university teaching our 1st year programming courses. She didn't care how we programmed code as long as they met the general parameters of the assignment and performed the correct functions. I remember how almost every single person in our tutorial classes would have a different solution for the assignment, and as long as everything worked you were pretty much good to go. Of course if you use an "if, then, else" statement when the assignment explicitly states that you need to solve it with a "for, next" loop because well, the assignment is on teaching you how to use loops then you'll lose serious marks, but this was never a real problem.

But you are right in a sense, the higher up you go the more abstract assignments tend to become in my experience. Instead of "make a program that does so & so using an array" the assignment is more likely to be "build a program that turns the input into this output" and you can go about it any way that works. Lower level courses do have to be more structured to teach everyone the basics & concepts behind programming, else the students can get majorly lost when they get to say, 3rd year code optimization.

[Phil Skayhan]

The professor I had gave us the choice of Pseudocode or Flowcharts, although on exams we'd be required to do both. His mantra was "document everything." He also mentioned not falling into the trap of writing the pseudocode after the code.

However, if the professor is insisting on one method at the expense of the other, I don't see how that is anything but detrimental to the student.

One bonus for me is that since the credits didn't transfer to UDel and I have to take the class over, I already have most of the flowcharts and pseudocode. I'm still not sure why they didn't carry, the only difference in the class structure is that UDel codes in C++ whereas the class I took was in Fortran.

Oh well.

[ukamikazu]

Hey all!
I think it is fair to say that most of you are are new, young programmers, probably with plenty whoofie of your own and no doubt chomping at the bit for a challenge and some real experience. I just want you to remember that long ago you had to learn to crawl before you could walk.

These are my two cents.

Right now, if this applies to you because you are just starting out, you are being instilled with methodology and theory; A foundation for you to base your future knowledge on. That knowledge must be collected and represented in such a way that others can derive meaning from and at some point become executable code. Regardless of who or what the reader be.

Pseudocode, I agree, seems a bit trifling but, it allows you to focus on the algorithm itself without regard to any particular language at the moment, which is what you should be learning just as passionately as any other programming language. It is a way of solidifying your thoughts and a key to your documentation which you must be fastidious in.
Like an artist's sketch or a writer's rough draft.
Think of it like trigonometry or calculus: No one memorizes functions or integrals or every little thing that could happen, but you have basic things you can use like the chain rule, expansions and transforms, as well as identities that allow you to take any problem and determine a solution and a proof (if there is one). Some of you, if you haven't already may have already taken, Calculus II and have probably realized that is about all the math you'll ever need to express just about anything in Computer Science or Engineering. Rely on the theorems, the identities and the proofs. Know your algorithms. How you execute it (i.e. the code/language/proof itself) is up to you and whatever elegant solution you can logically surmise.

In the mundane world, really high level pseudocode is greatly appreciated by programmers working from specs. It is a way of condensing your wishes into something that can be quickly scanned, altered, experimented with and commented on, from your hackers point of view that is. That, and it also protects the programmers hubris by just telling her what you want (with great efficiency) without telling her what to do. They really hate that. This happens a lot with typical spec writers. Source of a lot of hostility and lost productivity.
And it can win you brownie points with your programmers which is always a bonus.

In the end, pseudocode can even save you some time by not being too specific. For example, many general text books and how to's use pseudocode because different people use different programming languages. Some may only know one, while others dozens, but no one knows them all, and if it is just describing, say, a simple hash table, why take up the space to show examples from so many languages, when they can just write some good pseudocode (or just the algorithm from one of Knuth's books even) and let either the individual programmers think of their own solution, or just allow the professor to make it into that days exercise/lecture/lab for whatever language he is specializing in that day.
It is much easier to create a mistake on paper and fix it then to have to hunt down various snippets on an already massive CVS development tree, or worse yet, hose up a production system by doing some just-in-time compiling without the benefit of notes and a great deal of impatience.
I learned that last one the hard way...

In short, give it time, give it a chance, don't be obstinant and get used to it because it really does get better eventually.

[Dooey Jo]

The only time I really use psuedocode is when I'm going to do complex algorithms and such things. Whenever I write a simple function or something that pretty straightforward, there's no need for me to write psuedocode since I already know in my head what I want the program to do, and how I want it to do it. Writing psuedocode for it would just be a useless waste of time because I wouldn't use it later anyway.

And I, too, hate it when you have to turn in the psuedocode!! I did just that yesterday and I made the mistake to write it before I wrote the program itself. That means I can't do anything which is not documented in the psuedocode. That really sucks!! And the teachers never tell you how they want it! I wrote mine as comments, which I later used in the real code. That was probably the wrong way to go...

[tharkûn]

I only do programming when I can't pawn it off on someone else; with this in mind I have found pseudo code to be quite useful. When I don't know the language it is eventually going to be coded into, psuedocode works just fine. Given that some of the datasets will be crunching for weeks; I much prefer to write some higher level conceptual crap than actually doing the coding and optimization myself. RISC sucks.

For every programming class I ever took I never used psuedocode because either I made a real flowchart or I just coded first and then wrote everything else up once I had a useable program; but then I never got to the upper levels.

[GrandMasterTerwynn]

The only place pseudocode has any use is when you're trying to explain to management types how your design works in a 400 slide Powerpoint presentation at a peer review because your company has instituted anally insane design process and your program is too new to have snuck in under the old way of doing thing.

And even then, flowcharts look prettier on Powerpoint slides.

[InnocentBystander]

I'm now on my fifth CS class and I have never had to write a single line of pseduo code, so I can't really comment on writing it. However, my professors often write it during/for lectures and I have to say, from the point of view of the reader, its not bad. It gets the idea, the algorithem acorss, and the basic structure across clearly. I can't really see any pupose for writing it for a homework assignment, and thankfully all my homework assignments are graded by TA's who really couldn't care less, and taught by professors who shouldn't be allowed within 100 meters of a lecture hall.

[Slartibartfast]

Yep, pseudocode and flowcharts are for slide shows. Real Men (TM) (and Women, I guess) code directly into the language.

Besides, today a lot of programming is done as events (what happens when I push this button) instead of a neatly defined loop of commands.