The "Z" notation is easy to explain, but I think it has practical problems. In particular, even trivial functions end up taking a very large number of lines.

The "Z" notation is easy to explain, but I think it has practical problems. In particular, even trivial functions end up taking a very large number of lines. Here's the blog post example of "Take the first n elements of list xs": defun take n xs if = n 0 unit if unit? xs unit cons car xs take - n 1 cdr xs Here's exactly the same thing using sweet-expressions (which I led the development of): defun take n xs if {n = 0} unit if unit?(xs) unit cons car(xs) take {n - 1} cdr xs Even in this trivial example we see a 20% reduction in line use. We can trivially do a lot more, e.g., the last 3 lines could become one line for a 40% reduction in number of lines: cons car(xs) take({n - 1} cdr(xs)) Number of lines matters. Modern screens are typically quite wide but lack height, so a notation that requires the use of lots more lines for simple functionality means you can see far less information at one time (increasing change and debug time). Z-expressions also lack any kind of infix notation, which is a serious problem. Most software developers will not use a language without a built-in infix notation, for the same reason they won't use a line-oriented text editor... there are better alternatives available. I think it's also especially easy to get things wrong. For example: take - n 1 cdr xs Is completely different from: take - n 1 cdr xs Indentation-sensitive notations where the amount of increased indentation causes different interpretations can make it very easy to insert unintentional and hard-to-detect bugs. Anyway, my opinion, but hopefully I've provided some reasonable rationale for my opinion. I don't object to indentation-based syntax (obviously), but unsurprisingly I think there are better alternatives for this use case :-).