> "I've often wondered what are the real blocks to having it both ways?" That it's not particularly useful. Here's a classic APL: {(~T∊T∘.×T)/T←1↓⍳⍵} And in w

> "I've often wondered what are the real blocks to having it both ways?" That it's not particularly useful. Here's a classic APL: {(~T∊T∘.×T)/T←1↓⍳⍵} And in words: direct function (not T member T jot dot multiply T) compress T gets one drop iota omega. Or in Pythonic words: lambda w: [n for n in range(2, w) if n not in [i * j for i in range(2, w) for j in range(2, w)]] That is, the APL in Englishy words is no clearer. The Python is mostly clear because it's familiar (there are Python programmers who don't know or understand list comprehensions). And isn't it dull to have to type out the "for in range if n in for in range for in range" and a lambda and two list comprehensions? Just to say "numbers which aren't in the multiplication table of those numbers and themselves" Wouldn't it be clear enough if you could write more like a hybrid with JavaScript or C# anonymous functions with curly braces? lambda w: [n for n in range(2, w) if n not in [i * j for i in range(2, w) for j in range(2, w)]] w=>{nums=range(w).Drop(1); nums.where(n=>n not in outer_product(__op__.mul, nums, nums))} w=>{T=range(w).Drop(1); T.where(n=>n not in outer_product(__op__.mul, T, T))} ⍝ no idea why the original APL code used T w=>{T=range(w).Drop(1); T.where(n=>n not in T ∘.× T)} ⍝ outer product as a symbol with normal multiply symbol w=>{T=iota(w).↓(1); T.where(n=>n not in T ∘.× T)} ⍝ drop as a symbol ↓ w=>{T=1↓⍳w; T.where(n=>n not in T ∘.× T)} ⍝ range as a symbol (iota ⍳) w=>{T=1↓⍳w; (T not in T ∘.× T)/T} ⍝ where as a symbol (compress /) w=>{T=1↓⍳w; (~ T ∊ T ∘.× T)/T} ⍝ not ~ and in ∊ as symbols w=>{T←1↓⍳w ⋄ (~ T ∊ T ∘.× T)/T} ⍝ APL statement separator ⋄ {T←1↓⍳⍵ ⋄ (~ T∊T∘.×T)/T} ⍝ implicit lambda argument as a symbol (omega ⍵) {(~T∊T∘.×T)/T←1↓⍳⍵} ⍝ inlined two statements into one, reads right to left Presumably you're fine with symbols in Python like the colon when introducing functions, brackets for lists, asterisk for multiplication, parens and commas for tuples and function arguments, equals for assignment. You're likely fine with ! for Boolean 'not' in C-likes. If you have symbols for range, outer product, filter, in, drop, then you start to realise how annoying it is to type them out. We shorten the things we do often, or make them implicit. And we often do loops and data transforms when programming. It isn't the symbols which are the hard bit, and making them words doesn't make them usefully easier.