StarDestroyer.Net BBS

I don't think there's a single thing about programming classes I hate more than the requirement to hand in "pseudo-code" for a program. I always end up writing that shit afterward anyway, so there's no fucking point to it. I can deal with IPO charts and even structure charts; that shit is easy. But pseudo-code is so utterly and absurdly time-consuming comparatively, adds nothing to my program design process and generally just pisses me off.

Anyone else feel this way, or do you see a legitimate use for that shit in programming courses?

I see a use in pseudocode for explaining algorithms or concepts, but that's it. Fortunately my AP CS teacher doesn't require us to do any of this, though my summer school regular CS teacher was very anal about "planning".

Pseudocode has it's uses, espically if you don't know the exact syntax of a command and whatnot. (Although I can make an effort to fix that as soon as possible.)

I do agree that having assignments in which you're supposed to turn in the pseudo-code itself is useless though - for most assignments I simply can write/type code that would work as is.

As for planning, that annoys me as well. It's too much like being forced to think other people's thoughts.

Pseudocode is alright if the instructor makes it clear how you're supposed to lay it out. I've handed in lots of homework using pseudocode only to have the prof say "this isn't pseudocode" and "don't use real language code". Usually they don't let you know wtf they really want.

Useless garbage.
It's best to program straight into assembler.

It can all go to hell. If I need to plan out some code (which is rare, as I vastly prefer to be actively coding, compiling, fixing, recompiling, etc), then I will do so. Too many programming teachers are hellbent on making their students conform to their exact methods of coding, whether or not said methods are effecient. Commenting requirements I can at least understand, as they do tend to make code more readable, but comments can still go to hell.

I usually just make a quick flowchart or block diagram (for large programs) when programming something complicated.

Pseudocode, for me, is redundant. Instead of pseudocoding, I first write out a handful of comments in the program body, and then fill in according to those comments. So the comments kind of become the pseudocode.

And contrary to opinion, unless you think and breathe assembly language, you should at least have a translatable framework (whether written in a high-level language, pseudocode, or flowchart) before you start coding. Writing assembly without an established idea of what you're doing is pretty much a bad idea.

I got a bad grade in assembler because I didn't put a single comment. Stupid teacher, anyone could have seen what it does just by looking at the code.

I sometimes find it useful if I'm set a problem (say a complex algorithm) I can't just solve in my head straight off, but that hasn't happened often (more to do with the lack of academic rigour of the course than my ability, unfortunately).

Pseudocode is nice when you're starting out. But being *required* to write it, I think, is utter bullshit.

Pseudocode is useful for describing a specific algorithm without having to write it in a specific language.

YES YES YES YES YES

I HATE it. If you want to describe an algorithm, use a flowchart, pseudocode serves no purpose, it is bullshit. Waste of my time.

Don't mind it, probably as I've never had to use it. We got told what it was, and were shown a few examples. After that it was left as "use if if you want".

I hated it last year, i mean, why bother to not write the accurate coding? Silly nonsense.

Rye wrote:I hated it last year, i mean, why bother to not write the accurate coding? Silly nonsense.

Because in pseudocode you don't have to deal with annoying special features of a specific language...

And I never saw anyone trying to explain an algorithm in flowcharts...

The issue is; once you are down to coding a single routine, writing the pseudocode is a waste of time.

Before you write a routine, it should have 1 planned purpose, and you should have clear understanding of the algorithm it might need to uses.

Most routines should be no more than 100-150 lines of code in C#/C++/C/Java/etc. Which is generally one screen of code.

If you are dealing with maths, you should have worked it out on pen & paper long before touching the code. Computers are horrible for doing quick & dirty symbol manipulation, which you need todo to manipulate the maths into a form which can easily be encoded in code.

How it does it is not really important, its the required output based on the provided input.

I use psuedo code for documentation purposes, since I never comment (grin)

We were required to turn in psuedo-code for every project during the first 2 Java classes we took. After that, it wasn't required. Seems like a very backwards policy to me. When you are writing a program to accept a Length and Width of a yard and return the length of time it takes to mow given a mowing speed, you don't need any algorithm. Psuedo-code does come in handy when you are writing much larger programs stretching across multiple classes, however.

My big problem is that each instructor has special style preferences. For example, mine prefers it to look shoddy and unprofessional. Her examples are pseudo-code with shitty-looking lines connecting certain portions. When I go through the trouble of finding a LaTeX pseudo-code style file and using it to make something at least somewhat resembling professional, I get all points knocked off for it.

And frankly, the first run of the code I try and compile resembles pseudo-code very much anyway. It's syntactically incorrect and doesn't compile.

This remembers me of a joke:

At a programming course, the assistent is called by a student:
"My programs runs, but it doesn't do anyhting."
The assistent looks at the code, eyes widening.
"But you have all the code commented"
"Yeah, but it was the only way to get it compiled."

I can't recall ever having been required to turn in pseudocode, except maybe when covering pseudocode itself...

I use pseudocode or some other method of planning when I need it, but usually I don't need it for assignments.

I just handed in Pascal code. It looks just the same.

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.

I don't find much use for it, but its not so stupid as, say, the enviornment model. When I've had to turn in "Pseudocode" my TAs didn't mind actual Java, so I guess I'm in the same boat.

Slartibartfast wrote:I got a bad grade in assembler because I didn't put a single comment. Stupid teacher, anyone could have seen what it does just by looking at the code.

I hope you're joking there, but I'm not sure.

aerius wrote: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.

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.