https://youtube.com/watch?v=tcyb1lpEHm0

If nothing else please watch the opening story, it's true and quite funny :o).

Now as to the talk, as you could imagine, it touches on another language as well...


Andrei

On 1/12/2019 7:51 AM, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0

Wonderful talk! The questions asked at the end were great, too.

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0
>
> If nothing else please watch the opening story, it's true and quite funny :o).
>
> Now as to the talk, as you could imagine, it touches on another language as well...
>
>
> Andrei

Top notch, as usual.

Nice progression from “another language” through “the other language”, “d (other) language” to finally just “D language“ :-)

Bastiaan.

On 1/12/19 7:21 PM, Bastiaan Veelo wrote:
> On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
>> https://youtube.com/watch?v=tcyb1lpEHm0
>>
>> If nothing else please watch the opening story, it's true and quite funny :o).
>>
>> Now as to the talk, as you could imagine, it touches on another language as well...
>>
>>
>> Andrei
> 
> Top notch, as usual.
> 
> Nice progression from “another language” through “the other language”, “d (other) language” to finally just “D language“ :-)
> 
> Bastiaan.

Glad you noticed. It was deliberate.

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0
>
> If nothing else please watch the opening story, it's true and quite funny :o).
>
> Now as to the talk, as you could imagine, it touches on another language as well...
>
>
> Andrei

Very nice. I especially liked how design by introspection was contrasted with other approaches and how the constexpr discussion fit into the overall theme.

--Jon

On 1/12/2019 7:51 AM, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0

One major takeaway is that the bugs/line are the same regardless of the language used. This means that languages that enable more expression in fewer lines of code result in fewer bugs for the same functionality.

Another way to look at that is when refactoring code, look for ways of reducing the line count.

It does not mean deleting comment lines, or putting several statements on one line. :-)

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0

I especially like how design by introspection was contrasted with concepts and metaclasses, culminating in "We want to generate more smart code, not more boilerplate.  We want to generate code that matters." Indeed.  But what language features do we already have that are as "bo-riing" as concepts and metaclasses?

What I wonder is, with design by introspection and the right mix of other language features (e.g. `alias`, `alias this`, mixins, etc...), what traditional language features can be removed from the compiler and delegated to library facilities? For example,  https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html

Because design by introspection allows us to "assemble programs atomically", perhaps high-level language features like classes and interfaces can become obsolete, and the language itself can be reduced simpler primitives that don't require the overhead of a runtime.

Mike

On Monday, 14 January 2019 at 03:58:37 UTC, Mike Franklin wrote:
> What I wonder is, with design by introspection and the right mix of other language features (e.g. `alias`, `alias this`, mixins, etc...), what traditional language features can be removed from the compiler and delegated to library facilities? For example,  https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html
>
> Because design by introspection allows us to "assemble programs atomically", perhaps high-level language features like classes and interfaces can become obsolete, and the language itself can be reduced simpler primitives that don't require the overhead of a runtime.
>
> Mike

Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].)

When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything.

[1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
[2] https://en.wikipedia.org/wiki/Focal_point_(game_theory)

On 1/13/2019 9:31 PM, Paul Backus wrote:
> Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].)
> 
> When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything.
> 
> [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
> [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory)

Interesting cites, which provide a basis for why I've opposed AST macros, and why Ddoc and unittest are builtin (and a few other things).

Also, before std::string came along in C++, everyone invented their own string class, and as a result, nobody could share code.

On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:

> When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything.
>
> [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
> [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory)

I think D's structs are a sufficient object system for such a focal point.  With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary.  Rust and Zig are pretty good examples of this.

D's implementation could even be improved to keep its runtime, yet still allow D to be used as I'm suggesting, without introducing any breakage for anyone.  I made some significant progress in that direction when I was working on the compiler in the 2017~2018 timeframe, but my abilities ultimately fell short, and I couldn't see a way forward without support.

Mike