On Fri, Jan 14, 2022 at 06:20:58AM +0000, Araq via Digitalmars-d-announce wrote:
> 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.
That's not entirely accurate. Using unique_ptr or shared_ptr does not guarantee you won't get a long pause when the last reference to a large object graph goes out of scope, for example, and a whole bunch of dtors get called all at once. In code that's complex enough to warrant shared_ptr, the point at which this happens is likely not predictable (if it was, you wouldn't have needed to use shared_ptr).
> (What does D's GC assure you? That it won't run if you don't use it?
> That's such a low bar...)
When I'm writing a shell-script substitute, I DON'T WANT TO CARE about memory management, that's the point. I want the GC to clean up after me, no questions asked. I don't want to spend any time thinking about memory allocation issues. If I need to manually manage memory, *then* I manually manage memory and don't use the GC. D gives me that choice. C++ forces me to think about memory allocation WHETHER I WANT TO OR NOT.
And unique_ptr/shared_ptr doesn't help in this department, because their use percolates through all of my APIs. I cannot pass a unique_ptr to an API that receives only shared_ptr, and vice versa, without jumping through hoops. Having a GC lets me completely eliminate memory management concerns from my APIs, resulting in cleaner APIs and less time wasted fiddling with memory management. It's a needless waste of time. WHEN performance demands it, THEN I can delve into the dirty details of how to manually manage memory. When performance doesn't really matter, I don't care, and I don't *want* to care.
> 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?
When I'm writing a shell-script substitute, I don't care about const/immutable or @safe/@system. Let all data be mutable for all I care, it doesn't matter. @nogc is a waste of time in shell-script substitutes. Just use templates and let the compiler figure out the attributes for you.
When I'm designing something longer term, *then* I worry about const/immutable/etc.. And honestly, I hardly ever bother with const/immutable, because IME they just become needless encumbering past the first few levels of abstraction. They preclude useful things like caching, lazy initialization, etc., and are not worth the effort except for leaf-node types. There's nothing wrong with mutable by default in spite of what academic types tell you.
> Are exceptions still a good idea?
Of course it's a good idea. Esp in a shell-script substitute, where I don't want to waste my time worrying about checking error codes and all of that nonsense. Just let it throw an exception and die when something fails, that's good enough.
If exceptions ever become a problem, you're doing something wrong. Only in rare cases do you actually need nothrow -- in hotspots identified by a profiler where try-blocks actually make a material difference. 90% of code doesn't need to worry about this.
> Should I use interfaces or inheritance? Should I use class or struct?
For shell script substitutes? Don't even bother with OO. Just use structs and templates with attribute inference, job done.
Honestly, even for most serious programs I wouldn't bother with OO, unless the problem domain actually maps well onto the OO paradigm. Most problem domains are better handled with data-only types and external operations on them. Only for limited domains OO is actually useful. Even many polymorphic data models are better handled in other ways than OO (like ECS for runtime dynamic composition).
> Pointers or inout?
inout is a misfeature. Avoid it like the plague.
As for pointers vs. non-pointers: thanks to type inference and `.` working for both pointers and non-pointers, most of the time you don't even need to care. I've written lots of code where I started with a non-pointer and later decided to change it to a pointer (or vice versa) -- most of the code that works with it doesn't even need to be changed, I just change the type definition, and maybe 1 or 2 places where the difference actually matters, and type inference takes care of the rest. No such nonsense as needing to change '.' to '->' in 50 different places, or respell types in 25 different modules scattered across the program. `auto` and templated types are your friend. Let the compiler figure out what the concrete types are -- that's its job, the human shouldn't need to constantly fiddle with this manually except in a few places.
> There are many languages where it's much easier to focus on the PROBLEM DOMAIN. Esp if the domain is "shell-script substitute".
I'm curious. Do you have any actual examples to show?
T
--
Some days you win; most days you lose.
| 
Permalink
Reply
