14 ms·

As someone who has only somewhat recently started using D, I would love to see this language succeed. It's been such a pleasure to use.. scope guards, string m

by ktm5j 7y ago

As someone who has only somewhat recently started using D, I would love to see this language succeed. It's been such a pleasure to use.. scope guards, string mixin, inline json & std.json. It's been so useful for the code I write at work. Much love for D The one thing I would add to this list is documentation! There is a lot of good documentation available, but not for everything you would expect. For example, I had a hard time figuring out the behavior of sub-packages within a dub package. Some more explicit documentation on this subject would have been appreciated.

jordigh 7y ago
I find that D is about as easy as Python to get into. Being able to use rdmd as a shebang makes D almost feel like as scripting language. A lot of Python was also pretty easy for me to directly translate into D. Here is an example: http://inversethought.com/hg/medcouple/file/tip/medcouple.py#l94 http://inversethought.com/hg/medcouple/file/tip/medcouple.py... http://inversethought.com/hg/medcouple/file/tip/medcouple.d#l79 http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...
- skocznymroczny 7y ago
  While I enjoy using D, I find it hard to use at times. Especially if someone isn't a C++ veteran, as soon as heavy template usage comes into play I get confused, and error messages are useless because it's several screens of errors with multiple isX() && !isY() && isZ() conditions for types. Most of the standard library function calls return some opaque Result type which isn't obvious how to progress from. Only after some googling you'll learn that if you import std.array you can use .array() on the Result and get something usable. Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it.
  - jordigh 7y ago
    Yes, there's an extra barrier with D because of type checking, but in exchange, you get compile-time checks. I actually kind of like those template errors because they tell you what kind of Python-like compile-time duck-typing D is trying to use! Oh, and you can also use type deductions for function declarations! Just make it a template and let D figure out for you what type you want, or use typeof to record the type you want and use that typename in your function declaration.
    - axaxs 7y ago
      That second feature sounds really neat. I'd always wished Go had implemented something like this, even if just for numeric types.
      - cppforlife 7y ago
        just use a wrong type (bool lets say), and check out go compilation error. it will tell you what type it wants.
  - abaga129 7y ago
    Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.
    - jordigh 7y ago
      It's not the best idea to always unconditionally use .array because you might want to preserve the laziness of a Result type. By using .array you're saying you want all of the results into memory right now! Depending on what you're doing, you might not want that.
      - abaga129 7y ago
        I actually didn't know this! Very cool. I guess it's similar to calling .ToList() on IEnumerable<T> in C#.
        p0nce 7y ago
        Most range function return a "Voldemort" that preserve lazyness if you put it in an `auto` local. Or you can use .array to get a slice out of it.
    - anaphor 7y ago
      On the other hand, I like the explicitness of it instead of automatically converting to a different type. At least you know exactly what it's doing. The python version of it would be calling `list()` on things all the time, which you might not always want to do.
      - abaga129 7y ago
        That's a fair point. I'm not necessarily against having to do it, I just would like there to be a more obvious indication of how to convert the result to an array. It took a lot of searching the first time I came across this. Perhaps it's just my own incompetence though!
  - 7thaccount 7y ago
    I also have this problem. I find part of D is easy like Python, but all the template jargon is over my head.
  - anaphor 7y ago
    I've written like one C++ program in my life and I had no problems figuring it out. Although I write C somewhat frequently and have done a lot of Haskell stuff. I think experience with any statically typed language is going to make it easier to learn another one.
  - EvenThisAcronym 7y ago
    Let me give you a little guidance on this (if you happen to still be using D). Most functions in std.algorithm (and many more throughout the rest of the standard library) return "ranges", which is like a begin iterator and an end iterator zipped up into one data structure. There is a "range hierarchy" that mirrors the C++ iterator hierarchy: Input/Output Range > Forward Range > Bidirectional Range > Random Access Range Input ranges provide the following API: bool empty() T front() void popFront() Forward ranges provide the same API, and also add a "save" function that creates a copy of the range's current state. Bidirectional ranges add "back" and "popBack" functions, which don't really need any explanation. Random access ranges additionally add a "length" function and constant-time array-like indexing. In addition to most functions in std.algorithm _returning_ ranges, most of them also _accept_ ranges. Therefore, you can freely pass the result of any function in std.algorithm into another function that takes a range, and it should all just work. It's pretty much the same deal as in Rust/Java/Swift/etc. with their various iterator protocols, although the API for ranges in D is more influenced by C++. For example, the first Project Euler problem, using a range-based approach: import std.algorithm; import std.range; import std.stdio; void main() { //List all the natural numbers below 1000 that are multiples of 3 or 5 auto natsBelow1000 = iota(1000); //iota returns a range that lazily computes the numbers from 0-999 auto multiplesOf3Or5 = natsBelow1000.filter!(n => n % 3 == 0 || n % 5 == 0); //filter accepts a range as an argument, which it lazily filters according to the given predicate auto sum = multiplesOf3Or5.sum(); //Sum accepts a range of "summable" items and computes the... sum writeln(sum); //Prints 233168 } A D programmer wouldn't generally write things this way, preferring to make a more idiomatic "range chain" like you'd see with Java's streams or Rust's iterators, but you get the idea. As you might have guessed, arrays are also ranges - random access ranges - which is why they're so easy to use. I would highly recommend against putting `.array` everywhere in your code, as it will force the range you pass to it to be eagerly evaluated and allocate more memory from the GC. It's much better to take some initial data store, like an array, do all your filtering and mapping, etc. on it, and when you're done, _then_ turn it back into an array with a call to `.array`. That way you'll get all the lazy iteration and low memory footprint of ranges, and then at the end you have a nicely allocated array of data with the result that is easy to work with. Honestly, though, in most of my code I usually just pass around ranges as they're very good for creating interlocking adapters over different backing stores. One really great article on advanced usage of ranges is H. S. Teoh's article on Component Programming with Ranges: https://wiki.dlang.org/Component_programming_with_ranges https://wiki.dlang.org/Component_programming_with_ranges A couple great resources on ranges in D: http://www.informit.com/articles/printerfriendly/1407357 http://www.informit.com/articles/printerfriendly/1407357 https://tour.dlang.org/tour/en/basics/ranges https://tour.dlang.org/tour/en/basics/ranges http://ddili.org/ders/d.en/ranges.html http://ddili.org/ders/d.en/ranges.html http://dconf.org/2015/talks/davis.html http://dconf.org/2015/talks/davis.html
  - mhh__ 7y ago
    > Most of the standard library function calls return some opaque Result type This is by design, e.g. map could not be lazy if it returned an array. > Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it. templates, void use(T)(T x) [auto ref if you feel fancy]
  - ttkciar 7y ago
    For what it's worth, I'm a long-time C programmer, but have piss-poor C++ skills, and despise C++, and D clicked for me immediately. I'm loving it. Whether D "clicks" for someone might be more a matter of subjective taste than what languages they're used to. As for D templates, they puzzled me until I read Andrei's D Programming book, which made everything clear. They're less narrow than C++ templates, more like directives for a syntax/scope-aware C preprocessor. You can use them for more than just polymorphic functions; they're a way to pass source code around the program at compile-time, for almost any purpose whatsoever.
