November 08, 2021

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

>

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.)

class as a reference type makes sense as you are dealing with polymorphism. The only thing I see is unnecessary is the "*", which from my understand is intentional design by walter. Which according to him, it is to make porting c code to d easier. Yet we have import c now. So I don't know what he thinks of it now.

-Alex

November 08, 2021

On Monday, 8 November 2021 at 16:29:28 UTC, bachmeier wrote:

>

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

I think that is the wrong line of argument. The core language ought to be minimal, yet complete. So, for a system level programmer having some language features being GC dependent is seen as a red flag.

For that to be reasonable you would need different profiles and a more layered approach. So you have a core language (no GC) and then on top of that a more high level language (possibly GC).

November 08, 2021

On Monday, 8 November 2021 at 17:40:08 UTC, 12345swordy wrote:

>

class as a reference type makes sense as you are dealing with polymorphism.

Maybe so, but you could have the same typing scheme. Just make it a typing error to instantiate it as a non-reference type.

So you could for instance collapse struct/class, yet allow the programmer to specify that this particular struct/class can only be instantiated as heap-object.

And you could similarly put a ban on virtual members. So rather than having special cases struct and class, you allow the addition of constraints to a singular aggregate concept.

November 08, 2021
On Mon, Nov 08, 2021 at 03:57:30PM +0000, jfondren via Digitalmars-d 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:
> 
> - 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)

I can understand this sentiment, but why would I care about features that I don't want/use?  As long as I'm not forced to use it, I can just not use those features.  I used to write quite a lot of C++, but I doubt if I even used 50% of its features.  That didn't stop me from writing lots of useful C++ code.


> - for the language's future to be more certain

I'm not sure how strictness equates with the future, the latter doesn't necessarily follow from the former.  But sure, if people want something concrete to put a finger on...


> - for the language to get more popular

Again, not sure how this follows from strictness, but OK, sure.


> - for robust follow-through on features that are added

Now this is something I could stand behind.  A lot of D features aren't bad ideas per se, but they only cover a small subset of use cases, and their interactions with other language features is anybody's guess (usually this means an ICE). Things like `inout` or `shared` fall in this category.


> - 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 ???).

"This D bug breaks existing code" - that seems to be the biggest bugbear / motivator these days. :-D


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

I usually don't bother participating in threads about popularity, because I don't believe in the philosophy that more popular == better, or that popularity should be a goal at all.  But I responded this time because it sounded really strange that people would actually prefer less choice instead of more in a programming language. :-D


T

-- 
For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
November 08, 2021

On Monday, 8 November 2021 at 01:36:59 UTC, arco wrote:

>

On Sunday, 7 November 2021 at 09:18:37 UTC, Ola Fosheim Grøstad wrote:

>

[...]

It is a very common response when people are enthusiastic about a particular technology. People for whom using D is a goal in itself are using it, but the others are not going to move to it for the sake of using D. They would do it if D solves some problems they are currently facing, or if it allows them to achieve their own objectives (which are probably unrelated to D) better than some other alternative.

[...]

Erlang rox

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.

What is needed is more of a layered approach.

That's what -betterC is for I believe.

November 08, 2021

On Monday, 8 November 2021 at 18:59:56 UTC, Dukc wrote:

>

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

>

What is needed is more of a layered approach.

That's what -betterC is for I believe.

That is more of a feature removal. You ought to have all interfacing types at the bottom layer.

November 08, 2021

On Monday, 8 November 2021 at 18:02:27 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 8 November 2021 at 17:40:08 UTC, 12345swordy wrote:

>

class as a reference type makes sense as you are dealing with polymorphism.

Maybe so, but you could have the same typing scheme. Just make it a typing error to instantiate it as a non-reference type.

So you could for instance collapse struct/class, yet allow the programmer to specify that this particular struct/class can only be instantiated as heap-object.

And you could similarly put a ban on virtual members. So rather than having special cases struct and class, you allow the addition of constraints to a singular aggregate concept.

That would be reaching near the infamous "curse of lisp" here.

-Alex

November 08, 2021

On Monday, 8 November 2021 at 19:56:11 UTC, 12345swordy wrote:

>

That would be reaching near the infamous "curse of lisp" here.

Why is that? As I said you can add syntactical sugar.

November 08, 2021

On Monday, 8 November 2021 at 18:02:27 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 8 November 2021 at 17:40:08 UTC, 12345swordy wrote:

>

class as a reference type makes sense as you are dealing with polymorphism.

Maybe so, but you could have the same typing scheme. Just make it a typing error to instantiate it as a non-reference type.

So you could for instance collapse struct/class, yet allow the programmer to specify that this particular struct/class can only be instantiated as heap-object.

And you could similarly put a ban on virtual members. So rather than having special cases struct and class, you allow the addition of constraints to a singular aggregate concept.

We are lucky we have class in D as ref is near useless in D meta-programming.

alias I1(alias T) = T;
alias I2(T...) = T;

I1!(ref int) i1; // RIP
I2!(ref int) i2; // RIP

I rest my case.