On Thursday, 13 January 2022 at 11:30:40 UTC, zjh wrote:
> On Thursday, 13 January 2022 at 03:10:14 UTC, zjh wrote:
>
> I'm a `GC phobia`.

"A phobia is an irrational fear of something that's unlikely to cause harm."

"A phobia is a type of anxiety disorder defined by a persistent and excessive fear of an object or situation."

"A phobia is an excessive and irrational fear reaction."

" phobias .. are maladaptive fear response"


plz... go get some help ;-)

On Thu, Jan 13, 2022 at 09:32:15PM +0000, Paul Backus via Digitalmars-d-announce wrote:
> On Wednesday, 12 January 2022 at 20:48:39 UTC, forkit wrote:
[...]
> > Programmers want the right of self-government, over their code.
> 
> Actually, I think *self*-government has very little to do with it.
[...]
> So, why do so many programmers reject D? Because there's something else they care about more than their own autonomy: other programmers' *lack* of autonomy. Or, as it's usually put, "the ecosystem."
[...]
> Suppose you've already decided that you don't want to use a GC, and you also don't want to write every part of your project from scratch--that is, you would like to depend on existing libraries. Where would you rather search for those libraries: code.dlang.org, or crates.io? Who would you want the authors of those libraries to be: self-governing, autonomous programmers, who are free to use GC as much or as little as they like; or programmers who have chosen to give up that autonomy and limit themselves to *never* using GC?

This reminds me of the Lisp Curse: the language is so powerful that everyone can easily write their own [GUI toolkit] (insert favorite example library here).  As a result, everyone invents their own solution, all solving more-or-less the same problem, but just differently enough to be incompatible with each other. And since they're all DIY solutions, they each suffer from a different set of shortcomings.  As a result, there's a proliferation of [GUI toolkits], but none of them have a full feature set, most are in various states of (in)completion, and all are incompatible with each other.

For the newcomer, there's a bewildering abundance of choices, but none of them really solves his particular use-case (because none of the preceding authors faced his specific problem).  As a result, his only choices are to arbitrarily choose one solution and live with its problems, or reinvent his own solution. (Or give up and go back to Java. :-D)

Sounds familiar? :-P


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

On Thursday, 13 January 2022 at 21:32:15 UTC, Paul Backus wrote:
>
> Actually, I think *self*-government has very little to do with it.
>

I'm not so sure.

Presumably, C++ provides a programmer with much greater autonomy over their code than D?

C provides even greater autonomy over both C++ and D. And I'd argue, that's why C remains so useful, and so popular (for those problems where such a level of autonomy is needed).

By, 'autonomy', I mean a language provided means, for choosing what code can do, and how it does it.

A language that makes you jump through loops to get that autonomy, will serve a niche purpose (like Java for example).

An aversion to losing that autonomy, I believe, is a very real reason as to why larger numbers of C++ programmers do not even consider switching to D.

Of course, even if they did consider D, there are other considerations at play as well.

It think this is also why D (in contrast to C++ programmers) tends to attract programmers from the C# and Java like world. That is, D provides greater autonomy (which should translate to greater freedom to innovate and be creative with code).

Of course autonomy is not something that is real.

Only the 'perception of autonomy' can be real ;-)

On Fri, Jan 14, 2022 at 01:19:01AM +0000, forkit via Digitalmars-d-announce wrote: [...]
> C provides even greater autonomy over both C++ and D. And I'd argue, that's why C remains so useful, and so popular (for those problems where such a level of autonomy is needed).
> 
> By, 'autonomy', I mean a language provided means, for choosing what code can do, and how it does it.
[...]
> An aversion to losing that autonomy, I believe, is a very real reason as to why larger numbers of C++ programmers do not even consider switching to D.

How is using D "losing autonomy"?  Unlike Java, D does not force you to use anything. You can write all-out GC code, you can write @nogc code (slap it on main() and your entire program will be guaranteed to be GC-free -- statically verified by the compiler). You can write functional-style code, and, thanks to metaprogramming, you can even use more obscure paradigms like declarative programming.

If anything, D makes it *easier* to have "autonomy", because its metaprogramming capabilities let you do so without contorting syntax or writing unmaintainable write-only code.  I can theoretically do everything in C++ that I do in D, for example, but C++ requires that I spend 5x the amount of effort to navigate its minefield of language gotchas (and then 50x the effort to debug the resulting mess), and afterwards I have to visit the optometrist due to staring at unreadable syntax for extended periods of time.

