Anyone else find pseudocode weird, counterintuitive, etc.?

Post Reply New Topic

As I have studied programming and computer science over the past few years, I have repeatedly read (and been told) that I should try to write out a problem in pseudocode before coding it in a specific programming language. I have attempted it, but I often end up doing it in an actual programming language, anyway.

To me, the idea of pseudocode is kind of weird. The whole idea of "general, abstract, language-independent" just doesn't make much sense to me, except at the level of specific algorithms (sorts, searches, etc.). I find it counterintuitive to think about the problem independently of language-specific features:
-Object-oriented, procedural, functional, etc.
-Compiled or interpreted
-Libraries (of functions, objects, interfaces, etc.)
-Form of persistent data (SQL, XML, JSON, etc.)

At the end of the day, either the language allows a line such as "objectName.methodName();" or it doesn't (and you, therefore, have to accomplish the same thing in a more roundabout way).

Anyone else feel this way about pseudocode?

It depends on how the pseudocode is written. In most cases, it's fairly easy to translate pseudocode into Java or C#.

I'd say pseudocode is meant to serve the programmer instead of constraining him. When I need to write something I end up doing it in Java because it's the language I am more familiar with, while taking liberties on the syntax as long as what is going on is still understandable. Especially if it is not meant to be shared as in your example; why make an effort to write in "pseudocode" if it won't give me any special insights and writing in proper code is much easier anyway?

In the algorithm design class I must use GCL all the time. It can be annoying,

I always thought pseudo code was used only by UCSD p-system (shows you my age!), let alone Java.

When I was in grad school, taking a course in introduction to computers (since information science was beginning to take over from traditional library science in the 1980's), whenever an programming assignment was given, we had to flow chart the logic of that program. Once we had the logic flow charted, we then wrote the code and had to document the living daylights out of all the code written.

I don't see PseudoCode as exlusively for PrePlanning.

I think it can be practical to include it while during the actual programing. Well, in my limited experience, leaving # comment lines in Bash Shell scripts.

This isn't so much for pre-planning as it is for staying organized or especially troubleshooting.

I can relate to what you're saying though because I'm trying to tackle MySQL next and the teacher's style emphasizes pre-planning and design before touching any command line. I mean c'mon, at some point I need to get into the CLI to understand the program. I see no harm in screwing up or wrecking a table and having to fix it or start over.

It's interesting that you should say that. I've never found pseudocode particularly useful either. Code for me is more like a sort of a sensation of structure. Writing it out in English feels nasty and unhelpful.

If I'm stuck I might do a little sketch, but it's typically just a few dots, circles and lines.

Okay, I get it now. Time for a pro-tip: build the db, then sweep back through & document the data definitions [and logic.]

You can even use any of the open-source data visualization tools to help in the documentation process.

I remember one pseudocode example which looked suspiciously like Python

The times where I need something very abstract I end up either using GCL or a mix of Java and Python clear enough anyone should understand. Sometimes a problem is hard enough I draw graphs of what's going on, and in some cases I use mathematical notation.

Psuedocode is a waste of time. I found an outline to be more useful.

You can't convert it into the language of your choice. Try taking some non-trivial pseudocode and converting into Ruby, Erlang, Prolog, Java, Haskell, Befunge. Languages are different. A simple thing like a looping construct has no direct equivalent in Prolog. In Erlang you would solve many problems with pattern matching. In Java, you'd create a bunch of object factories. In Ruby, monkeypatching. In JavaScript you'd come up with some elegant solution involving closure.

The solution, and the pseudocode are impacted by the architecture and the environment.

Human language is elegant, but it's an ugly fit for code. No one writes pseudo-maths.