On 02/09/2018 02:54 AM, Suliman wrote:
I like D, but sometimes it's look like for me too complicated. Go have a
lot of fans even it not simple, but primitive. But some D futures make
it very hard to learning.
Small list by me:
3. too many attributes like: @safe @system @nogc etc
Which language futures by your opinion make D harder?
And yes, things like "inout", "auto ref" or whatever, and such, strike
me as indicative of more fundamental design flaws. (Not "flaw" in the
sence of "mistakes" necessarily, but "flaw" in the sence of "there must
be a better way to design these things...")
Aside from that, I don't think features inherently make D complicated,
but I do think there are features that are designed or implemented in
overly-complicated ways. Or *missing* features, which by their absence
make the langauge more complicated.
The biggest, by far, that comes to my mind is dealing with types:
- At runtime: Dealing with type infos at runtime is a mess compared to
many other langauges (especially dynamic ones).
- At compile time: The mechanisms for dealing with type info at compile
time seem...undesigned. It's kind of a clutter of various approaches and
haphazard quirks, and std.traits is a testament that it's not very
cleanly designed at the language-level.
- RT vs CT: The interfaces for dealing with types are completely 100%
different depending whether you're working with runtime or compile-time.
Other things that come to mind:
Defining input ranges (one of my biggest pet peeves):
C# knocked it out of the park ages ago with its design for a
stackless!!! (ie no-fibers) coroutine syntax. There's no reason the same
approach couldn't be used in D for creating input ranges. But instead, D
forces input ranges to be defined the same way as random-access ranges,
which is a PITA (a necessary PITA for random-access, but unnecessary for
mere generators like input ranges), and D provides no way around that
without introducing the overhead of fibers. Even an old version of C#
from ten years ago puts us to complete shame here.
And Algebraic types. Yes, we technically have them, but compared to
something like Nemerle, D claiming to have algebraic or pattern matching
is like C claiming to support OO:
Umm...sorta...technically...kinda...but...uhhh...no, not really.