5 ms·

Yes, I spent 6mths with it. As with any programming langauge, if you do simple things, and do them often, then you'll probably have little to worry about. D ce

by WuHu 8y ago

Yes, I spent 6mths with it. As with any programming langauge, if you do simple things, and do them often, then you'll probably have little to worry about. D certainly makes many things simple for you. On the otherhand, the language has no personality that you get your head around. It tries to be everything to everyone. If you are presented with some code for D app, it's not possible to understand what 'style' programming you'll see, until you see it - because the language supports so many paradigms. Although, not all paradigms are faithfully represented. For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module. Any code in a module can change any part of your encapsulated classes. Then, you have the issue of public being the default. Then, you have the issue of class instances being able to share mutable data. And the list goes on..and on... and on.. If you've never programmed before, these might not be such a big deal, but if you're an experience programmers from a mainstream langauges, you'll spend a large amount of your time working out all these things for yourself, most of the time. I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D. It just does not make sense to me. Sure D does some interesting things. Other languages can learn and take from D, just as D has taken so much from other langauges. In the end, there is nothing in D that really changes the nature of programming. It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.

germandiago 8y ago
> On the otherhand, the language has no personality that you get your head around I do not get this point. I use D as a C++ improvement (which is what it was since the beginning) and I can do from functional, to OOP to structured or generic programming. No personality? You mean it does not favor any paradigm? That is another of the reasons why I chose it. By this measure, Nim is another non-personality language: the package offers the same things -> soft real-time gc, generic, structured and OOP (with Nim Style programming), metaprogramming. Should I say that Nim has no personality and conclude it is not useful? Nim is not useful due to "metaproblems" -> tools, maturity, worse interoperability than D. I do not say the language is not nice, I just say that it is more complicated to get things done with it from a perspective of someone looking for something that can work. Also, following Python makes it for very nice-looking code, but I am not sure it was the right decision from a social point of view (more people know C/C++ than know Python). > For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module I consider that a design mistake, but that does not preclude powerful metaprogramming or superior interoperability, which are far more important to my use case. > Then, you have the issue of class instances being able to share mutable data. I make primarily use of structs and all gc stuff and mutability problems disappear. > I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D The case for C++ is still very strong for me. But try to get good compile times and do something along the lines of static if (I do not mean only if constexpr in C++ with templates, try to avoid macros for config if you want and you will see, or add a conditional member to a class, or simulate something like version, or generate code without messing with macros) > In the end, there is nothing in D that really changes the nature of programming. That is a fair opinion, but I can say that in D there are these small nice things that I value in day-to-day programming like static if (a powerful one, not one that is in the middle between useful and full-featured), overloading opDispatch for forwarding, fast compile times and a module system. The faster compile-times are really, really something that makes more of an impact, maybe, than everything else. I understand your point, D has nothing "revolutionary". D is not revolution, it is evolution. But D is targeted at doing and using techniques that have been useful for years (and not experimental) easier and convenient: from memory allocation control to gc-free programming, immutability or better interoperability (something that should not be underestimated when using older code bases). I really think that people that see nothing "new" in D should try and see how the full package works together. They will be surprised. And they will also be surprised at how much of the older techniques, in improved versions, they can use. Techniques that have been useful for decades, not experiments of the last FP trends or experiments for which drawbacks are not well known. I used to think things along the lines you say. I still use C++ mainly, but, when I have another chance, I will insist on D a bit more. I think it is worth the time. > It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere. That is precisely the strong point of it. It is evolution, not revolution. Did anyone discover lately a better general programming paradigm suddenly that makes all the other obsolete? Not AFAIK. Packaging things in familiar ways has real advantages of lowering the learning curve or figuring out more easily how to interoperate with older code bases. As I said before, that should not be underestimated if you really want to get things done and deliver stuff. If you are just toying around maybe you enjoy more something more revolutionary. But if I have to get things finished, I would bet on D rather than Nim or Go for most use cases.
- dom96 8y ago
  You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it? Once again. Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. For C++ interoperability this is a huge benefit. I'd love to hear why you disagree if you do disagree. Otherwise please give Nim a try and stop spreading this as a disadvantage of Nim.
  - germandiago 8y ago
    > You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it? I did not downvote anyone unless it was an accident :) > Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. I did not try myself. Well, I did not try Nim to the level I tried D, starting bc I know C++ better than D, though I also know quite a bit of Python (my "second" language). I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) You thought very bad about me and the downvotes before.
    - dom96 8y ago
      > I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it. Because Nim compiles to C++ it can interface with it incredibly well. Happy to answer any more questions in case I'm not clear. > You thought very bad about me and the downvotes before. Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)
