In quest for more power, C# has recently been grown with new features and Java might follow soon the same path. While extending the choice of features provides programmer with more freedom, does this necessarily provide more power? And does a language need to offer a lot of freedom and flexibility to be genuinely powerful?
Reg Braithwaite believes that this is not necessarily true. In response to Azubuko Obele’s statement that “people who argue for languages with more power are actually arguing for less rules”, Braithwaite asserts that there is no causal relationship between power and freedom even though the two are correlated in many languages, e.g. Ruby. According to Reg, Python is “a considerably more powerful language than Java” even though both are “built with the philosophy that removing certain programmer freedoms would produce better programs”. In Python, features were not rejected simply because they could be potentially misused but rather when they were judged unnecessary, either because there were already “a perfectly serviceable way” to achieve the desired outcome or because they concerned things “that don’t matter, like indentation”. And this approach did not prevent from adding new features to the languages if those could “fit within Python’s style and design æsthetic”.
Some functional languages also impose strict rules, which does not mean they offer less power:
Haskell is quite possibly the most extremely limiting language in common use: there is one way to do everything, mathematically pure functional programming. You have strong, expressive static typing
[…]
Likewise, the Factor programming language imposes a single, constraining set of rules on the programmer: programmers switching to Factor must relinquish their local variables to gain Factor’s higher-order programming power.
Hence, Reg argues that “languages can provide more power while also providing more rules and, paradoxically, less freedom.” What really matters, according to him, is careful design that follows a guiding philosophy and brings coherence into the language. The languages can then provide more power by letting programmer achieve more with less and it can be grown without “throwing more [often unrelated] features on top of the pile”:
Good design in every field accomplishes the “antigravity” trick of accomplishing more with less. With poor design, adding new power requires adding more check boxes, more features, more ways to do things that interact with each other unexpectedly.
While sharing Braithwaite’s opinion that power and freedom are not necessarily correlated, one of commentators, Daniel, argues that power of a language does not depend on rules it imposes on programmers but on “computer language "theorems" it provides:
A computer language is not akin to rules, but akin to mathematics. […] So, compare it to algebra. The more theorems you have, the more powerful you are. Are theorems freedom? Not, of course not. Theorems are fundamental truths that can be combined to more easily achieve further results.
According to Daniel, what makes the difference between languages is to which extent theorems they provide are constructs that are easy for human minds to deal with:
For instance, in machine code there is no "for" loop as most of us would understand them. What you have are conditional jumps based on CPU flags.
But from that we developed a very useful construct, which is the "for" loop.
Now, even though the "for" loop is a very powerful construct, it is often prone to misuse. Few people can really truly simulate in their minds a "for" loop, so errors in that construct are not uncommon.Now, a "foreach" (list iterator or mapper) construct might not be as flexible as a "for" construct, but it is easier for us to understand.
Daniel advocates for using such easy to understand constructs because this limits the risk of misusing them and makes a language more “prone to correct programs”. Even though these constructs can be “powerful and easy to use at the same time”, this is not always the case and some “theorems” prone to be misused are actually more powerful. Hence, not only is there no direct correlation between freedom and power, but one may need to renounce to some power in the name of code quality.
In spite of underlying conceptual difference, these two approaches don’t oppose each other. Based on arguments of both Reg and Daniel, one could argue that to be genuinely powerful, a language needs to have a carefully conceived design that guarantees the coherence of different features and to offer constructs that make sense for humans in order to limit the risk of misuse and to rise the quality of code.
