The Snap! block based visual programming language uses "zebra coloring" by using a light and dark version of the same hue, with alternating black and white text, to clearly show the structure of nested blocks of the same type.
>Zebra Coloring:
This feature, introduced in BYOB 3.0, is representative of the careful attention to the user interface in BYOB/Snap!. When same-color blocks are nested, it's hard to see the borders between them. Zebra coloring assigns two colors to each palette category, the normal color and a lighter color. When same-color blocks are nested, the outermost one has the normal color, and an inner block takes the opposite color from the one just outside it. The text inside light color blocks is black, instead of white as usual.
>The round block rounds 35.3905… to 35, and the + block adds 100 to that. (By the way, the round block is in
the Operators palette, just like +, but in this script it’s a lighter color with black lettering because Snap!alternates
light and dark versions of the palette colors when a block is nested inside another block from the same palette:
>This aid to readability is called zebra coloring.)
>Non-goal: Emulate the terse APL syntax. It’s too bad, in a way; as noted above, the terseness of
expressing a computation affects APL programmers’ sense of what’s difficult and what isn’t. But you can’t say
“terse” and “block language” in the same sentence. Our whole raison d’être is to make it possible to build a
program without having to memorize the syntax or the names of functions, and to allow those names to be long
enough to be self-documenting. And APL’s syntax has its own issues, of which the biggest is that it’s hard to use
functions with more than two inputs; because most mathematical dyadic functions use infix notation (the
function symbol between the two inputs), the notion of “left argument” and “right argument” is universal in
APL documentation. The thing people most complain about, that there is no operator precedence (like the
multiplication-before-addition rule in normal arithmetic notation), really doesn’t turn out to be a problem.
Function grouping is strictly right to left, so 2×3+4 means two times seven, not six plus four. That takes some
getting used to, but it really doesn’t take long if you immerse yourself in APL. The reason is that there are too
many infix operators for people to memorize a precedence table. But in any case, block notation eliminates the
problem, especially with Snap!’s zebra coloring. You can see and control the grouping by which block is inside
which other block’s input slot. Another problem with APL’s syntax is that it bends over backward not to have
reserved words, as opposed to Fortran, its main competition back then. So the dyadic ○ “circular functions”
function uses the left argument to select a trig function. 1○x is sin(x), 2○x is cos(x), and so on. ‾1○x is arcsin(x).
What’s 0○x? Glad you asked; it’s √1 − W!.
https://snapwiki.miraheze.org/wiki/Snap!
>Zebra Coloring: This feature, introduced in BYOB 3.0, is representative of the careful attention to the user interface in BYOB/Snap!. When same-color blocks are nested, it's hard to see the borders between them. Zebra coloring assigns two colors to each palette category, the normal color and a lighter color. When same-color blocks are nested, the outermost one has the normal color, and an inner block takes the opposite color from the one just outside it. The text inside light color blocks is black, instead of white as usual.
Snap Manual, Page 11:
https://snap.berkeley.edu/snap/help/SnapManual.pdf#page=11
>The round block rounds 35.3905… to 35, and the + block adds 100 to that. (By the way, the round block is in the Operators palette, just like +, but in this script it’s a lighter color with black lettering because Snap!alternates light and dark versions of the palette colors when a block is nested inside another block from the same palette:
>This aid to readability is called zebra coloring.)
Snap Manual, Page 150:
https://snap.berkeley.edu/snap/help/SnapManual.pdf#page=150
>Non-goal: Emulate the terse APL syntax. It’s too bad, in a way; as noted above, the terseness of expressing a computation affects APL programmers’ sense of what’s difficult and what isn’t. But you can’t say “terse” and “block language” in the same sentence. Our whole raison d’être is to make it possible to build a program without having to memorize the syntax or the names of functions, and to allow those names to be long enough to be self-documenting. And APL’s syntax has its own issues, of which the biggest is that it’s hard to use functions with more than two inputs; because most mathematical dyadic functions use infix notation (the function symbol between the two inputs), the notion of “left argument” and “right argument” is universal in APL documentation. The thing people most complain about, that there is no operator precedence (like the multiplication-before-addition rule in normal arithmetic notation), really doesn’t turn out to be a problem. Function grouping is strictly right to left, so 2×3+4 means two times seven, not six plus four. That takes some getting used to, but it really doesn’t take long if you immerse yourself in APL. The reason is that there are too many infix operators for people to memorize a precedence table. But in any case, block notation eliminates the problem, especially with Snap!’s zebra coloring. You can see and control the grouping by which block is inside which other block’s input slot. Another problem with APL’s syntax is that it bends over backward not to have reserved words, as opposed to Fortran, its main competition back then. So the dyadic ○ “circular functions” function uses the left argument to select a trig function. 1○x is sin(x), 2○x is cos(x), and so on. ‾1○x is arcsin(x). What’s 0○x? Glad you asked; it’s √1 − W!.