June 15, 2022

On Wednesday, 15 June 2022 at 01:57:28 UTC, zjh wrote:

>

On Wednesday, 15 June 2022 at 01:21:51 UTC, monkyyy wrote:

>

Id suggest fixing ancient template bugs and getting several competing compilers going to compete with c++;

In any case, we should not be afraid of change! not be afraid of complexity!
Take a look at 'rust'. It is becoming more and more complex. Take a look at other mainstream languages. Which is not complex?

C++23, c++26 is absolutely monsters! But people don't care!

If theres several old bugs, that suggests that the language is already past its complexity budget.

Like dual context, or calling nested templates, or my little favorite little bug, really suggests that foundation is quite unstable; I tolerate it because I dont exactly see good implementations of templates anywhere but maybe poeple like c++ because dispite being uglier syntax maybe you can find a compiler that works when you find a blocking bug

June 16, 2022
On Wednesday, 15 June 2022 at 11:16:42 UTC, Abdulhaq wrote:
> On Wednesday, 15 June 2022 at 11:06:45 UTC, forkit wrote:
>> I'm now enjoying using Swift way more than D.
>>
>> So that's it for me.
>
> I guarantee you'll be back within the month, the D forums are addictive. Even Chris has not escaped. Paulo is still here. Only bearophile is running free.

I'm back! But not for long ;-)

Just want to mention this, as it's seem pretty relevant:

So I found this discussion from 2003! That's (at least) how long this has been going on.

It will continue to go on of course, because there is no right or wrong way here.

The only genuine solution to this problem is providing 'a choice' that the programmer can make.

Sean L. Palmer : "I find that it's one of the biggest pains in programming, deciding what to make private, what to encapsulate, what to expose."

Ken Carpenter : "If you want something to be made accessible to others, then is it really so hard to type "public"?

Both perspective seem reasonable to me.

Walters response is interesting, and (of course) it still hasn't changed - i.e. -> basically (paraphrased) 'if you want to program in D, you gotta do it my way'.

In the end though, the controversy continues, not because of Sean or Ken's position, but because Walter is just too stubborn to compromise so that both Sean and Ken can both do what they think is best for their design.

In a compromise, nobody loses.

The problem here is not Sean's or Ken's view/perspective.

The problem is Walter. (and those that support his view of -> 'NO COMPROMISE!'

https://forum.dlang.org/post/b186be$udr$1@digitaldaemon.com

June 16, 2022
On Thursday, 16 June 2022 at 00:02:41 UTC, forkit wrote:
>

oops:

https://forum.dlang.org/thread/b12n5o$1lvn$1@digitaldaemon.com?page=1
June 16, 2022

On Thursday, 16 June 2022 at 00:02:41 UTC, forkit wrote:

>

but because Walter is just too stubborn to compromise so that both Sean and Ken can both do what they think is best for their design.

They only see that "public" is very useful, but they don't see that real "private" is also very useful.

June 16, 2022
On Thursday, 16 June 2022 at 00:06:14 UTC, forkit wrote:
>

see .. the world does not come crashing down, simply because you can declare something private ;-)


(in Swift)

// -----------
struct A
{
  private static var x = 100;
  fileprivate static var z = 200;
}

//print(A.x); //  error: 'x' is inaccessible due to 'private' protection level
print(A.z); // ok

// -----------

June 16, 2022

On Wednesday, 15 June 2022 at 17:13:45 UTC, monkyyy wrote:

>

but maybe poeple like c++ because dispite being uglier syntax .

C++ template syntax is not ugly ,Just get used to it.

June 16, 2022

On Thursday, 16 June 2022 at 01:04:22 UTC, forkit wrote:

>

On Thursday, 16 June 2022 at 00:06:14 UTC, forkit wrote:

>

see .. the world does not come crashing down, simply because you can declare something private ;-)

(in Swift)

// -----------
struct A
{
private static var x = 100;
fileprivate static var z = 200;
}

//print(A.x); // error: 'x' is inaccessible due to 'private' protection level
print(A.z); // ok

// -----------

Swift has 5 different access control modes:

  • private: as in C++
  • file private: for the source file
  • internal: for a collection of sources files constituting a module
  • open access: allows subclassing and override outside the module
  • public: …

Swift also does some conservative analysis of references, preventing writing to references if there is an alias that would make it a conflict:

https://docs.swift.org/swift-book/LanguageGuide/MemorySafety.html

June 16, 2022
On Thursday, 16 June 2022 at 00:02:41 UTC, forkit wrote:
> Sean L. Palmer : "I find that it's one of the biggest pains in programming, deciding what to make private, what to encapsulate, what to expose."

Incapsulation is overrated, so it's really a non issue, maybe only if you treat incapsulation as a superidea, but D doesn't honor superideas, it's a practical language.

Also memoization is a use case for varying access between different methods of the same class. Would you address that too?
June 16, 2022
On Thursday, 16 June 2022 at 07:45:52 UTC, Kagamin wrote:
> On Thursday, 16 June 2022 at 00:02:41 UTC, forkit wrote:
>> Sean L. Palmer : "I find that it's one of the biggest pains in programming, deciding what to make private, what to encapsulate, what to expose."
>
> Incapsulation is overrated, so it's really a non issue, maybe only if you treat incapsulation as a superidea, but D doesn't honor superideas, it's a practical language.
>
> Also memoization is a use case for varying access between different methods of the same class. Would you address that too?

'encapsulation' is an abstract concept.

It may well be overrated, but that doesn't mean it's not useful, and sometimes necessary. Without it, we humans would have a hard time understanding anything, about anything. It's an vital component of how we understand things. (yes, I have psych degree ;-)

The old OOP ideals of "all member variables should be private" and "global variables should be avoided", have clearly not been the best choice, over time, and certainly should never apply by default, for all cases.

What's important, is the designer(programmer, programming team) have the options to strategically use this principles to accomodate the design they believe is best for them.

This is particulary important when doing OOP, which is very different to the C like procedural progammning you often find in the D community. That C like mentality, I believe, is the source of the module design in D (i.e. everything global to the module, and that's all there is too it).

Fortunately, Swift (which intenationally set out to drop all the baggage that came with C and C like thinking), 'seems' (I've only been using it a couple of days), like a very nice alternative to D, for me - not just because it returns that choice to me, but the syntax is very pleasing to understand and work with (one of D's biggest advantages too).

With the options available to me in Swift, I feel 100% comfortable in programming in the large. Not so in D.

Although I program mostly in C#, so I've never been restricted to programming in the small ;-)

But in the many years I've been 'playing' with D, I've never considered it a suitable language, for me, to program in the large - primarily because of the 'everything is global in the module, and we in D, don't want you to have any other choice in this'.. .thing.

June 16, 2022
On Thursday, 16 June 2022 at 00:02:41 UTC, forkit wrote:
>
> So I found this discussion from 2003! That's (at least) how long this has been going on.
>
> It will continue to go on of course, because there is no right or wrong way here.
>

Yes, every once in a while we get such discussions when someone finds out that D doesn't work exactly like [insert one's favorite language here] and pretends that is THE cause of the lack of popularity of D.

Or that we absolutely need a new syntax for an existing feature to match the new language du jour, like when Go introduced the := operator. We were told that we HAD to add it too, back then, to avoid typing 'auto'.

If you really want to add a new visibility level to D, you'll have to write a DIP and convince the community that the existing four are not enough. Pretending that you'll be leaving for [whatever language better fits your needs] may only indicate that you don't care.



3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19