November 08, 2021

On Monday, 8 November 2021 at 12:50:46 UTC, zjh wrote:

>

On Monday, 8 November 2021 at 12:43:05 UTC, zjh wrote:

>

Phobos's

But metaprogramming is definitely a bonus.
Look at the newly languages. Which one has no generics?

Generics has good type inference support: it is a well stablished part of methods/classes/interfaces signature... metaprogrammig with mixins difficuts type inference for code intellisense

November 08, 2021

On Monday, 8 November 2021 at 13:03:59 UTC, Antonio wrote:

>

On Monday, 8 November 2021 at 12:50:46 UTC, zjh wrote:

> >

Look at the newly languages. Which one has no generics?

>

metaprogrammig with mixins difficuts type inference for code intellisense

This is what D team should dive into.
The problem has been raised and must be solved if we want to compete with other popular languages.

November 08, 2021

On Monday, 8 November 2021 at 12:43:05 UTC, zjh wrote:

>

Phobos's idea is wrong in force. It forces you to use GC, forces you to use utf8, and forces you to use auto decoding...

Strange definition of "force". You have to voluntarily choose to call those functions that use the GC, which does not qualify as "force" according to any standard definition. You seem to have it reversed. You want to force everyone using D to deal with the headache of avoiding the GC.

November 08, 2021

On Monday, 8 November 2021 at 13:52:52 UTC, bachmeier wrote:

>

Strange definition of "force". You have to voluntarily choose to call those functions that use the GC, which does not qualify as "force" according to any standard definition.

The language mandates a GC as design, meaning: you cannot remove the GC and use the full language.

What is needed is more of a layered approach.

November 08, 2021

On Monday, 8 November 2021 at 13:59:30 UTC, Ola Fosheim Grøstad wrote:

>

The language mandates a GC as design, meaning: you cannot remove the GC and use the full language.

What is needed is more of a layered approach.

Yes, but it can be a deterministic gc like reference counting. Pascal (modern one) did it from the beginning 20 years ago with strings, dynamic arrays and interfaces and nobody from the "every cpu cycle counts" camp complained about it. Interfaces in pascal resolved also the class/struct pointer dichotomy: use a class if you want to manage memory yourself, use an interface implemented by that class if you want that we take care of the deallocation.

I wonder if the !gc crowd will be happy with ARC built in language.

November 08, 2021

On Monday, 8 November 2021 at 14:45:19 UTC, Rumbu wrote:

>

Yes, but it can be a deterministic gc like reference counting. Pascal (modern one) did it from the beginning 20 years ago with strings, dynamic arrays and interfaces and nobody from the "every cpu cycle counts" camp complained about it. Interfaces in pascal resolved also the class/struct pointer dichotomy: use a class if you want to manage memory yourself, use an interface implemented by that class if you want that we take care of the deallocation.

I wonder if the !gc crowd will be happy with ARC built in language.

I would. You could have ARC for objects that are shared between actors/threads and use a proper GC with an actor/thread. Then you get the best of both worlds IMO.

What is preventing ARC from happening right now is that the interface between the compiler frontend and backend isn't clear. So it is very costly for an individual to implement it.

With a better compiler architecture then ARC is something a separate group of 2-3 people could add as it requires limited insight into the compiler internals, and you can start by adding regular reference counting and gradually improve on the ARC optimizations.

November 08, 2021
On Mon, Nov 08, 2021 at 01:36:59AM +0000, arco via Digitalmars-d wrote: [...]
> The other problem is that D seems deeply allergic to making hard decisions.  From reading this forum it seems to me that the overall attitude within D is that it should offer choices, not enforce decisions. But in the real world, that's often a bad thing. Another language with the same mantra was Perl.  Look at what happened to Perl the moment we got Python, Ruby etc. Enforcing decisions is a Good Thing: it ensures that people understand each other's code, that analysis tools can do a much better job, that people won't roll out their own error management that doesn't work together with someone else's, that there will be consistency in memory management, etc etc etc.  Once again, the two languages somewhat comparable to D that "made it", Go and Rust, are all about enforcing what they deemed to be their way to do things. That doesn't mean it's the only legitimate way, but it means that if you want to do X, this is how you do it in Go (not that there isn't a one true way, but you are free to try to devise 15 different ways). And if the Go way doesn't work for you, that's perfectly fine, there are other languages that would be a better fit for your problem. Same for Rust.
[...]

Interesting, one of the reasons I *like* D is because it lets me do the deciding, instead of dictating how I should do things.  IMO it's what makes it adaptable to all kinds of different tasks.  For one task I might need heavy use of the OO paradigm, for another task I might need a more functional approach, for yet another task, I might need to go low-level C-like approach with manual loop unrolling and hand-tweaking generated code.  D lets me do all of that without any encumbrance (I don't have to e.g. do lip-service to OO just to get the thing to compile, like I have to in say Java), and best of all, lets me do all of that *in the same program* because it's all D.

I'm honestly surprised anyone would want it any other way! :-D  (Being forced to do things one particular way is what drove me *away* from languages like Java.)


T

-- 
Кто везде - тот нигде.
November 08, 2021

On Monday, 8 November 2021 at 15:16:07 UTC, H. S. Teoh wrote:

>

I'm honestly surprised anyone would want it any other way! :-D (Being forced to do things one particular way is what drove me away from languages like Java.)

I doubt that people do want it any other way; strictness is seen rather as an easy to understand catalyst for what they actually want:

  • for the language to evolve in a predictable direction (and definitely not to add features they don't want, or waste time on features they don't care about)
  • for the language's future to be more certain
  • for the language to get more popular
  • for robust follow-through on features that are added
  • for there to be an easy argument to get language devs to move quickly to fix a problem (this go bug makes compilation super slow; this rust bug breaks memory safety; this d bug breaks ???).

There's a lot of arguing for means instead of ends like this when language popularity comes up.

November 08, 2021

On Monday, 8 November 2021 at 15:57:30 UTC, jfondren wrote:

>

On Monday, 8 November 2021 at 15:16:07 UTC, H. S. Teoh wrote:

>

I'm honestly surprised anyone would want it any other way! :-D (Being forced to do things one particular way is what drove me away from languages like Java.)

I doubt that people do want it any other way; strictness is seen rather as an easy to understand catalyst for what they actually want:

You need consistency in the language in order to enable sensible meta programming. So there is a need for streamlining.

For instance, having three ways to express references is not necessary. (class, "*", "ref").

Ideally you would define a minimal core and express all other concepts through meta-programming, but add syntactical sugar where necessary. (Associative arrays could have been a standard library type with syntactical sugar.)

November 08, 2021

On Monday, 8 November 2021 at 13:59:30 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 8 November 2021 at 13:52:52 UTC, bachmeier wrote:

>

Strange definition of "force". You have to voluntarily choose to call those functions that use the GC, which does not qualify as "force" according to any standard definition.

The language mandates a GC as design, meaning: you cannot remove the GC and use the full language.

I'd be willing to be money that no program has ever been written that uses all of the language features.