
A Paper Algorithm Notation (2014) - kick
http://canonical.org/%7Ekragen/sw/dev3/paperalgo
======
carapace
I've found Joy to be a really interesting and useful notation.
[https://en.wikipedia.org/wiki/Joy_(programming_language)](https://en.wikipedia.org/wiki/Joy_\(programming_language\))
[http://joypy.osdn.io/notebooks/index.html](http://joypy.osdn.io/notebooks/index.html)

The syntax is enormously simple (the only keywords and '[' and ']' for
quotes), the semantics are elegant, and implementation is trivial[0] It seems
to me to combine the best aspects of Forth and Lisp.

In working with Joy, I've come to suspect that elaborate syntax, and the
parsing thereof, is a kind of _MacGuffin_ :
[https://en.wikipedia.org/wiki/MacGuffin](https://en.wikipedia.org/wiki/MacGuffin)

> ... a MacGuffin (sometimes McGuffin) is an object, device, or event that is
> necessary to the plot and the motivation of the characters, but
> insignificant, unimportant, or irrelevant in itself.

[0]
[https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/...](https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/thun.pl)

Work-in-progress. That code does evaluation, type-checking, and type-
inference; and there is a start on a compiler to machine code as well as some
meta-programming tools. All in 52 kilobytes, more than half of which are
comments.

Compare and contrast with [https://git.sr.ht/~sforman/Prolog-
Junkyard/tree/master/typet...](https://git.sr.ht/~sforman/Prolog-
Junkyard/tree/master/typetype/FormalKnowledge.pl)

> A simple language with semantics based on the language and code from "Formal
> Methods: A First Introduction using Prolog to specify Programming Language
> Semantics" by Lutz Hamel. Lexer, parser, evaluation function.

~~~
kick
Ha! I was waiting for someone to mention Joy! You can find a bunch of stuff on
Joy hanging around if you know where to look:

[http://nsl.com/](http://nsl.com/)

[http://archive.vector.org.uk/art10000360](http://archive.vector.org.uk/art10000360)

[https://vector.org.uk/conquering-
recursion/](https://vector.org.uk/conquering-recursion/)

It's a neat concatenative language, and everyone reading this thread should at
least give it a cursory glance!

NB. Joy is a bit more APLJK-inspired than Lisp-inspired.

~~~
carapace
Yeah, sometimes I feel like a broken record here on HN: certain subjects pop
up and if I see them I'm almost guaranteed to mention certain other subjects.
But then again, there are always people who haven't heard about <FOO> yet, eh?

------
MrEldritch
See also APL, which was designed as a concise algorithmic notation first and
only adopted as an actual language afterwards. (Hence the use of custom
symbols)

Although unlike this notation, APL is more _typewriter_ -optimized; many
symbols are made by double-striking two other more basic symbols, and the
typesetting is simple and linear - it clearly doesn't take advantage of the
full expressive power of handwriting. (Plus, its array-based programming flow,
while extremely powerful, is very different from the way most people write
algorithms these days)

~~~
alexjm
Older APL programs used a 2D layout to show control flow, which probably
worked well in handwriting but not so well once APL started being used as a
programming language, rather than as a notation for specifying a program to be
written. This page has some examples:

[http://www.zerobugsandprogramfaster.net/essays/5b.html](http://www.zerobugsandprogramfaster.net/essays/5b.html)

~~~
eternalban
That page deserves its own hn submission.

------
samatman
For a language optimized for pen and paper, `z.@re` seems verbose, when one
could use either `z.re` or `z@re` to describe member access. I notice that
later on the page he drops into the more obvious notation l.next for a linked
list member.

This one may be cultural, but when I write math (including pseudocode), I use
× rather than ⋅ for ordinary multiplication. This is 100% a matter of habit,
but also it's too easy to mix up ⋅ and ., at least in my handwriting. Dot
product I write with a small open circle, ∘.

The ← for assignment is good, but I wish it was used consistently; elsewhere
we see =, and then == for equals, which is totally unnecessary in handwriting
if one has adopted a distinct symbol for assignment. ↑ for returns is alright
though I'd probably write it →, but this is a minor aesthetic judgement call:
I like the symmetry that i ← double(x) could expand to i ← (λ(x) → x × x)(x).

The actual meat of the article, starting with loops and conditionals, is good
stuff. I wouldn't understand it if I just saw it written out, but it beats the
pants off UML-like bubble diagrams, and I don't expect it would take much
exposure to render it familiar.

~~~
kragen
I'm glad to hear your thoughts! I have a great deal of respect for your
technical judgment.

There are definitely errors in there. Some are inconsistencies as I
experimented over time. However, the distinction intended to be expressed by
=/← is the distinction between initialization and mutation. I might have
gotten it wrong sometimes.

In the case of UML-like bubble diagrams, have you looked at Alloy?

~~~
samatman
Aha, that makes sense (the initialization and mutation, that is).

It probably won't surprise you to know that I would scribble a := there; `==`
is one of my least favorite of the tokens we've inflicted upon ourselves as a
profession. Certainly it's good to draw the distinction between initialization
and mutation.

Although as an _immutable_ initialization, `=` is correct as an equation as
well... hmm.

I wasn't familiar with Alloy, but I'm about to be. I've clobbered a few things
together with PlantUML, and don't have any use for a diagramming system that
doesn't have a canonical textual representation, which it appears Alloy
does... it appears Alloy does rather a lot, actually.

My goodness. This thing has a SAT solver strapped to the side of it. I did not
see that coming.

------
a-saleh
This was one of the reason, I started looking at APL, to be able to write code
better on paper.

And a reason why I like applicative programming in haskell with all of its
squiggly <$> and <*>.

Another interesting idea might be to look at TLA+, because it reminds me of
the way I used to scribble out basic ideas for physics simulations, i.e
distance with accelerating velocity:

s' = s + v /\ v' = v + dv

------
galaxyLogic
Pseudo-code I think is like "sketching" an algorithm. It doesn't have to be
precise it just needs to produce a "picture", the big ideas, that give us the
characteristics of the algorithm being described.

Thus pseudo-code makes it easier to understand an algorithm. It should be
intuitive, like a picture, so it is trivial to understand what it depicts.

I've often wondered why algorithms are described in pseudo-code and not in any
actual programming language. The above is my best answer so far to that
question.

------
dang
A thread from 2016:
[https://news.ycombinator.com/item?id=13286503](https://news.ycombinator.com/item?id=13286503)

~~~
kragen
Oh hey, thanks! I didn't see that in 2016.

------
einpoklum
> That may be easier to read, but which one would you rather scribble on a
> whiteboard or a napkin?

The one that's easier to read. And easier to remember.

------
fhars
Am I misreading his notation, or did he get FizzBuzz wrong?

~~~
samatman
I think you're right, the "Fizz" and "Buzz" conditions need an = 0 if we're to
assume the expression on the right executes when the condition is true.

~~~
fhars
Ah, no, I have been reading it wrong, the code is correct: given the "i % 3 ∧
i % 5" in the first case, the "i % 5" for the "Fizz" case is effectively an "i
% 3 = 0". Clever. Readable? Maybe.

~~~
kragen
Right, multiples of 3 print "Fizz", and multiples of 5 print "Buzz". It would
be clearer to pattern-match on the tuple (i % 3 == 0, i % 5 == 0), or even (i
% 3, i % 5), but at that point I haven't introduced pattern-matching.

------
beagle3
APL is well thought out, battle tested and IMHO a better system. It comes with
vector semantics, which simplify a lot of things - but you don’t have to use
them.

~~~
kick
I use APL daily; I still think Kragen's notation is worth a look. It's
important to examine alternative approaches!

~~~
kragen
Hey, maybe you can help me get APL into my brain? I've been trying to jam it
in there for years and it still doesn't fit.

~~~
kick
Happily! Have you tried out J's labs? That's what I usually recommend, just
because of how varied, deep & consistent they are. If you have, and they
didn't work for you, I'd ask if you've read _J for C Programmers,_ which is a
useful book if you're having trouble with the paradigm overall.

J is in an interesting spot because it's a bit more complicated than K
(though, I'd argue, less complicated than modern APL2, which won out), but has
learning resources that actually help you get a feel for the language.

And of course, check out idiom libraries, they sometimes help to make things
"click."

(J Labs can be found in every J install; there are some pieces that only work
when you have Windows, but overall they work anywhere a computer can be found,
and the ones requiring Windows aren't really essential to learning.)

Just ping me if there's anything else!

