digitalmars.D.learn - Is D overly complex?
- Brother Bill (15/15) Aug 05 I am in my learning curve for D as an experienced developer.
- monkyyy (15/22) Aug 05 "D the good parts", syntax should be learned in a few hours:
- user1234 (5/10) Aug 05 I think what you should get is that D is a language that
- Bradley Chatha (13/18) Aug 05 This is both one of the strong and weak points of D: It gives you
- IchorDev (39/50) Aug 05 D is invested in letting you program how you want, it is designed
- Kagamin (2/6) Aug 12 I think everything is ok as long as you keep it simple.
- Dejan Lekic (13/16) Aug 13 After little bit over 20 years of using D I believe I
I am in my learning curve for D as an experienced developer. What has attracted me to D is the combination of features: Design by Contract, Functional Programming, OOP, and more. But I have been exploring the "weeds" and am curious if D is only for rocket scientists or for regular programmers, including as a first programming language. It would be good to have a "style" document that showed the "best practices" and "Do's and Don'ts" of good D programming. Every language has its "nits", even Eiffel. The concern is whether that is a straight forward approach to get things done, avoid the "dragons", and work with existing libraries without needing a "wizard" to cast some spells. Should D be considered a language that should be learned in its entirety? Or should most developers stick to the "Safe D" subset?
Aug 05
monkyyy <crazymonkyyy gmail.com> On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:Every language has its "nits", even Eiffel. The concern is whether that is a straight forward approach to get things done, avoid the "dragons", and work with existing libraries without needing a "wizard" to cast some spells. Should D be considered a language that should be learned in its entirety?"D the good parts", syntax should be learned in a few hours: https://github.com/crazymonkyyy/dingbats Id probably delete over half of programming in d's chapters for beginner introductions. Im confused by the order. The true depths of template hell, is still unlearned *by anyone*; there are bugs that provide more capability then what upstream release is a few years that were undiscovered for 10 years, just there in how it was implemented.Or should most developers stick to the "Safe D" subset?Wrong boundary, its template hell vs c-like d Safe D will bring in complexity, those dips make problems hard to solve, "how do I write swap thats safe from dip 1000 1069 1337?" well thats an on going research project last I saw was 100 lines of code with criticisms about 5 edge cases, id just go with the 4 lines of code.
Aug 05
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:I am in my learning curve for D as an experienced developer. [...] Should D be considered a language that should be learned in its entirety? Or should most developers stick to the "Safe D" subset?I think what you should get is that D is a language that "clicks". That means that you have previous experience with other languages. They can be more complex than D but also sometimes less complex. So often that just "clicks".
Aug 05
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:I am in my learning curve for D as an experienced developer. What has attracted me to D is the combination of features: Design by Contract, Functional Programming, OOP, and more.This is both one of the strong and weak points of D: It gives you a ton of flexibility and lets you model code in a fairly free-form way, unlike languages like Go where variety between codebases is very minimalised.It would be good to have a "style" document that showed the "best practices" and "Do's and Don'ts" of good D programming.There's things like The D Style guide (https://dlang.org/dstyle.html) which is used for Phobos, and there's the slightly crusty D Idioms list (https://p0nce.github.io/d-idioms/) going over a bunch of misc stuff. I initially had more to say, but monkyyy's answer kind of eludes to it - there's many different ways to use D (half baked or not) to the point nothing can truly work together in exact harmony.
Aug 05
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:I am in my learning curve for D as an experienced developer. What has attracted me to D is the combination of features: Design by Contract, Functional Programming, OOP, and more. But I have been exploring the "weeds" and am curious if D is only for rocket scientists or for regular programmers, including as a first programming language. It would be good to have a "style" document that showed the "best practices" and "Do's and Don'ts" of good D programming.D is invested in letting you program how you want, it is designed to allow many different programming styles to co-exist. You can go full C procedural style, or opt for a more functional style, or use OO, or any combination of the three. None of these ways is wrong or right. My only word of advice is to consider using structs over classes when passing around small amounts of data. A lot of D newbies use classes for everything and ignore structs as if they don't exist. Also check out [`std.sumtype`](https://dlang.org/phobos/std_sumtype.html) if you ever need tagged unions. It's really useful for a lot of stuff!Should D be considered a language that should be learned in its entirety?For fun, yes. But if you get started and learn as you go then you'll probably pick up the vast majority of it. And the stuff you don't learn is probably not important to you. For example, if you use OO a lot then you will probably barely touch D's incredibly rich (and complex!) meta-programming. Things I recommend familiarising yourself with are: - the range interface & what ranges are (`front`, `popFront`, `empty`) - how strings work in D (they're arrays of `immutable char`, where `char` is a UTF-8 code unit—not to be confused with a UTF-8 code point) - what slices are (AKA 'dynamic arrays') and how/when mutating GC-allocated slices causes them to be re-allocated - other things you need to know to get your work done. If you need to process data, like splitting by comma, sorting, etc. then get familiar with `std.algorithm`. If your work requires lots of maths then get familiar with `std.math`. - a lot of Phobos functions are named a bit oddly, so sometimes you have to rummage a little to find what you want, or you might not realise that it's there.Or should most developers stick to the "Safe D" subset?If you are doing web development, yes. If you are a low-level systems programmer or game developer, then try to use ` safe` on as much of your code as possible, but you will be calling ` system` functions in a lot of places to get your job done. (e.g. kernel, SDL, etc.) I recommend checking out the new [`-preview=safer`](https://dlang.org/changelog/2.111.0.html#dmd.safer) as well if this interests you. And remember: if you misuse ` trusted`, then ` safe` will not save you.
Aug 05
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:Every language has its "nits", even Eiffel. The concern is whether that is a straight forward approach to get things done, avoid the "dragons", and work with existing libraries without needing a "wizard" to cast some spells.I think everything is ok as long as you keep it simple.
Aug 12
On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:Should D be considered a language that should be learned in its entirety? Or should most developers stick to the "Safe D" subset?After little bit over 20 years of using D I believe I learned/used 60% of language features. - There are lots of things I either do not need, or do not like, that I do not use. Language is a tool, right - you use it the way you prefer to use it. My intention was never to become a D language expert. I just want to implement my next planned feature of my D application in a way that suits me. That is why always my recommendation for developers who are using new language is - think of something "you need", and implement that in this language. As long as you progress you will learn those language features that you need, and that is all that matters.
Aug 13