Programming languages come in many shapes and sizes. While it is difficult to definitely claim one language is better than another, you can certainly point to flaws. One tough balance a language has to strike is between simplicity and complexity. In the context of this post: features.

Less is More

For every new feature added, it comes with a set of burdens and opinions. There will always be a level of trade off. And frequently, the trade offs are well worth it. Modern languages come with modern niceties that are hard to live without. But not all proposed features are worth implementing. Even when a problem is easier to solve with a given feature; that very feature puts you into unique holes. The worst part is that sometimes, the hole is very shiny looking. But don’t be fooled, this is all to lull you into a sense of security!

The Perfect Example

C vs. C++

C++ is a language with far too many features. The worst part is that the compiler doesn’t even implement them all. C is better than C++ even though to most, C++ is just C with extra features (it is not.) Naturally, this introduces a lot of questions.

This is not a post on why C is better. But perhaps by talking about the following mindsets, you will understand what I am getting at.

Just don’t use the features you don’t like

This argument is flawed from the start. If a feature can be used, it will be used. But none of the nuance with the problem it was trying to solve will be explored when blindly using it. Conversely, when a programmer has to explicitly create a feature to solve their own problems, they inherently know the limitations of said feature. Very few programmers consider the original intent and just make the language bend to their will (even if their will is wrong.) A classic case of the circle in the square hole.

A language that allows users to make dumb mistakes will have users that make dumb mistakes.

More features just means more options

Mount Everest, essentially a small bump on the Earth’s surface, is ideal for a light stroll, much like how navigating a language with endless features is a breeze for newcomers.
The bigger the mountain, the more intimidating it is. Even if you ignore that; the learning curve of unlimited features comes at a massive cost. New users will have to take shortcuts and make avoidable mistakes. They will not read the docs explaining every feature. The only people who are able to traverse the vast language, and fully / correctly utilize the available features, are those who have been around since the beginning. They had the time to get accustomed to the breadth of the language.

A language that requires a dissertation just to use will be misused.

The language maintainers added this feature for a good reason

Maybe. Or maybe not. Maintainers might be smart but they are still human. Additionally, an apparent good decision might be massively flawed. But only in retrospect do we know that. And removing the feature introduces more issues than it solves.

A Goliath can be taken down when led by incompetent leadership.

A Lesson from Game Dev

Even if we avoid all pitfalls that a presented feature gives us (unlikely,) we are still likely to introduce unrealistic expectations. Your code is only as good as its weakest link. Irresponsibly using a feature might inaccurately represent your code base, creating impossible expectations for either the end users or the maintainers (or worst yet - both.)

Consistency is the most important component. When making a game, many people get bogged down by components that they are not good at. These devs will quickly reach for a shortcut feature that tries to fill in for their flaws. Be it using asset packs or game engine features. However, what happens when they need to expand those assets? Their flawed attempt will drag the whole thing down. Instead, they should focus on making everything consistent and not get stuck on trying to make their game exactly like their favorite game.

A game with perfect graphics but horrible controls and game play, is a bad game. This is my major gripe with using Unreal Engine for new developers. They are so quick to use the shiniest features. But without appropriately incorporating it into their game, the fancy feature only serves to detract from the experience. Pirate Software has a wonderful resource site to help people get into making games. One section is on What skills do I need? The whole section essentially shows examples of why you don’t need to be the best at every aspect of game dev, to make a wildly successful game.

Conclusion

Do not just assume that powerful features serve as good substitutes for inexperience and lack of skill. A language that forces you to properly learn a topic will nurture better developers, and in turn, better software. Good features truly can elevate a program and a programmer, but that doesn’t mean that introducing new features for every problem is a good solution.
Not all developers can fully leverage a given feature. Knowing what side you fall on, is almost impossible. Instead, it is easier to take an approach where when you begin to heavily rely on a given feature, dig into that feature and try to understand it inside and out.

Supplement

Python has the best discourse around new features. If you are interested in rejected features (PEPs,) I suggest reading The best of rejected PEPs by trag1c. And taking it a step further, look into the reasons for the rejections.