> The purpose of using pseudocode is that it is easier for people to understand than conventional programming language code, and [...].
So in common usage, "psuedocode" is supposed to be easily understood. I imagine that that isn't one of the goals of this new notation, though. It looks more useful for internal use (e.g., within your team) than external use (e.g., a whiteboard interview), since it's basically unreadable if you haven't seen it before.
All notation has a learning curve, PHBs won't just be able to understand them without putting in some effort.
Far as a learning investment, that's true for any precise notation, modeling tool, or formal language. Even English takes Americans years to learn. So, pointing out pseudocode has a learning curve like everything else doesn't invalidate my claim that it reduces detail to aid understanding and by many people.
Note: Im also not arguing group-specific pseudocodes cant be developed. Only that the normal kind is meant to be accessible and usually is.
So, what is "the notation that everyone can read?" Since you've claimed that it exists and is well defined, it must be describable. Surely, it isn't because this notation is different and everyone doesn't like different things?
I guess you just don't like new things, it makes sense now.
Now, the OP designing a new method for perceived benefits is fine. I even encourage experimentation. That's a different topic. I haven't even responded to that one that I recall. I was countering misinformation about common pseudocode. Discussing OP's would require me actually using it on a number of problems along with diverse set of others with a meta-analysis of reported pro's and con's. Obviously haven't done that... ;)
Does that seem on the right track? I don't mean to put words in your mouth.
1. Private exploration as you said.
2. Publication of algorithms in a form most will understand and be able to duplicate.
There's an example of 2 on the front page right now:
https://arxiv.org/abs/1610.08129
In the PDF, they describe their algorithms in pseudo-code that combines the common, BASIC/ALGOL-like text with some common notation (i.e. division) from math. I immediately understood the algorithms enough to implement them myself in about any language without soneone telling me what the notation meant. A common effect of published pseudocode since it's intended to be widely understood.
This new notation Id have to think about and practice with. Just using it in a paper with the label pseudocode would cause confusion. It's less intuitive in a world of widely-deployed, ALGOL-like notations. Maybe it has benefits worth sacrificing the wide usability but person switching it better be OK with that.
I get the impression that the work here is more about thinking and iterating on paper, not just communicating on paper, which, IMHO, is a very niche use case that most people aren't going to run into. We don't do anything in our C-style pseudo codes but present.
This misses both of those advantages.