p0nce 8y ago
D has _split_ or _multiple_ personalities which makes it very flexible.

by WuHu 8y ago

germandiago 8y ago

> On the otherhand, the language has no personality that you get your head around I do not get this point. I use D as a C++ improvement (which is what it was since the beginning) and I can do from functional, to OOP to structured or generic programming. No personality? You mean it does not favor any paradigm? That is another of the reasons why I chose it. By this measure, Nim is another non-personality language: the package offers the same things -> soft real-time gc, generic, structured and OOP (with Nim Style programming), metaprogramming. Should I say that Nim has no personality and conclude it is not useful? Nim is not useful due to "metaproblems" -> tools, maturity, worse interoperability than D. I do not say the language is not nice, I just say that it is more complicated to get things done with it from a perspective of someone looking for something that can work. Also, following Python makes it for very nice-looking code, but I am not sure it was the right decision from a social point of view (more people know C/C++ than know Python). > For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module I consider that a design mistake, but that does not preclude powerful metaprogramming or superior interoperability, which are far more important to my use case. > Then, you have the issue of class instances being able to share mutable data. I make primarily use of structs and all gc stuff and mutability problems disappear. > I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D The case for C++ is still very strong for me. But try to get good compile times and do something along the lines of static if (I do not mean only if constexpr in C++ with templates, try to avoid macros for config if you want and you will see, or add a conditional member to a class, or simulate something like version, or generate code without messing with macros) > In the end, there is nothing in D that really changes the nature of programming. That is a fair opinion, but I can say that in D there are these small nice things that I value in day-to-day programming like static if (a powerful one, not one that is in the middle between useful and full-featured), overloading opDispatch for forwarding, fast compile times and a module system. The faster compile-times are really, really something that makes more of an impact, maybe, than everything else. I understand your point, D has nothing "revolutionary". D is not revolution, it is evolution. But D is targeted at doing and using techniques that have been useful for years (and not experimental) easier and convenient: from memory allocation control to gc-free programming, immutability or better interoperability (something that should not be underestimated when using older code bases). I really think that people that see nothing "new" in D should try and see how the full package works together. They will be surprised. And they will also be surprised at how much of the older techniques, in improved versions, they can use. Techniques that have been useful for decades, not experiments of the last FP trends or experiments for which drawbacks are not well known. I used to think things along the lines you say. I still use C++ mainly, but, when I have another chance, I will insist on D a bit more. I think it is worth the time. > It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere. That is precisely the strong point of it. It is evolution, not revolution. Did anyone discover lately a better general programming paradigm suddenly that makes all the other obsolete? Not AFAIK. Packaging things in familiar ways has real advantages of lowering the learning curve or figuring out more easily how to interoperate with older code bases. As I said before, that should not be underestimated if you really want to get things done and deliver stuff. If you are just toying around maybe you enjoy more something more revolutionary. But if I have to get things finished, I would bet on D rather than Nim or Go for most use cases.

dom96 8y ago
You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it? Once again. Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. For C++ interoperability this is a huge benefit. I'd love to hear why you disagree if you do disagree. Otherwise please give Nim a try and stop spreading this as a disadvantage of Nim.
- germandiago 8y ago
  > You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it? I did not downvote anyone unless it was an accident :) > Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. I did not try myself. Well, I did not try Nim to the level I tried D, starting bc I know C++ better than D, though I also know quite a bit of Python (my "second" language). I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) You thought very bad about me and the downvotes before.
  - dom96 8y ago
    > I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it. Because Nim compiles to C++ it can interface with it incredibly well. Happy to answer any more questions in case I'm not clear. > You thought very bad about me and the downvotes before. Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)

p0nce 8y ago

D has _split_ or _multiple_ personalities which makes it very flexible.