
A Paper Algorithm Notation - akkartik
http://canonical.org/~kragen/sw/dev3/paperalgo
======
beagle3
Everything old is new again

Ken Iversion originally designed APL as exactly this - an algorithm notation,
then it was noticed that -- since this was well specified -- it could actually
be executed. I urge anyone who finds interest in this to read Ken's "the
description of finite sequential processes"[0], especially the description of
the simplex algorithm[1], which is perhaps the most elegant I've ever seen.

I am actually surprised that kragen did not mention APL more, as I know he is
familiar with it, and he is usually pretty good about giving credit where
credit is due.

[0]
[http://keiapl.info/eemcd/keisimplexpages/keisimplex447.html](http://keiapl.info/eemcd/keisimplexpages/keisimplex447.html)

[1]
[http://keiapl.info/eemcd/keisimplexpages/keisimplex452.html](http://keiapl.info/eemcd/keisimplexpages/keisimplex452.html)

~~~
groovy2shoes
Lisp was designed in the same way. As I recall, it was Steve Russell who
demonstrated that it could be implemented on machines of the day.

------
riazrizvi
I don't see the point of precise handwritten software notation. Pseudocode is
a thinking tool because of its ambiguity and looseness. We need to process
problems in a number of passes of increasing precision and correctness, so we
want to start with something that is more vague than a programming language.
When we are ready for precision we can write the code, using encapsulation to
manage how much of the problem we bite off at a time.

Also the point about pseudocode being unnecessarily cumbersome is not true
IMO, because we don't need to adhere to any language syntax that we find
redundant. I've never seen an audience to a whiteboard script complain about a
missing colon or self/this keyword when the human context made it unnecessary.

~~~
taeric
I actually have seen folks complain about missing semicolons. Luckily, they
did not take the stance heavily and getting them to discuss it immediately led
them to agree it didn't matter.

I go so far as to say any coding in stuff like google docs can miss items like
semicolons without a bat of an eye from me. Sure, they are typing. But if it
is not their normal coding environment, the aesthetics and finer points of the
language are... superfluous at best for the points I generally care about in
that kind of correspondence.

------
nemo1618
This is really neat! It's fun to imagine what true 2D programming could look
like, unconstrained by bitmap fonts.

I'll state the obvious, though: this isn't going to be useful for the #1 time
I need to code on a whiteboard: interviews. Both parties need to be familiar
with the syntax in order for it to be useful.

Tangentially related: check out these alternative musical notations:
[https://www.quora.com/What-are-some-alternatives-to-
standard...](https://www.quora.com/What-are-some-alternatives-to-standard-
written-music-notation)

~~~
michaelchisari
A couple years ago, I played around with the idea of a "shorthand" for
algorithms, specifically for whiteboard interviews.

[https://github.com/michaelchisari/scrwl](https://github.com/michaelchisari/scrwl)

It was based on shorthand writing systems that emphasize a minimal amount of
strokes, and the ability to continue strokes into each other.

~~~
titanomachy
Did you get around to writing examples? None show up for me.

~~~
michaelchisari
I didn't, unfortunately. Other projects ended up taking priority.

------
argonaut
This seems overcomplicated. Theoretical computer science papers just write the
algorithm in words, using widely accepted mathematical notation wherever they
can (e.g. sigma for sums, set notation, and so on).

~~~
seanmcdirmid
It seems that this isn't for CS paper writing, but for writing pseudocode
during design, which needs much more flexibility than communicating results in
a POPL paper.

~~~
nickpsecurity
Regular pseudocode, formal specs close to programming (eg VDM language), and
graphical stuff like Statecharts worked well in industry for a long time.
Including for high-assurance systems where ambiguities lead to catastrophic
failure. Middle option was advantageous where it was precise enough for tools
to catch errors or prove properties. Any of these worked well enough and
didn't look as weird as OP to average programmer.

~~~
seanmcdirmid
Those are fairly established notations that...when hey first came out, weren't
as obvious as they appear now.

It is unfair to expect that pseudo code notations be static at this point in
history when new programming languages that look "weird" pop up all the time.

------
politician
There is a real need for a concise notation for collaborative whiteboarding,
so I see this as a good start.

I'd even go so far to say that as a notation for interviews, if the candidates
were informed ahead of time, then I can see it working out better than the
current approach for both candidate and interviewers.

At the very least, you could see whether the candidate could _learn_ a new
notation, and that alone is a pretty valuable signal.

~~~
nickpsecurity
"At the very least, you could see whether the candidate could learn a new
notation, and that alone is a pretty valuable signal."

I could see that as a benefit. Much like how they would have to learn unusual
requirements or API's on the job then solve problems with them. A notation
like this and basic specs might be a useful filter.

~~~
anentropic
cruel and unusual :)

------
Avshalom
_COUGH_
[http://www.jsoftware.com/papers/APL.htm](http://www.jsoftware.com/papers/APL.htm)
_COUGH_

------
natch
Clearly there is room for improvement in this area.

But I'd rather see papers include code snippets.

If a widely used and highly readable language is used (Python, for example)
then the meaning of what is going on would be much more clear, and in some
cases could be immediately tested out with ones own data or at least played
with in an existing, widely installed, live system.

~~~
gravypod
I think ideally a psudo-code should be directly translatable into any
programming language. It should be dead simple. It should use all of the best
practices of the most common programming languages. It should be typable.

None of this garvage of arrows and triangles. I'm not Greek, I don't have that
kind of stupid keyboard.

Also, it should follow programming practices for variable names.

Rather then A, B, C, D, X and the lot use forward_momentum or ForwardMomentum.
We're not using typewriters any more. The extra few keystrokes for typing out
words, and not symbols, is well worth it.

~~~
nickpsecurity
Interestingly, exactly how it's done in almost every academic paper or article
on software I've read outside some really niche ones. Plus most prototypes in
industry that were done as UML, Visual Basic, etc. Python got somewhat popular
in this niche as it's quite readable & high-level.

The people downvoting these comments don't represent a majority opinion on
pseudocode in any way. Quite the opposite.

~~~
gravypod
I'm an undergrad and I'm currently working with people in the physics. All of
their code, python or not, uses N, n, and x as the most common variable names.

~~~
nickpsecurity
That is a recurring problem. The structure is easy to follow. Variable names
often suck. I think they get it from their Algebra and Calculus classes
because that was first type of books I saw using those letters almost
exclusively.

~~~
e12e
It's almost as if algebra would also make more sense with better variable
names, rather than simple letters...

~~~
nickpsecurity
It would. Start with the word problem. Define some variables maybe big or
short-hand closer to actual description. Then use algebra with those variables
to model the problem in math. Solve it. Others understand it more easily in
peer review.

Much like programming and code review.

------
happynewyear
Looks like he's got another potential gem here:
[http://canonical.org/~kragen/memory-
models/](http://canonical.org/~kragen/memory-models/)

~~~
akkartik
Oh yeah. That whole site is a gem.

------
nateabele
I think the real question is, why is the amazing interactive simulation medium
that we call a computer so _abysmal_ at capturing and representing ideas
(particularly ideas about _the computer itself_ ) that we have to resort to
inventing a new _notation_ for _pencil & paper_ to deal with it?

~~~
kevinwang
I don't think that's the issue here. It's the verboseness of code/pseudocode
which this solves. The understandingness of code was not raised as a problem.

This notation is not to say that ideas can be expressed _better_ on paper with
this notation, but rather that, in situations where you must use pencil (such
as whiteboarding), code is overly verbose and this notation is less so.

Then again, I do see some benefits of writing this on paper over writing code
on a keyboard, like the flexibility of being able to write wherever you want,
and write notes or pictures in the margins. But these are minor.

Also I may have misunderstood your comment.

Edit: actually, upon rereading: I guess you were referring to this line in the
opening paragraph

>But our programming languages are very poorly suited for handwriting: they
waste the spatial arrangement, ideographic symbols, text size variation, and
long lines (e.g. horizontal and vertical rules, boxes, and arrows) that we can
easily draw by hand, instead using textual identifiers and nested grammatical
structure that can easily be rendered in ASCII (and, in the case of older
languages like FORTRAN and COBOL, EBCDIC and FIELDATA too.)

which is an interesting thing to think about. So I guess your criticism of
modern computers for representing ideas is valid. But I suppose the advantage
of the more restricted inputs of a computer (keyboard into a 1d string of
ascii text) is the structure that it inherently has, that paper and pencil
does not. So there are tradeoffs.

------
agumonkey
Reminds me of notation used un Old Lisp books (queinnec).

Personally I find ml to be much of what concise and unambiguous hand notation
should be. Probably why I like it.

------
grogenaut
minor nit but this feels very much like it was designed by an academic in that
I think you could do this in latex very easily but not at all in a standard
text editor. Those horizontal and vertical lines. But otherwise you need a
specialized program or a whiteboard to pull this off. Also all those math
symbols. I don't know where those live in my input.

------
kutkloon7
Hm, I thought the point of pseudocode was that it is simple to write down, and
everyone understands it.

This misses both of those advantages.

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

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

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