In D, I get to choose how low-level I want to go -- if all I need is a one-off shell script substitute, I can just allocate away and the GC will worry about cleaning after me.  If I need to squeeze out more performance, I run the profiler and identify GC hotspots and fix them (or discover that the GC doesn't even affect performance, and redirect my efforts elsewhere, where it actually matters more).  If that's not enough, GC.disable and GC.collect lets me control how the GC behaves. If that's still not enough, I slap @nogc on my inner loops and pull out malloc/free.

In C++, I'm guaranteed that there is no GC -- even when having a GC might actually help me achieve what I want.  In order to reap the benefits of a GC in C++, I have to jump through *tons* of hoops -- install a 3rd party GC, carefully read the docs to avoid doing things that might break it ('cos it's not language-supported), be excluded from using 3rd party libraries that are not compatible with the GC, etc.. Definitely NOT worth the effort for one-off shell script replacements. It takes 10x the effort to write a shell-script substitute in C++ because at every turn the language works against me -- I can't avoid dealing with memory management issues at every turn -- should I use malloc/free and fix leaks / dangling pointers myself? Should I use std::autoptr? Should I use std::shared_ptr? Write my own refcounted pointer for the 15th time?  Half my APIs would be cluttered with memory management paraphrenalia, and half my mental energy would be spent fiddling with pointers instead of MAKING PROGRESS IN MY PROBLEM DOMAIN.

With D, I can work at the high level and solve my problem long before I even finish writing the same code in C++.  And when I need to dig under the hood, D doesn't stop me -- it's perfectly fine with malloc/free and other such alternatives.  Even if I can't use parts of Phobos because of GC dependence, D gives me the tools to roll my own easily. (It's not as if I don't already have to do it myself in C++ anyway -- and D is a nicer language for it; I can generally get it done faster in D.)

Rather than take away "autonomy", D empowers me to choose whether I want to do things manually or use the premade high-level niceties the language affords me. (*And* D lets me mix high-level and low-level code in the same language. I can even drop down to asm{} blocks if that's what it takes. Now *that's* empowerment.) With C++, I HAVE to do everything manually. It's actually less choice than D affords me.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!

On Friday, 14 January 2022 at 02:13:48 UTC, H. S. Teoh wrote:
>
> How is using D "losing autonomy"?  Unlike Java, D does not force you to use anything. You can write all-out GC code, you can write @nogc code (slap it on main() and your entire program will be guaranteed to be GC-free -- statically verified by the compiler). You can write functional-style code, and, thanks to metaprogramming, you can even use more obscure paradigms like declarative programming.
>

I'm talking about the 'perception of autonomy' - which will differ between people. Actual autonomy does not, and cannot, exist.

I agree, that if a C++ programmer wants the autonomy of chosing between GC or not, in their code, then they really don't have that autonomy in C++ (well, of course they do actually - but some hoops need to be jumped through).

My point is, that a C#/Java programmer is more likely to be attracted to D, because D creates a perception of there being more autonomy (than that provided by C#/Java).

I'm not saying it's the only thing people consider. Obviously their choice is also reflected by the needs of their problem domain, their existing skill set, the skillset of those they work with, the tools they need, the extent to which their identity is attached to a language or community, etc..etc.

And I'm just talking about probability - that is, people are more likely to be attracted to something new, something that could benefit them, if it also enhances their perception of autonomy, or at least, does not not seek to diminish their existing autonomy (e.g a C programmer might well be attracted to betterC, for example).

D should really focus more on marketing one of its biggest strenghts - increased autonomy (well, the perception of).

Getting back to the subject of this thread, that's why 'I' like D.

On Friday, 14 January 2022 at 02:13:48 UTC, H. S. Teoh wrote:
> It takes 10x the effort to write a shell-script substitute in C++ because at every turn the language works against me -- I can't avoid dealing with memory management issues at every turn -- should I use malloc/free and fix leaks / dangling pointers myself? Should I use std::autoptr? Should I use std::shared_ptr? Write my own refcounted pointer for the 15th time?  Half my APIs would be cluttered with memory management paraphrenalia, and half my mental energy would be spent fiddling with pointers instead of MAKING PROGRESS IN MY PROBLEM DOMAIN.
>
> With D, I can work at the high level and solve my problem long before I even finish writing the same code in C++.

Well C++ ships with unique_ptr and shared_ptr, you don't have to roll your own. And you can use them and be assured that the performance profile of your program doesn't suddenly collapse when the data/heap grows too big as these tools assure independence of the heap size. (What does D's GC assure you? That it won't run if you don't use it? That's such a low bar...)

Plus with D you cannot really work at the "high level" at all, it is full of friction. Is this data const? Or immutable? Is this @safe? @system? Should I use @nogc? Are exceptions still a good idea? Should I use interfaces or inheritance? Should I use class or struct? Pointers or inout? There are many languages where it's much easier to focus on the PROBLEM DOMAIN. Esp if the domain is "shell-script substitute".

On Friday, 14 January 2022 at 02:13:48 UTC, H. S. Teoh wrote:
> On Fri, Jan 14, 2022 at 01:19:01AM +0000, forkit via Digitalmars-d-announce wrote: [...]
>> [...]
> [...]
>> [...]
>
> How is using D "losing autonomy"?  Unlike Java, D does not force you to use anything. You can write all-out GC code, you can write @nogc code (slap it on main() and your entire program will be guaranteed to be GC-free -- statically verified by the compiler). You can write functional-style code, and, thanks to metaprogramming, you can even use more obscure paradigms like declarative programming.
>
> [...]

When languages are compared in grammar and semantics alone, you are fully correct.

Except we have this nasty thing called eco-system, where libraries, IDE tooling, OS, team mates, books, contractors, .... are also part of the comparisasion.

And in that regard it doesn't matter how great D is against C# 10, if C# 10 gets me 90% there with a legion of libraries, IDE tooling, OS, team mates, books,.... to help me getting there. Using C# version explicitly here, because since C# 7 the language has grown multiple features that used to be only on the D's side of the comparisasion.

Naturally C# 10 was only an example among several possible ones, that have a flowershing ecosytem and keep getting the features only D could brag about when Andrei's book came out 10 years ago.