Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Everyone understands it" is not a goal of psuedocode.


One of the first sentences on Wikipedia about psuedocode:

> 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.


Yes, but this is not even close to what parent stated.

All notation has a learning curve, PHBs won't just be able to understand them without putting in some effort.


Since it abstracts a programming language and allows for simplified syntax and inline explanations, more people can understand it. Why would you think that's not a goal?


Everyone understands it implies that everyone understands it, regardless of background or knowledge or whether they know programming or not.


Only to the extremely pedantic.


Not pedant at all, I'm sure parent meant exactly what they said.


No reasonable person here would regard "everyone" to include e.g. Sally in accounting. Psuedo code is obviously for people who write code.


He did include sally in accounting below though. This is just the standard anti-new PL rant applied to pseudo code.


Sorry, is this entire subthread an argument about whether "everyone" means "everyone who knows programming" or "literally everyone"?


That's an explicit goal of pseudocode. It's implied by the fact that it's used by both laypersons and programmers to explore algorithms for any sub-field of CompSci or application in IT. It's the level of detail and symbols they modify when targeting specific groups.


It really isn't. Psuedocode is a notation to move design along, to communicate and iterate. It isn't meant for the 6 year old kid or non programming PHB people manager, laypersons if you might say. Psuedocode notations require learning investments just like any other notations.


Perhaps you didnt understand what for everyone means. It wasn't meant literally. It's often used by programmers, even laypersons, as a short-hand for a broad audience. I've seen laypersons write pseudocode and formal specs after training. Many were also taught to use an executable form called 4GL's which still have a lot of revenue and users. COBOL was the first in this since its language let even accountants and such write programs.

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.


Anyone (even lay people!) can learn how to program, anyone can learn math, anyone can learn a formal specification language. I've seen accountants learn and excel at APL, the most obtuse language ever.

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?


The Pascal-looking one in the paper I cited that academic publications and classrooms have used successfully going back decades. Strange you seem so unfamiliar with it.


Yes, pascal makes for great psuedocode because we have a long history with pascal. I am familiar with it, I even ate dinner with Wirth once, nice guy.

I guess you just don't like new things, it makes sense now.


I'm fine with new things. That's another tangent you're on. The original one that started all this was a claim that pseudocode wasn't about broad understanding. The Pascal-like pseudocode that I've seen for over a decade now has been there for familiarity and understanding. Even lay people get it without much work. If they didn't want it comprehensible, they'd be using C language they wrote the code in or who knows what.

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... ;)


Another attempt at articulating what I think is your point: languages have network effects. You're less effective programming in a language if others don't understand what you did. But the notation of OP is intended to not require network effects. Pseudocode is often intended purely to help one privately think through a problem. Even if nobody adopts this notation, it might be useful to you.

Does that seem on the right track? I don't mean to put words in your mouth.


There's two reasons pseudocode is used in most cases:

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.


In the PL community, when we want to communicate an algorithm in a paper in something like code, we will say something to the effect of C-style pseudo code. This serves two roles: 1) everyone "knows" C so you don't have to explain your notation very well, and 2) we will skip over all the ickiness of C (hence the C-like).

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.


I agree with this. The notation might also apply to a smallish group of people, like mathematicians in a certain field who use it to communicate and work together. Notations are powerful like programming languages, if you can reuse an existing one or use ones other people you need to work with already know, there is an advantage to that.


Right. I was focusing on the extreme ends of the spectrum to sharpen the contrast.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: