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:
1. mixins
2. inout
3. too many attributes like: @safe @system @nogc etc

Which language futures by your opinion make D harder?


Auto-decode.

Dub.

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.

Reply via email to