On Sunday, 15 November 2020 at 13:08:58 UTC, Paul Backus wrote:
> On Sunday, 15 November 2020 at 12:31:15 UTC, Russel Winder wrote:
>> I'd say it is a matter of personal prejudice, so most likely different for each individual.
>>
>> Where two people agree on the "expressiveness" of different programming languages, you have the beginnings of a clique.
>
> What if I told you there's a way to mathematically formalize the idea of "expressiveness" while preserving many of our intuitions about which programming languages are more expressive than others?
>
> Are you curious? If so, watch the talk--it's all in there. :)

Interesting talk, I've enjoyed it, thanks!

On Sun, 2020-11-15 at 13:08 +0000, Paul Backus via Digitalmars-d wrote:
> On Sunday, 15 November 2020 at 12:31:15 UTC, Russel Winder wrote:
> > I'd say it is a matter of personal prejudice, so most likely different for each individual.
> > 
> > Where two people agree on the "expressiveness" of different programming languages, you have the beginnings of a clique.
> 
> What if I told you there's a way to mathematically formalize the idea of "expressiveness" while preserving many of our intuitions about which programming languages are more expressive than others?
> 
> Are you curious? If so, watch the talk--it's all in there. :)

Except that I see/hear no mathematical definition of the concept of "expresiveness".

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sunday, 15 November 2020 at 14:53:04 UTC, Russel Winder wrote:
>
> Except that I see/hear no mathematical definition of the concept of "expresiveness".

The talk defines a relation, "more expressive than", between languages. As I'm sure you're aware, a relation between pairs of elements of a set is sufficient to define an ordering of that set. In this case, I believe it is entirely reasonable to refer to the ordering so defined as "expressiveness", even if it is not explicitly referred to by that name in the talk itself.

Also, I remind you that you are the one that brought the word "expressiveness" into this discussion in the first place. In my original post, you will note that I took care to use the term "more expressive" to refer to the aforementioned relation.

On 11/14/20 8:01 PM, Paul Backus wrote:
> What do we mean when we say that one programming language is "more expressive" than another? Is it just a matter of opinion and personal taste, or is there some underlying objective truth? And is more expressiveness necessarily a good thing?
> 
> Based on a 1991 paper by Matthias Felleisen, this presentation by Shriram Krishnamurthi is an accessible and easy-to-digest introduction to some of the programming-language theory that goes into answering the above questions. If you have even a passing interest in programming-language design, it's well worth your time to give this a watch.
> 
> https://www.youtube.com/watch?v=43XaZEn2aLc

I enjoyed the talk and like the principles shown.

But I think this doesn't really answer the question of which language is more expressive than another, because they are completely separate languages. It's more of a test as to whether a language feature adds expressiveness to an existing language (that is, when language A is equivalent to language B + feature F).

And the bar is pretty high. I don't know if there are many "expressive" features left to add to D if we go by this definition unless we go AST-macros.

-Steve

On Monday, 16 November 2020 at 16:37:07 UTC, Steven Schveighoffer wrote:
> On 11/14/20 8:01 PM, Paul Backus wrote:
>> [...]
>
> I enjoyed the talk and like the principles shown.
>
> But I think this doesn't really answer the question of which language is more expressive than another, because they are completely separate languages. It's more of a test as to whether a language feature adds expressiveness to an existing language (that is, when language A is equivalent to language B + feature F).
>
> And the bar is pretty high. I don't know if there are many "expressive" features left to add to D if we go by this definition unless we go AST-macros.
>
> -Steve

string mixins kind of ruined this distinction for us - even AST macros would have a hard time proving that they can't be expressed via (mixin(genCode(params))) :D

Anyways, Paul, thanks for sharing the talk, I also enjoyed watching it!

On Monday, 16 November 2020 at 16:40:56 UTC, Petar Kirov [ZombineDev] wrote:
> On Monday, 16 November 2020 at 16:37:07 UTC, Steven Schveighoffer wrote:
>> On 11/14/20 8:01 PM, Paul Backus wrote:
>>> [...]
>>
>> I enjoyed the talk and like the principles shown.
>>
>> But I think this doesn't really answer the question of which language is more expressive than another, because they are completely separate languages. It's more of a test as to whether a language feature adds expressiveness to an existing language (that is, when language A is equivalent to language B + feature F).
>>
>> And the bar is pretty high. I don't know if there are many "expressive" features left to add to D if we go by this definition unless we go AST-macros.
>>
>> -Steve
>
> string mixins kind of ruined this distinction for us - even AST macros would have a hard time proving that they can't be expressed via (mixin(genCode(params))) :D

s/expressed via/locally re-written (lowered to)/

On Monday, 16 November 2020 at 16:37:07 UTC, Steven Schveighoffer wrote:
> I enjoyed the talk and like the principles shown.

What are the principles?

> And the bar is pretty high. I don't know if there are many "expressive" features left to add to D if we go by this definition unless we go AST-macros.

Oh, there is a ton of stuff to add. Logic programming, idris/agda like type system, an smt engine, verified concurrent actor concepts etc...

In reality, expressiveness is not the challenge, but bridging the gap between modelling and implementation while ensuring correctness and maintainability with little performance loss and low labour costs...

On 11/16/20 11:54 AM, Ola Fosheim Grøstad wrote:
> On Monday, 16 November 2020 at 16:37:07 UTC, Steven Schveighoffer wrote:
>> I enjoyed the talk and like the principles shown.
> 
> What are the principles?

That you can measure expressiveness via checking if two expressions are equivalent before and after the feature is added. It gives a nice measurable distinction for features that might be considered "primitives" for what a language can express.

>> And the bar is pretty high. I don't know if there are many "expressive" features left to add to D if we go by this definition unless we go AST-macros.
> 
> Oh, there is a ton of stuff to add. Logic programming, idris/agda like type system, an smt engine, verified concurrent actor concepts etc...
> 
> In reality, expressiveness is not the challenge, but bridging the gap between modelling and implementation while ensuring correctness and maintainability with little performance loss and low labour costs...

I agree that I don't measure expressiveness in the same way.

For example, they removed traditional for-loops from Swift because they can be expressed via while loops or foreach loops.

But that doesn't help when what I need is a for loop. Syntax sugar has tangible benefit that shouldn't be dismissed.

-Steve

On Monday, 16 November 2020 at 17:09:16 UTC, Steven Schveighoffer wrote:
> For example, they removed traditional for-loops from Swift because they can be expressed via while loops or foreach loops.
>
> But that doesn't help when what I need is a for loop. Syntax sugar has tangible benefit that shouldn't be dismissed.

Yes, human factors and programming culture should not take a back seat to the math perspective when designing a language.  In some sense it is good that many programmers now get trained on Python, so that we have shared frame of references and conceptualizations.

We can create minimalistic expressive languages, but the resulting code is hard to read for most humans, in some sense the programming language should allow us to express algorithms in terms of our physical experience which we often use to understand complicated systems: objects, actions, roles, stereotypes/concepts/interfaces/subclasses, actors...

Anyway, there is a cross cutting field in CS that try to abstract the semantics of various programminglanguages to find the essence of programming language design, I guess it is comparable to how category theory tries to describe key patterns i math.