7thaccount 7y ago
Yes on documentation. They have a beginner's book and everything else is pretty advanced or reference material. Some additional intermediate content would be good like how the Julia project does it.
- anaphor 7y ago
  the #d channel on freenode is extremely helpful and knowledgeable though, which helped fill the gaps for me personally.
- pjmlp 7y ago
  There are a couple of good D books on Packt. https://www.packtpub.com/application-development/d-cookbook https://www.packtpub.com/application-development/d-cookbook https://www.packtpub.com/web-development/d-web-development https://www.packtpub.com/web-development/d-web-development https://www.packtpub.com/application-development/learning-d https://www.packtpub.com/application-development/learning-d Plus buying them is a way to support some community members.

by ktm5j 7y ago

jordigh 7y ago

I find that D is about as easy as Python to get into. Being able to use rdmd as a shebang makes D almost feel like as scripting language. A lot of Python was also pretty easy for me to directly translate into D. Here is an example: http://inversethought.com/hg/medcouple/file/tip/medcouple.py#l94 http://inversethought.com/hg/medcouple/file/tip/medcouple.py... http://inversethought.com/hg/medcouple/file/tip/medcouple.d#l79 http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...

skocznymroczny 7y ago
While I enjoy using D, I find it hard to use at times. Especially if someone isn't a C++ veteran, as soon as heavy template usage comes into play I get confused, and error messages are useless because it's several screens of errors with multiple isX() && !isY() && isZ() conditions for types. Most of the standard library function calls return some opaque Result type which isn't obvious how to progress from. Only after some googling you'll learn that if you import std.array you can use .array() on the Result and get something usable. Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it.
- jordigh 7y ago
  Yes, there's an extra barrier with D because of type checking, but in exchange, you get compile-time checks. I actually kind of like those template errors because they tell you what kind of Python-like compile-time duck-typing D is trying to use! Oh, and you can also use type deductions for function declarations! Just make it a template and let D figure out for you what type you want, or use typeof to record the type you want and use that typename in your function declaration.
  - axaxs 7y ago
    That second feature sounds really neat. I'd always wished Go had implemented something like this, even if just for numeric types.
    - cppforlife 7y ago
      just use a wrong type (bool lets say), and check out go compilation error. it will tell you what type it wants.
- abaga129 7y ago
  Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.
  - jordigh 7y ago
    It's not the best idea to always unconditionally use .array because you might want to preserve the laziness of a Result type. By using .array you're saying you want all of the results into memory right now! Depending on what you're doing, you might not want that.
    - abaga129 7y ago
      I actually didn't know this! Very cool. I guess it's similar to calling .ToList() on IEnumerable<T> in C#.
      - p0nce 7y ago
        Most range function return a "Voldemort" that preserve lazyness if you put it in an `auto` local. Or you can use .array to get a slice out of it.
  - anaphor 7y ago
    On the other hand, I like the explicitness of it instead of automatically converting to a different type. At least you know exactly what it's doing. The python version of it would be calling `list()` on things all the time, which you might not always want to do.
    - abaga129 7y ago
      That's a fair point. I'm not necessarily against having to do it, I just would like there to be a more obvious indication of how to convert the result to an array. It took a lot of searching the first time I came across this. Perhaps it's just my own incompetence though!
