3 ms·

> The feature bloat makes it very hard to learn D, let alone being an expert on it. Learning 100% of any programming language should not be a goal. I know less

by Ace17 7y ago

> The feature bloat makes it very hard to learn D, let alone being an expert on it. Learning 100% of any programming language should not be a goal. I know less than 10% of the functionalities of my microwave oven or my washing machine. This doesn't prevent me from successfully using them and save a lot of time. Bjarne Stroustrup himself says learning all the nitty-gritty details of C++ is counterproductive and unnecessary.

mehrdadn 7y ago
Weird, because I agree with the general sentiment, yet with C++ I feel you have to learn most of the language if you want to be productive with it...
astrobe_ 7y ago
The problem with feature bloat is related to a very well known fact: Code is read more often than it is written. As a consequence, if you don't know the little details of a language, it might be a harder to read code written by someone else that is more knowledgeable. Consider for instance Lua, which is often read by people that have superficial knowledge of the language. Lua has a very standard syntax that anyone with basic general programming knowledge will understand: > player:set_pos({x=0, y=0}) But it also has syntactic sugar: > player:set_pos{x=0, y=0} -- note the braces instead of parens This is where you lose half of your readers because they have to look for that weird syntax in the manual. In defense of language implementers, it is sometimes difficult to "resist" feature requests. It's difficult to say "no" in general, in particular when you are not Niklaus Wirth and have half a dozen languages designs on your resumé; all you have is your gut feelings as justification.
- Ace17 7y ago
  I have 15 years experience as a professional C++ programmer in various teams and companies (and although I don't know 100% of C++17, I consider myself productive!). When diving into new codebases, the couple of esoteric-used-features-you-did-not-know-existed in C++ was never a big deal. Learning the required C++ features was always a matter of days (because the codebase is full of real examples). Understanding the overall structure of the code, the interactions/dependencies between the components, in what file/directory should go your first feature... this is the hard part. And it's many orders of magnitude harder than learning a couple of new language features. Don't get me wrong, I'd really like that C++ and D be smaller, and I don't like feature bloat. I once wrote a source code processor based on clang, and then you realize how big the language really is (there are many AST node types), and having all your code written in it starts to feel like technical debt. However, I pragmatically have to recognize that feature bloat isn't a real problem for professional C++ programmers (It might be, for compiler vendors - at this point, I'm not expecting any new C++ compiler to be created). PS1: C++ certainly gives you some shiny tools to make interesting messes (I've seen codebases where simply including a header would change the program behavior). This isn't related to the feature count, but rather to the semantic of the individual features themselves, like macros/templates. At least we don't have monkey patching ... PS2: About your Lua example: even without knowing the syntax, can you sincerely have the slightest doubt about what "player:set_pos{x=0, y=0}" actually does?

by Ace17 7y ago

mehrdadn 7y ago

Weird, because I agree with the general sentiment, yet with C++ I feel you have to learn most of the language if you want to be productive with it...

astrobe_ 7y ago

The problem with feature bloat is related to a very well known fact: Code is read more often than it is written. As a consequence, if you don't know the little details of a language, it might be a harder to read code written by someone else that is more knowledgeable. Consider for instance Lua, which is often read by people that have superficial knowledge of the language. Lua has a very standard syntax that anyone with basic general programming knowledge will understand: > player:set_pos({x=0, y=0}) But it also has syntactic sugar: > player:set_pos{x=0, y=0} -- note the braces instead of parens This is where you lose half of your readers because they have to look for that weird syntax in the manual. In defense of language implementers, it is sometimes difficult to "resist" feature requests. It's difficult to say "no" in general, in particular when you are not Niklaus Wirth and have half a dozen languages designs on your resumé; all you have is your gut feelings as justification.

Ace17 7y ago
I have 15 years experience as a professional C++ programmer in various teams and companies (and although I don't know 100% of C++17, I consider myself productive!). When diving into new codebases, the couple of esoteric-used-features-you-did-not-know-existed in C++ was never a big deal. Learning the required C++ features was always a matter of days (because the codebase is full of real examples). Understanding the overall structure of the code, the interactions/dependencies between the components, in what file/directory should go your first feature... this is the hard part. And it's many orders of magnitude harder than learning a couple of new language features. Don't get me wrong, I'd really like that C++ and D be smaller, and I don't like feature bloat. I once wrote a source code processor based on clang, and then you realize how big the language really is (there are many AST node types), and having all your code written in it starts to feel like technical debt. However, I pragmatically have to recognize that feature bloat isn't a real problem for professional C++ programmers (It might be, for compiler vendors - at this point, I'm not expecting any new C++ compiler to be created). PS1: C++ certainly gives you some shiny tools to make interesting messes (I've seen codebases where simply including a header would change the program behavior). This isn't related to the feature count, but rather to the semantic of the individual features themselves, like macros/templates. At least we don't have monkey patching ... PS2: About your Lua example: even without knowing the syntax, can you sincerely have the slightest doubt about what "player:set_pos{x=0, y=0}" actually does?