Why is D unpopular (page 90)

On Sunday, 12 June 2022 at 11:49:21 UTC, Ola Fosheim Grøstad wrote:

On Sunday, 12 June 2022 at 10:40:02 UTC, Max Samukha wrote:

Then it is natural to expect the feature would apply to the class level (if we are talking about class-based OOP)? Really, I'm yet to meet a D user that wouldn't be surprised 'private' is module-level. And the 'friend' story rarely impresses them. The reply is always: "Ok, 'friend' breaks OOP principles. Is D better because it breaks OOP in its own way?"

Yes, of course, D could make private work like C++ and give module access to protected instead.

You could also allow reading of object attributes from the module and restrict writing to the object (without using properties).

If I could have private (or any keyword that mimics C++ private) as a optional compiler flag, I would turn that on in a heartbeat.

June 12, 2022

Re: Why is D unpopular

Posted by Mike Parker
in reply to Max Samukha

Permalink

Mike Parker

Posted in reply to Max Samukha

Permalink

On Sunday, 12 June 2022 at 14:05:00 UTC, Max Samukha wrote:

On Sunday, 12 June 2022 at 11:47:53 UTC, Mike Parker wrote:

Hi, Mike! Congratulations on being the first unsurprised D user! (You were actually surprised for a moment, weren't you?)

No. Nor was I surprised, for example, when I learned that in Python all members are public, or that protected in C# is more restrictive than protected in Java.

Every language has a similar approach as other languages to some things, a different approach to others. I've investigated enough programming languages that I learned long ago to be open to the differences and never to expect that just because something is true in Language A that it will be true for a similar feature in Language B.

I often have reactions of "neat" or "cool", or "too bad" or "that sucks", but I can't say I'm ever really surprised when learning about features the first time. You have to learn to think in the language you're using if you want to be productive with it, and that means accepting the differences. You may find some things grate on your nerves because they don't square with your view of the world, in which case you either push to change them, accept them, or, if it's too much to handle, move on to a language that better fits your mental model. The latter is why I never stuck with C++.

When I first learned about D's private-to-the-module approach, it made perfect sense to me. It fits right in with D's concept of modules.

I have been surprised occasionally, though, when I was certain a feature worked a certain way, but I learned later my understanding was wrong. There were a couple of those instances when I was writing Learning D, but I can't for the life of me remember what they were.

On Sunday, 12 June 2022 at 14:05:00 UTC, Max Samukha wrote: > (You were actually surprised for a moment, weren't you?) Actually, when I used PHP's classes the first time, I as so perplexed at why this private thing was giving an error when the code was right next to it. It just seems so unnatural.

On Sunday, 12 June 2022 at 11:11:32 UTC, Sergey wrote: > On Sunday, 12 June 2022 at 01:03:06 UTC, forkit wrote: >> My argument could not be simpler: >> >> Compiler. please enforce the invariants of my class at compile time, if that's what I ask you to do (with, for example, 'scope private int x'; >> >> It's a really, really, really, really, simple proposition. > > Why not prepare well written DIP with examples from other languages and to ask some experienced core developer to have a look at it? Cause the decision to reject it, has already been made ;-) If I want a compiler that can enforce invariants of a class from code surrounding it, I'll have to look elsewhere. Which is probably what I'll end up doing. (e.g. Swift).

On Sunday, 12 June 2022 at 12:26:33 UTC, Chris Katko wrote: > > If I could have private (or any keyword that mimics C++ private) as a optional compiler flag, I would turn that on in a heartbeat. That is actually a decent alternative (i.e. an 'optional' compiler switch). But even with the support of the D community, this would likely end up being something that Walter would have to implement (in that messy thing known as the frontend). I'm sure he would give it is foremost attention ;-) To be honest, the more I look into Swift (I only started a few days ago), the less impressed I am with D. I think Swift has a really bright future actually. https://docs.swift.org/swift-book/GuidedTour/GuidedTour.html

On Sunday, 12 June 2022 at 14:56:53 UTC, Mike Parker wrote: > It takes a certain amount of ' ?? ' (not sure of the right word to use here) to not be surprised, when you're new car arrives and you're told "only brakes on the rear are necessary in this car", when you're experience is, that brakes on all wheels are more likely to protect you from an accident.

On Sunday, 12 June 2022 at 23:15:30 UTC, forkit wrote: > On Sunday, 12 June 2022 at 14:56:53 UTC, Mike Parker wrote: >> > > It takes a certain amount of ' ?? ' (not sure of the right word to use here) to not be surprised, when you're new car arrives and you're told "only brakes on the rear are necessary in this car", when you're experience is, that brakes on all wheels are more likely to protect you from an accident. The ?? is that you think this is a relevant analogy.

On Monday, 13 June 2022 at 01:07:07 UTC, Mike Parker wrote: > On Sunday, 12 June 2022 at 23:15:30 UTC, forkit wrote: >> On Sunday, 12 June 2022 at 14:56:53 UTC, Mike Parker wrote: >>> >> >> It takes a certain amount of ' ?? ' (not sure of the right word to use here) to not be surprised, when you're new car arrives and you're told "only brakes on the rear are necessary in this car", when you're experience is, that brakes on all wheels are more likely to protect you from an accident. > > The ?? is that you think this is a relevant analogy. Yes, coming up with an analogy for confusing decision in D, is challenging ;-) Putting analogies aside then.... The D approach of 'everything in a module is global to the module - and that's all there is to it', results in massive blobs of potentially globally mutating logic, that is very difficult to reason about. Don't believe me? Go look at D source code. But, just look what happens, when you have more flexibilty with access control: public class SomePublicClass // explicitly public class { fileprivate func someFilePrivateMethod() {} // explicitly file-private private func somePrivateMethod() {} // explicitly private class } (1) Now you can fully reason about that 'chunk' of code. You don't need to factor into consideration what other code as well, just to understand this little chunk. (2) Now the reasoning acts as a form of documentation also. (3) Now the reasoning is enforced by the compiler (you don't have to 'just not make mistakes'). Why would anyone would want to 'give this up' (or be forced to give it up), in favour of a 'global module mutation approach'? It is beyond my comprehension, and difficult to come up with a suitable analogy. Although, that brakes analogy suddenly starts to look not so bad afterall. i.e. Perhaps they 'just don't care all that much' about reducing the likelihood of an accident. 'Just don't have one' is their motto.

Forums