1. 11

  2. 2

    This is an interesting idea, but there’s a reason C-style syntax is so dominant in popular programming languages today. The difficulty of learning something new is proportional to the distance it lies from concepts you already know.

    So while this might be perfect for dense algorithms papers or folks who already have strong math backgrounds, it doesn’t seem worth the effort involved to learn for most industry engineers.

    Almost all my attempts to convey code fall into a few well defined categories:

    1. Code review. In which case I’ll either suggest edits to the code or in cases where I want to showcase a different design approach, provide a patch demonstrating the suggestion.
    2. Data Modeling. This is mostly the art of drawing boxes on a whiteboard.
    3. Whiteboarding actual code. I just use Python in these cases as it’s almost universally understandable (even if you don’t know Python!). I interview in Python for the same reason, despite rarely using it day-to-day.
    4. Writing design documents. This is where I’d think this would really shine, but I have never actually written a design document that’s more focused on the algorithmic solution than on explaining the problem and the tradeoffs that led to the solution that’s going to be used.

    Has anyone used this or similar shorthand systems? What are your experiences?

    1. 4

      I use a hodgepodge of mathematical symbols, Z notation, and J when writing stuff by hand. I’m writing for just myself, to get my thoughts in order, and the terseness helps a lot.

      1. 1

        Interesting, I’ve never heard of J before. Do you use it as a primary language?

        1. 2

          More as a hobby language, it’s just that being able to write \: list instead of sort_descending(list) is pretty nice!

        2. 1

          Funny you say J, as a Forther a lot of my scratch notes are Forth style. Just goes to show, one likes to program in ways one likes to think.

          1. 1

            one likes to program in ways one likes to think.

            Hence my tendency to write much of my code as if I long for it to be Lisp. Because I do.

        3. 1

          If I’m following the examples correctly, then there’s a bug in the FizzBuzz algorithm.

          When I do this type of stuff, I will generally use a pseudo-C type language—braces for blocks, and will sometimes skip variable declarations if it’s obvious. I might even flow chart a bit.

        4. 1

          The 2D aspect reminds me a bit of Plankalkül, that’s quite interesting looking into.