On Friday, 20 November 2020 at 18:44:33 UTC, H. S. Teoh wrote:
> my code passes a certain level of complexity.  IME, darling D projects that heavily utilize CTFE and templates like vibe.d's Diet templates, std.regex, etc., are painfully slow to compile and use, despite their coolness factor.

If this is the only issue, then it can be fixed with caching?

On Friday, 20 November 2020 at 12:57:24 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 20 November 2020 at 12:30:22 UTC, aberba wrote:
>> That's kind of how I use D. The language for prototyping, scripting, development (web, system), teaching, competitive programming. I don't have to relearn a new language.
>
> As programmers gain more experience learning a new language is a small challenge. What is expensive is figuring out how to use libraries and frameworks (and to find the ones you need). Also there is a heavy transition costs if you have to port your own libraries/code bases.

You're basically saying the same thing....for the most part. However, I see most people think that's all it entails when they write D code like Java code. Every language has its own idiomatic way of doing things and its own tricks.

On Friday, 20 November 2020 at 18:44:33 UTC, H. S. Teoh wrote:
> Do you have a concrete example of where type functions would do much better than templates, that might serve as a good motivating example of why type functions would be a good idea?

I can rewrite Binderoo with type functions, which essentially take one type (user or function types) and transform it in to something else.

But higher level. It will fundamentally change the way you approach metaprogramming. Even now, we have that thing that Andrei will say about C++. Where D is multiple languages under one banner. Writing D code can be as complicated as C#, but get in to DbI and it's a different language you need to learn. So I put it this way.

"Can you write a function?"
"Yes."
"Then you can do hardcore metaprogramming."

It's going to be a paradigm shift to get it in to a language like this.

On Fri, Nov 20, 2020 at 09:20:19PM +0000, Ethan via Digitalmars-d wrote: [...]
> "Can you write a function?"
> "Yes."
> "Then you can do hardcore metaprogramming."
> 
> It's going to be a paradigm shift to get it in to a language like this.

+1, I like that.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

On Friday, 20 November 2020 at 20:22:14 UTC, aberba wrote:
> they write D code like Java code. Every language has its own idiomatic way of doing things and its own tricks.

Right, but it is important to keep in mind that those idioms are cultural constructs, so if the language is flexible like D, you need to be smart on a cultural level to establish "code interface norms". This is where having gc, nogc, betterC etc can become a serious problem.

On Friday, 20 November 2020 at 22:09:14 UTC, H. S. Teoh wrote:
> +1, I like that.

Separately. Programmers that have no interest in D that I've spoken to, when I say "first class types are being pursued" they immediately have interest.

This isn't the thread for it. But there's _SERIOUSLY_ a big win to getting that in as a feature.

On Friday, 20 November 2020 at 23:19:50 UTC, Ethan wrote:
> On Friday, 20 November 2020 at 22:09:14 UTC, H. S. Teoh wrote:
>> +1, I like that.
>
> Separately. Programmers that have no interest in D that I've spoken to, when I say "first class types are being pursued" they immediately have interest.
>
> This isn't the thread for it. But there's _SERIOUSLY_ a big win to getting that in as a feature.

+1

Templates are great when used declaratively, as simple patterns that get filled in (aka templates).  They can be pressed in to service as "functions" but it's a bad fit.  Type functions would help, a lot, but there's more.

On Friday, 20 November 2020 at 16:12:35 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 20 November 2020 at 15:53:42 UTC, Bruce Carneal wrote:
>> Constraints are key.  The question is when they are applied and by whom.  Does the language designer choose the constraints ahead of time or does the programmer opt-in/out of full capability at need?
>
> The challenge is that opt-in/out is a source of serious bugs. Also very difficult to prove that the overall system is sound if you have many options that you can turn on/off.

The challenge is to provide as much readily accessible power as you can safely and correctly.  It is a language design error to promise something that you can not check automatically/correctly in the compiler.  If a language has such errors it needs an upgrade.

I also consider it an language design error to have defaulted to unsafe modes.  Things should default to safe/correct with opt-out capability to fast/dangerous. (I support @safe as default, for example, just not the extern(C) == safe nonsense)

>
> Another problem is that even if you can make it work for single threaded it might break down when you add concurrency, for instance, you can create a parallel high level language that provably cannot deadlock. With low level multi-threading that is basically off the table.

If "it", whatever that is, precludes safe parallelism in libraries or language extensions then "it" should be removed from the language.

Again, defaults really matter here.  If the right way is the default way then leaving the "wrong" way escape hatch costs less, in my view, than forcing two or more languages.

On Saturday, 21 November 2020 at 01:52:36 UTC, Bruce Carneal wrote:
> If "it", whatever that is, precludes safe parallelism in libraries or language extensions then "it" should be removed from the language.
>
> Again, defaults really matter here.  If the right way is the default way then leaving the "wrong" way escape hatch costs less, in my view, than forcing two or more languages.

Well, @safe just means memory safe, not sure if it is meant to also cover multi threading safety?

The guarantees are not very clear to me.

It is also not clear what happens if you allocated something as shared, cast away shared and the call free(). Are you allowed to have two separate heaps?

It is unclear if D programmers follow the same principles or just rely on testing with the current runtime. If it is the latter then it will be difficult to get clean nonbreaking  semantics.

On Saturday, 21 November 2020 at 02:42:13 UTC, Ola Fosheim Grostad wrote:
> On Saturday, 21 November 2020 at 01:52:36 UTC, Bruce Carneal wrote:
>> If "it", whatever that is, precludes safe parallelism in libraries or language extensions then "it" should be removed from the language.
>>
>> Again, defaults really matter here.  If the right way is the default way then leaving the "wrong" way escape hatch costs less, in my view, than forcing two or more languages.
>
> Well, @safe just means memory safe, not sure if it is meant to also cover multi threading safety?
>
> The guarantees are not very clear to me.
>

I've only read about @safe referring to the memory safety that you noted.

> It is also not clear what happens if you allocated something as shared, cast away shared and the call free(). Are you allowed to have two separate heaps?

I don't have a comprehensive understanding of where D is at and where it is headed wrt memory safety models.  The @live stuff looks a little "iffy".  Hopefully Walter's upcoming talk will help.

>
> It is unclear if D programmers follow the same principles or just rely on testing with the current runtime. If it is the latter then it will be difficult to get clean nonbreaking  semantics.

As you note, some language advances may not be practical for D but others could be built atop extant automated/correct checking and some could be independent, never-existed-before, capabilities where backward compatibility is not a concern: type functions, monadic type variables, new memory guarantees, arbitrarily prolonged "compile time", ...