Why I Like D

[H. S. Teoh]

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