When you put it from this perspective, it seems to make sense, however, I do 
not agree.

To me, from first principles it seems it’s all about condensing more complexity 
in smaller modular packages.

Leaving modularity aside, condensing more complexity in smaller packages in 
programming area is most often expressed via abstractions. Starting from binary 
we build more expressive components and applications, where each layer uses 
less and less code to do more and more complex things.

Yes, when you increase complexity without increasing the size - you say 
expressiveness.
But when you make package smaller without increasing complexity - you say 
conciseness.

So "expressiveness ~ 1/conciseness" if both aspects of phenomena are taken into 
account.

And decreasing number of characters is not conciseness, but rather 1 dimension 
of it, nevertheless important.

That is why I am a bit confused, when someone argues that it is not about 
conciseness, but about expressiveness.

I see the POV, that say ok x-size, y-expressiveness, however I think in this 
case, it is not expressiveness, but rather functionality.

So x-size(however one defines it), y-functionality.
Expressiveness = y/x
Conciseness = x/y
Thus, expressiveness = 1 / conciseness.

Maybe I am not using the terminology correctly (seems right to me, given 
etymology of these words), but this is just to explain what I meant.


> On 18 Jul 2023, at 18:34, Paul Moore <p.f.mo...@gmail.com> wrote:
> 
> On Tue, 18 Jul 2023 at 16:13, Dom Grigonis <dom.grigo...@gmail.com 
> <mailto:dom.grigo...@gmail.com>> wrote:
> To me, they are in the inverse relationship.
> 
> Terseness ~ 1 / expressiveness.
> 
> No, they are unrelated (in general).
> 
> Terseness is nothing more than "can I use fewer characters?" and is almost 
> always the wrong thing to do in isolation (yes, if things get *yoo* verbose 
> they can be hard to comprehend, but that's about going to extremes, not about 
> terseness as such).
> 
> Expressiveness is about matching the *concepts* involved to the problem. So 
> list comprehensions are expressive because they declaratively say what the 
> content of the list should be, and avoid the unnecessary concepts around how 
> you build the list. It's irrelevant how many characters are involved, what 
> matters is that you can omit saying "first create an empty list, now add 
> elements like <this> one by one..."
> 
> Paul

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6YRQLO74MSD3F3IJEWXIOJ7BOOHNELSE/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to