I think we're in violent agreement. Removing a feature only makes things better when it permits the addition of another feature. This is the point I trying to make about pure functional programming. Removing the ability to arbitrarily entangle state in time does not make a functional language more powerful, but adding lazy evaluation does make it more powerful.

Am I correct that we are seeing things the same way, even if my ability to explain it is poor?

Ah,

You are looking at the situation from a pure semantic point of view and from there, you are correct.

I think the parent is looking thing from the point of view of effective computing and they are correct from their point of view.

The viewpoint are perhaps incompatible.

One thing to consider is that I would say that I "can't" implement a recursive descent parser in Ruby because Ruby is too slow. Thus from the point of view of effective computing, adding features that make Ruby slow also removes some power.

I wouldn't say either position is "correct" but I think you have to take both into account.

You can argue that removing features can make a language more powerful, even if you don't add another feature.

Basically, if removing your feature, like side-effcts, allows you to give more guarantees about sub-program, you can do more with your sub-programs. Like use equational reasoning.

Not really. Take the pure functional example - you've got power because the compiler can transform certain parts of code. Now, throw in all sorts of unsafe mutable operations to the language. The language can still transform the pure parts, so you've lost no power. But you've gained the power to write other types of code as well. It's not as if you have to use every language feature all the time and suffer the downsides everywhere.

This still depends on the design of the language, though. Consider Java. There is definitely a pure functional subset of the language. However, any time you call across an object boundary the compiler has no way to know that the call can be treated as functional - because the language has late binding, and the actual implementation is swappable. In practise the JIT learns stuff like this and transforms it at runtime. That extra effort is needed because the language can't guarantee functional purity.

The point here being that some design decisions that add functionality remove the ability to rely upon design assumptions.