Anyone else find pseudocode weird, counterintuitive, etc.?

Post Reply New Topic

For me, Pseudeocode means writing it in whatever programming language I or thepeople I want to convey the idea to are most comfortable in, but relaxing the rules of syntax etc., sort of being intentionally sloppy or lazy if you will.

I totally agree with this, and nicely put.

As a 20 year (or more? I lose track) career and hobby programmer, I have never found it easier to express a program in English or any other pseudo-code before translating that to whichever destination language. Writing directly in the target language works fine for me, and pseudo-code is just an annoying detour, mainly because I think directly in whatever language, and have to translate it back to English/pseudo-code if someone wants some from me. I do not think in English or any other human language when I am coding. That being said, the one thing I do find immensely helpful are editors which have good syntax coloration and highlighting, so the elements of the language are more easily glanced out of the jumble it would otherwise be in monotone. Also I find an IDE very helpful at speeding things up as auto-completions or syntax checking and other assistance almost makes what you actually have to type much more short-hand and almost pseudo-code in itself. Some even have a template sort of system so when you begin entering a common structure (like a function call, or object definition) it will automatically create the closing parenthesis/brackets for you so you don't have to worry about it.

I find pseudo code no "weirder" than a formal program in some programming language.

In fact, as a mathematician I deal with proofs that are not written on the strict formalism of a logical calculus but are expressed in a well understood subset of natural language. A formal proof of most mathematical theorems would be extremely long and the detail would obscure the underlying idea or theme of the proof. Likewise, a good concise pseudo code of the algorithm expresses what the algorithm does without getting tied in in the minute details of a particular programming language.

Never let syntax get in the way of semantics.

ruveyn

My experience is 100% the same and has been for most people I've worked with. People who express enthusiasm for pseudo-code are the sort who see programming as an intermediary stop on the way to something more "fulfilling".

For a long time (through sometime in the 90s) it was usual on US government contracts to require pseudo-code (called PDL at the time). Typically, to meet the requirement, people wrote the PDL after their code was working. This practice was known as "PDLing" one's code.

I've experienced a number of different levels of pre-code levels, and they all have their uses.
There's Unified Modelling Language diagrams, which I'm surprised nobody mentioned. I was forced to use this in my grade 12 programming course. It was a pain in the ass (especially since the teacher wouldn't let us start coding until he OKed the UML model, but I can see it being useful for megaprojects. For the level I'm working at (strictly amateur - for me, if it has a GUI and it's not VB, it's pushing my limits), it's absurd, but I suspect my preferred method - flowsheets - are not sufficient for an OS project or creating game engines like Valve's Source. UML includes a flowsheet, but it's a heck of a lot more sophisticated (and constrictive) than what I'm referring to.

For me, flowsheeting could almost be considered pseudocode. It's a list of things that need to happen, in the order they happen, usually in the form of a text file, rather than UML's formal infographic style. Very general for easy stuff "load data from config file" and more specific when it's an algorithm that I have trouble wrapping my head around. At this level, I can communicate the idea to other people.

For me, pseudocode is what I use when I'm having trouble and don't want to break the flow. For instance, testing if something is not in an array, I'll type (variable) not in (array), then look up how to do that efficiently. I'm just switching over to Python and had to look up how to do that efficiently earlier today. ("Oh, hey, my pseudocode is apparently actual code in this language").

Commenting, on the other hand, is important to have. Most of my programming was for school work, so I've developed a habit of wrapping up programming sessions with liberally commenting the work I did. (The one time I did that, I spent the entire 2 hours I had in my next session just deciphering what the hell I had been trying to do in the previous session, ended up spending most of the time commenting half of it and redeveloping the other half.) Plus, it makes more formal documentation (which I'd always thought was supposed to be at the end, since the original plan never works perfectly, and documentation is supposed to reflect how it actually is) way easier.

Pseudo Code gets to the heart of the algorithm without getting tied up with the syntactical peculiarities of a programming language. It is better than flow charts. A combination of bubble charts to show data flow and pseudo code to show the logic is a very effective way of programming.

ruveyn

haha, well, i think good pseudo code should be like like this:

http://en.wikipedia.org/wiki/Proof_without_words

the point of pseudo code, i think, is actually that you don't think in english while coding! if you are anything like me you solve a coding problem by coding it. most of the time i solve a coding problem before i understand how i solved the problem. i think understanding "how" is very important because it helps you do it better in the future and it helps you translate it to other languages. for instance you might write an algorithm, write out in english how it works and then later when you are better with the language realize a better way of implementing the ideas documented in the pseudo code. you might have another problem to solve and find out it turns into much of the same pseudo code, so you can re-use those elements.

i only code for my own personal projects and most of it is the same ideas re-implimented in different ways...so yeah i guess i don't see the code as the end result, but what the code does.

getting too specific too soon with pseudo code i don't find helpful. it'd be impossible for me to get pseudo code right without actually implementing it in the language. i think you should try to abstract any language dependent explanations to a higher level and go back and fill in the blanks from time to time as needed.

there is a programing quote i like that says "A language that doesn't affect the way you think about programming, is not worth knowing." if pseudo code wasn't awkward and didn't take effort it'd be a waste of time, i think. anything i can't cross translate into natural language i find is a good area to work on in the programing language because i don't understand it well enough.

i don't think pseudo is the greatest word to use though. i don't think of it as "fake" code. i think of it as instructions that if you implement in any language will get the results you want.