181–190 of 211 posts
But I don't think D hasn't succeeded in replacing C++ for this reason; the reason D hasn't succeeded yet is because it's relatively unknown in the enterprise developers circle. Most people haven't heard of D.
Earlier quoted context omitted.
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 Ran…
auto natsBelow1000 = iota(1000); How do I pass this output to some other function without doing .array()? It's rare that you do all your processing in one method. Should I do this: void processFurther(T)(T t) if isInputRange!T { } ? I mean, it would probably work, but I don't like how the conditions are detached from type definitions :S
> I don't like how the conditions are detached from type definitions
I can understand that; it's something that takes a bit of getting used to. See https://dlang.org/concepts.html for an explanation of template constraints and why they were designed this way.
Earlier quoted context omitted.
The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3). So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.
Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.
Earlier quoted context omitted.
We actually do care about those benchmarks. At a certain scale it matters how many servers you need to run a website with millions of visitors. 90% of deployments do not have this problem, yet saying nobody cares is a bit silly.
At that scale do you use a stock framework though? An advantage of D in that situation is how easy it is to change the internals of an API without those changes propagating to the surface, both by design (e.g. UFCS, no brackets) and how that design is used (e.g. Templates)
Earlier quoted context omitted.
Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.
That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".
Earlier quoted context omitted.
Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.
That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".
Earlier quoted context omitted.
That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".
1. Because C has no shadowing of global variables by member variables? 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem. 3. C is a simplistic, almost-assembly-like, language. It's a reasonable choice for some tasks, not a reasonable choice for others. We're talking about languages with stronger abstraction capabilities.
Now tell me why every OOP codebase I look at has this problem. ;-)
The reason is the second "O" in OOP. Trying to switch on the type of a thing, where every thing has only one type (ignoring inheritance which is another problem, not a solution), means that people will put all sorts of unrelated things in one place.
Earlier quoted context omitted.
That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".
Ah the beauty of use-after-free and memory corruption issues. /s
Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.
Earlier quoted context omitted.
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... http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...
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…
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.