3 ms·
Hey, that is quite cool. :) It looks like Plankalkül [0] or early blackboard APL [1]. The 2D notation is probably a problem, but it is always cool to see new ta
by mlajtos 5y ago
Hey, that is quite cool. :) It looks like Plankalkül [0] or early blackboard APL [1]. The 2D notation is probably a problem, but it is always cool to see new takes on this problem.
[0]: https://gregorias.github.io/2014/11/22/early-high-level-programming-languages.html https://gregorias.github.io/2014/11/22/early-high-level-prog...
[1]: https://aplwiki.com/wiki/Iverson_notation https://aplwiki.com/wiki/Iverson_notation
- kragen 5y agoThanks! Why do you prefer 1-D notations for paper programming? I think of the second dimension as being one of the primary advantages of using a pencil rather than a keyboard: on the keyboard it is awkward to move around but it is easy to spew out thousands of characters, while for the pencil the situation is precisely reversed. Thank you for linking me to Grzegorz's post, which is a much better explanation of Plankalkül than I'd seen previously! I just celebrated Zuse's birthday on Tuesday. I jotted down his TPK example in paperalgo and found that it was about 64 symbols (characters and non-character lines), about a quarter the size of the Plankalkül version he gives†: https://ibb.co/4YpdYnD https://ibb.co/4YpdYnD But there are definitely some real parallels: the horizontal bracket for the loop and what I take to be the tabular condition-consequent-condition-consequent representation of conditional logic, with each consequent to the right of its condition, and of course the use of subscripts for array indexing. It is a peculiar combination of the comfortable and the rebarbative—why A9 or W2, for example? ______ † If we count by non-whitespace characters, it's a bit over a third the size of his Python, too.
- mlajtos 5y agoWhile I understand why 2D is objectively better choice for expressing algorithms, I believe 1D is better suited for our minds. 2D is just hard to parse. You don't know where to look and how to proceed. With 1D you start in the upper left corner, and there is only one direction to follow. Less is more. I read what you have wrote on paperalgo and I like it a lot. It's terse and thought out. I think pattern matching makes more sense than conditionals and looping, but it is easier to transliterate it from different languages. ↑ from Smalltalk just feels right.
- kragen 5y agoInteresting, I usually think of code as being easier to parse when it's laid out in 2D like this: enum { size = 8192 }; int main() { char *n = "tmp.mmapcrash"; int f = open(n, O_RDWR | O_CREAT, 0666); if (f < 0) err(errno, "open: %s", n); for (size_t i = 0; i < size; i++) { if (write(f, "x", 1) < 0) err(errno, "write"); } .... rather than in 1D like this: enum { size = 8192 }; int main() { char *n = "tmp.mmapcrash"; int f = open(n, O_RDWR | O_CREAT, 0666); if (f < 0) err(errno, "open: %s", n); for (size_t i = 0; i < size; i++) { if (write(f, "x", 1) < 0) err(errno, "write"); } ... Are you saying that your experience it's the other way around? Pattern-matching makes some code a lot easier to express and understand, but it's true that there are some languages where you end up having to kind of hand-translate it into a nest of conditionals and whatnot. It's kind of mindless work, though, so I don't really feel like I'm missing anything important in the pattern-matching representation of conditionals in paperalgo.