The paper doesn’t use psuedocode as I know it. In my experience pseudocode looks much more similar to real code. (According to Wikipedia I’m more used to mathematical pseudocode)
I’ve never been a fan because writing some simplified Python seems better. Or even better, writing Python that doesn’t necessarily follow every syntax rule to a T and takes liberties where necessary to improve readability
It probably depends on when you were taught to code, and what language you learned on/most familiar with.
This is exactly how I learned to write psudo code in the 80’s… We were also diagramming our code back then, with a pencil and paper, using a template.
https://www.ebay.com/itm/294862492558
Kind of like with this thing.Now I usually do a bit of a hybrid, but it also depends on how complicated the programs are. I’ll do some python/comment-psudo-code.
It doesn’t really matter what the process is, as long as it works for you, and doesn’t interfere with collaborating with anyone you work with.
I definitely write pseudocode like this, albeit perhaps with some more shorthand. It’s commonly taught this way too.
I started doing exactly this. Write a bunch of functions, that may end up in different systems, on different machines, even. This allows you to define the interfaces, figure out data dependencies, and so on.
The code may be runnable, just printing out some statements. Then I copy blocks of it to the place where it will belong.
It’s more of a thinking tool, than “actual code”.
I agree. Instead of pseudocode, using a simple language like Python that is pretty understandable seems to be a better way of representing your idea.
I fundamentally disagree with pseudocode and all the arguments made out on this um, paper? It is written by a educator who has seen lots of shitty unreadable student code which is about the only time pseudocode makes sense to write. But even then, if they cannot form what they want in code what makes making them form what they want in words any better?
But spending ten minutes to think out carefully the pros and cons of different approaches to the goal can save you hours of time debugging and refactoring your code later on.
I find the opposite. Spending time writing pseudocode leads to far more time wasting on things that don’t work. One of the biggest problems with pseudocode is YOU CANNOT RUN THE CODE. Not until you have fully finished thinking about it and then converted it to actual code. Only then can you tell if the code even does what you want. No, far better to write a small segment of code and then incrementally build and test it little by little. Then I can verify my ideas are taking me in the right direction and not resulting in some weird behavior due to some broken assumption I made early on.
Incremental development is the way to go. Just test things as you write them. Don’t write the whole program (and then rewrite it again in an actual language) before you ever even run it. Write a small bit, test it, refactor and continue. You cannot do that with pseudocode and it is vastly harder to debug something that is complete rather than incrementally checking it at every stage as you progress.
Pseudocode makes low-level design reviews easier and reduces the need to review the code itself.
No, no it does not. You NEED to review the source code to see if it does what the person thought it would do. This step cannot be skipped. So what value does pseudocode add then? The code should be readable enough on its own without basically doubling the amount of lines you need to read. Plus NO ONE READS COMMENTS. This comes from 15+ years in the industry. More often then not I see comments that are out of date and no longer describe the code they are talking about. It is a lot of effort to keep comments in sync with code and not worth the effort. There should be no pseudocode comments in your code at the review stage.
Pseudocode supports the idea of iterative refinement
Iterative refinement is vastly better when you get feedback on what you have written. The best place to get that is to run the code and see what it does (either manually or via testing). You cannot do that with pseudocode. Only hope that you can spot a problem, which more often then not you will not. If you write actual code you can run it and see if it fails and how it fails.
Pseudocode makes changes easier. A few lines of pseudocode are easier to change than a page of code
That is a false comparison, why would you only have a few lines of pseudocode and a whole page of code? Surely your psudocode will roughly match the number of lines of actual code? Otherwise what is the point in it and how will it help you spot any problems? You can always write real code as a series of function calls to hide away the implementations if you want a similar approach.
Pseudocode minimizes commenting effort
Not writing comments minimizes commenting effort. Comments should be used sparingly to describe things that cannot be describe in code. IMO the only comments worth while (at least ones that are not doc blocks) are ones that describe external factors. Like “this is to work around this bug <link to bug report>”. Or “we tried the more obvious solution here X but found it caused problems Y” or “this is actually required due to this weird undocumented behavior”. Comments that just describe the code are a waste of time and effort as you now have your code defined twice. Once where people will read in the actual code and once where people will ignore and will slowly rot and worst start to lie. The number of times I have seen a comment contradict the code and have no clue if the code or the comment is right… More often it is the code that is write and the comment is hideously out of date. That just becomes wasted effort trying to figure things out.
With other approaches, design is separated from the code, and when one changes, the two fall out of agreement… As long as the inline comments are maintained, the pseudocode’s documentation of the design will be accurate.
That is a big if there, IF they get maintained. Which they wont. It is far too much effort to edit the code twice. No one wants to do that and so no one does do that. Just read the code if you want to know what the code is doing and reject PRs for code the is unreadable.
The only people I ever see arguing for psudocode are professors that have never worked in the industry and spend far more time reading crappy students code than anything else. I have never seen anyone actually do this in production systems.
Agree.
The only time pseudo code might make sense is in academic papers, where there might be strict page limits. Even then, the paper should link to the actual code. It’s quite often the pseudo code gloss over or even misses important implementation details.
Same reason you write an outline for a report before you write the report.
This is a link to an article that gives reasons
Just summarizing a quick and easy answer
This is clearly written by someone who has never left academia. Writing pseudo code makes little sense in the industry.
Makes sense when try to work through a complex logic flow that you just aren’t sure about.
Nah, if you have some complex logic you are not sure about then you need to see it run to be able to see how it reacts to changes. You cannot run pseudocode so it is far harder to validate it will do what you want it to do.
I guess maybe its my sysadnin coding /DevOps domain that makes a couple of people spit balling on a white board faster to get started then rack and stacking, powercycling, or provisioning new instances.
There is a big difference in planning server layouts and similar tasks and writing pseudocode. In comparason the planning is much cheaper and the cost of getting things wrong can be quite high. But with pseudocode, it is not that much cheaper to write than real code is, it gives you a lot less useful information and the cost of a mistake is quite cheap in code (that is while you are still developing things and for the types of problems pseudocode might even be able to catch).
Agreed it seems like the largest factor is what is cost (both time, effort, and capital) is to run with real data vs tabletopping it. Mapping out unknowns might help if the costs of not catching unknowns is too high.
