On Wed, Jul 25, 2018 at 05:11:08PM -0500, Abe Dillon wrote:
The problem here is not whether it's explicit. It's about Readability and conciseness. Using symbols in place of words almost always harms readability in favor of conciseness.
And that is why we prefer COBOL over unreadable Perl-like languages that use unreadable symbols like: arithmetic operators + - * / // % ** bitwise operators & | ^ >> << ~ comparison operators == != < <= >= > function call symbols func(arg) argument packing and unpacking *args, **kwargs sequence slicing seq[::] assignment = comments # decorator syntax @ What a horrible, unreadable language that would be. REMARK this is much better than Perl-like x = func(a, b, c) PUT THE RESULT OF CALLING FUNCTION func WITH ARGUMENTS a AND b AND c INTO x \s Why do you claim that symbols and conciseness is "almost always" worse for readability? Your assertion doesn't survive even a cursory consideration. Readability doesn't occur in a vacuum. You have to understand the symbols, and it doesn't matter whether they are punctuation or words, if you don't understand them, they're "unreadable": result = page_count + 1 # readable jwrtsv = xpwvabs_ue + 1 # what? result obqxayrhs page_count wmsna 1 # what? The first time I encounted Python 1.5, I found it unreadable: it was full of mysterious keywords "class", "def", strange punctuation like [1:] and x.y, and idioms I couldn't guess like for i in range(len(seq)) With no context, it might as well have been Ancient Sumarian. Do you know what helps readability? *Learning to read*. Once you have learned to read ?. and friends, they will be as readable as . and slicing is now. -- Steve