| ▲ | WalterBright a day ago |
| With D you don't have to use multiple languages, such as mixing Python with C. D is The One Language to Rule Them All. (D's ability to use C code is to make use of existing C code. There's not much point to writing C code to use with D.) |
|
| ▲ | dataflow a day ago | parent | next [-] |
| > D is The One Language to Rule Them All. That's kind of why I said it's the "jack of all trades". It's not a bad language, it just doesn't beat any existing languages I know of in their own niches (hence "master of none"), so few people are going to find it useful to drop any existing languages and use D in lieu of them. |
| |
| ▲ | jibal a day ago | parent [-] | | It's amusing to see someone telling the designer and implementer of a language that he has put decades of effort into that "it's not a bad language". | | |
| ▲ | WalterBright a day ago | parent | next [-] | | I often hear a lot worse :-) No worries, it doesn't bother me. What pleases me are the people who use D, like it, and tell me they make more money using D because D is much more productive to write code in. D also attracts expert programmers who are very comfortable using the GC when appropriate, stack allocation when appropriate, malloc/free, even ref counting. These are just tools in the toolbox, like I use socket wrenches, end wrenches, box wrenches, crow foot wrenches, pipe wrenches, monkey wrenches, etc. I don't try to use socket wrenches for everything. BTW, the GC makes managing memory in compile time function execution trivial. Something that non-GC languages struggle with. | | |
| ▲ | dataflow 19 hours ago | parent [-] | | > What pleases me are the people who use D, like it, and tell me they make more money using D because D is much more productive to write code in. I guess what I've been trying to say is that you would find yourself pleased much, much more often (and D being much more successful) if you recognized and addressed these high-level issues that people have been pointing out for decades, instead of denying them and going on forums telling customers why their expectations are wrong or unnecessary. I'm saying this because D really is a great piece of technology that got a lot of things right, except a few crucial details for some of the most crucial users. And it has had so much potential - potential that has been gradually lost largely because you haven't even recognized the flaws and hurdles that come with it. It remind me of the infamous Dropbox comment. It's as if you invented FTP, but then whenever people told you it's hard to store & share files, you kept insisting that it's trivial with just a few simple steps on Linux, completely missing the massive market opportunity and the barriers you're telling people to walk through. https://news.ycombinator.com/item?id=9224 And I'm not saying all this out of out hate for D, but out of (at least past) love for it. I desperately wanted to see it succeed, but I gave up because I realized you simply did not see the Achilles heel that frustrates many of its users and that has held back its potential. | | |
| ▲ | WalterBright 15 hours ago | parent [-] | | Anyone is free to propose things for D, we have a process for it, or you can just post your idea in the D forum. Many do. You don't have to sit back and hope someone else does it. |
|
| |
| ▲ | tialaramex a day ago | parent | prev [-] | | It's better than the feedback I would have for, to give an example, Bjarne Stroustrup. Bjarne has spent so far as I can tell almost all of his adult life on C++. It's a huge bloated mess, and though there are many other guilty parties I don't think I can even say he was a good influence. | | |
| ▲ | jibal 6 hours ago | parent [-] | | You and Dataflow seem to have no idea how the real world works. |
|
|
|
|
| ▲ | quietbritishjim a day ago | parent | prev [-] |
| One of C++'s great weaknesses is that it is just a huge language with too much stuff in. There are lots of reasons why this is, not worth re-exploring, but the point stands. There is a great irony that a replacement to C++ should have lots of features in it. (Not necessarily the same too-many features.) One of the key requirements of a real C++ alternative would be fewer language features. |
| |
| ▲ | pjmlp a day ago | parent | next [-] | | It is telling that Ada and Rust are only ones that many people in the C++ community would ever consider. Because at the scale many companies use C++, the additions into ISO C++, for how bad WG21 process currently might be, don't land there because a group of academics found a cool feature, rather some company or individual has seen it as a must have feature for their industry. Sadly also a similar reason on how you end up with extension spaghetti on Khronos APIs, CSS levels or what have you. Naturally any wannabe C++ replacement to be taken seriously by such industries, has to offer similar flexibility in featuritis. | | |
| ▲ | quietbritishjim a day ago | parent [-] | | > Because at the scale many companies use C++, the additions into ISO C++, for how bad WG21 process currently might be, don't land there because a group of academics found a cool feature, rather some company or individual has seen it as a must have feature for their industry. Maybe it's just me but, sorry, I cannot parse this sentence. | | |
| ▲ | trealira a day ago | parent [-] | | I'm not them, but I'll try reordering the sentence to help you parse it better. As bad as the WG21 process might be, the additions into ISO C++ don't land there because a group of academics found a cool feature; they land there because some company or individual has seen it as a must-have feature for their industry. | | |
|
| |
| ▲ | feelamee a day ago | parent | prev [-] | | Why is a big number of features a problem? You can ignore them if you don't like/need them.
Can you briefly explain which features can be thrown out and language will not miss a lot without them? | | |
| ▲ | quietbritishjim a day ago | parent [-] | | > Why is a big number of features a problem? You can ignore them if you don't like/need them. You 100% cannot do that. I mean, you can if you're writing some toy project just for your own use. But as soon as you start interacting with other programmers, it's inevitable that some will use some other subset of language features. > Can you briefly explain which features can be thrown out and language will not miss a lot without them? I don't think that it's controversial that C++ is a huge language with many features, and I doubt I'm the best person to rehash that. One often quoted example is the multitude of ways to initialise a variable (Foo x = y; Foo x(y); Foo x = {y}; Foo x{y} and for default initialisation Foo x; Foo x = {}; Foo x{}; Foo x() (not really - that's the most vexing parse); Foo x = Foo()). There's multiple syntaxes to define a function including auto and decltype(auto) return types. There are const, consteval and constexpr - you may know the difference but I've forgotten. There are so many templating features that I wouldn't know where to start. Concepts are layered on top of that - which are useful and a good idea but no denying that it's layering extra complexity on top (which can be said for many C++ features). I've really just scratched the surface. The thing is, I learned C++ over 20 years ago, when the latest standard was C++03 (which was essentially the same as C++98). Even at the time, C++ seemed like a bit of a chunky language (e.g., compared to C or Object Pascal - languages tended to be simpler back then), but it was achievable to mostly understand it all. But each revision that passed has added a huge volume of features. So I really feel how big C++ is because it's even big compared to (an older version of) itself. I've mostly kept up over the years but I can't imagine how I would properly learn the language today from scratch - I feel like you don't really stand a chance unless you've also been closely following it for decades. |
|
|