- 7thaccount 7y ago
  I also have this problem. I find part of D is easy like Python, but all the template jargon is over my head.
- anaphor 7y ago
  I've written like one C++ program in my life and I had no problems figuring it out. Although I write C somewhat frequently and have done a lot of Haskell stuff. I think experience with any statically typed language is going to make it easier to learn another one.
- EvenThisAcronym 7y ago
  Let me give you a little guidance on this (if you happen to still be using D). Most functions in std.algorithm (and many more throughout the rest of the standard library) return "ranges", which is like a begin iterator and an end iterator zipped up into one data structure. There is a "range hierarchy" that mirrors the C++ iterator hierarchy: Input/Output Range > Forward Range > Bidirectional Range > Random Access Range Input ranges provide the following API: bool empty() T front() void popFront() Forward ranges provide the same API, and also add a "save" function that creates a copy of the range's current state. Bidirectional ranges add "back" and "popBack" functions, which don't really need any explanation. Random access ranges additionally add a "length" function and constant-time array-like indexing. In addition to most functions in std.algorithm _returning_ ranges, most of them also _accept_ ranges. Therefore, you can freely pass the result of any function in std.algorithm into another function that takes a range, and it should all just work. It's pretty much the same deal as in Rust/Java/Swift/etc. with their various iterator protocols, although the API for ranges in D is more influenced by C++. For example, the first Project Euler problem, using a range-based approach: import std.algorithm; import std.range; import std.stdio; void main() { //List all the natural numbers below 1000 that are multiples of 3 or 5 auto natsBelow1000 = iota(1000); //iota returns a range that lazily computes the numbers from 0-999 auto multiplesOf3Or5 = natsBelow1000.filter!(n => n % 3 == 0 || n % 5 == 0); //filter accepts a range as an argument, which it lazily filters according to the given predicate auto sum = multiplesOf3Or5.sum(); //Sum accepts a range of "summable" items and computes the... sum writeln(sum); //Prints 233168 } A D programmer wouldn't generally write things this way, preferring to make a more idiomatic "range chain" like you'd see with Java's streams or Rust's iterators, but you get the idea. As you might have guessed, arrays are also ranges - random access ranges - which is why they're so easy to use. I would highly recommend against putting `.array` everywhere in your code, as it will force the range you pass to it to be eagerly evaluated and allocate more memory from the GC. It's much better to take some initial data store, like an array, do all your filtering and mapping, etc. on it, and when you're done, _then_ turn it back into an array with a call to `.array`. That way you'll get all the lazy iteration and low memory footprint of ranges, and then at the end you have a nicely allocated array of data with the result that is easy to work with. Honestly, though, in most of my code I usually just pass around ranges as they're very good for creating interlocking adapters over different backing stores. One really great article on advanced usage of ranges is H. S. Teoh's article on Component Programming with Ranges: https://wiki.dlang.org/Component_programming_with_ranges https://wiki.dlang.org/Component_programming_with_ranges A couple great resources on ranges in D: http://www.informit.com/articles/printerfriendly/1407357 http://www.informit.com/articles/printerfriendly/1407357 https://tour.dlang.org/tour/en/basics/ranges https://tour.dlang.org/tour/en/basics/ranges http://ddili.org/ders/d.en/ranges.html http://ddili.org/ders/d.en/ranges.html http://dconf.org/2015/talks/davis.html http://dconf.org/2015/talks/davis.html
- mhh__ 7y ago
  > Most of the standard library function calls return some opaque Result type This is by design, e.g. map could not be lazy if it returned an array. > Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it. templates, void use(T)(T x) [auto ref if you feel fancy]
- ttkciar 7y ago
  For what it's worth, I'm a long-time C programmer, but have piss-poor C++ skills, and despise C++, and D clicked for me immediately. I'm loving it. Whether D "clicks" for someone might be more a matter of subjective taste than what languages they're used to. As for D templates, they puzzled me until I read Andrei's D Programming book, which made everything clear. They're less narrow than C++ templates, more like directives for a syntax/scope-aware C preprocessor. You can use them for more than just polymorphic functions; they're a way to pass source code around the program at compile-time, for almost any purpose whatsoever.

7thaccount 7y ago

Yes on documentation. They have a beginner's book and everything else is pretty advanced or reference material. Some additional intermediate content would be good like how the Julia project does it.

anaphor 7y ago
the #d channel on freenode is extremely helpful and knowledgeable though, which helped fill the gaps for me personally.
pjmlp 7y ago
There are a couple of good D books on Packt. https://www.packtpub.com/application-development/d-cookbook https://www.packtpub.com/application-development/d-cookbook https://www.packtpub.com/web-development/d-web-development https://www.packtpub.com/web-development/d-web-development https://www.packtpub.com/application-development/learning-d https://www.packtpub.com/application-development/learning-d Plus buying them is a way to support some community members.