On Wed, Oct 23, 2019 at 03:16:51PM +0100, Rhodri James wrote:
I'm seriously not getting the issue people have with
colours1 = ["red", "green", "blue"]
which has the advantage of saying what it means.
As opposed to the alternatives, which say something different from what they mean? The existing alternative: "red green blue".split() equally "has the advantage of saying what it means", and so will the proposed alternative, just as it already does in Ruby. I know that code is read more than it's written, but it still has to be written, and maintained, and writing out long lists of words is annoying to write and tedious to read. An example like "red", "green", "blue" isn't too bad, but try it with 30 or more single-word strings. I have. 1 out of 5, would not recommend. Hand-writing repetitive, dumb, mechanical code is an anti-pattern. I'm sure that, somewhere out there, there's a coder who prefers to write: [mylist[1], mylist[2], mylist[3], mylist[4], mylist[5]] instead of the obvious slice, but most of us didn't become programmers because we love the tedious, repetitive boilerplate. [ QUOTE red QUOTE COMMA QUOTE green QUOTE COMMA QUOTE blue QUOTE COMMA QUOTE yellow QUOTE COMMA QUOTE magenta QUOTE COMMA ... ] Wherever possible, we should let the interpreter or compiler do the repetitive stuff. The average word length in English is five characters. That means that in a list of typical English words, more than a third of the expression is made up of the quotes and commas. In the example you give, there are twelve characters in the words themselves and eight characters worth of boilerplate surrounding them (quotes and commas, not including the spaces or brackets). -- Steven