On Fri, Jan 14, 2022 at 03:51:17AM +0000, forkit via Digitalmars-d-announce wrote: > 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).
IMO, 'autonomy' isn't the notion you're looking for. The word I prefer to use is *empowerment*. A programming language should be a toolbox filled with useful tools that you can use to solve your problem. It should not be a straitjacket that forces you to conform to what its creators decided is good for you (e.g., Java), nor should it be a minefield full of powerful but extremely dangerous explosives that you have to be very careful not to touch in the wrong way (e.g., C++). It should let YOU decide what's the best way to solve a problem -- and give you the tools to help you on your way. I mean, you *can* write functional-style code in C if you really, really wanted to -- but you will face a lot of friction and it will be a constant uphill battle. The result will be a huge unmaintainable mess. With D, UFCS gets you 90% of the way there, and the syntax is even pleasant to read. Functional not your style? No problem, you can do OO too. Or just plain ole imperative. Or all-out metaprogramming. Or a combination of all four -- the language lets you intermingle all of them in the *same* piece of code. I've yet to find another language that actively *encourages* you to mix multiple paradigms together into a seamless whole. Furthermore, the language should empower you to do what it does -- for example, user-defined types ought to be able to do everything built-in types can. Built-in stuff shouldn't have "magical properties" that cannot be duplicated in a user-defined type. The language shouldn't hide magical properties behind a bunch of opaque, canned black-box solutions that you're not allowed to look into. The fact that D's GC is written in D, for example, is a powerful example of not hiding things behind opaque black-boxes. You can, in theory, write your own GC and use that instead of the default one. D doesn't completely meet my definition of empowerment, of course, but it's pretty darned close -- closer than any other language I've used. That's why I'm sticking with it, in spite of various flaws that I'm not going to pretend don't exist. As for why anyone would choose something over another -- who knows. My own choices and preferences have proven to be very different from the general population, so I'm not even gonna bother to guess how anyone else thinks. T -- English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall
