3 ms·
"It is a logical impossibility to make a language more powerful by omitting features" - false. Different designs have different limitations. C can't have precis
by JulianMorrison 16y ago
"It is a logical impossibility to make a language more powerful by omitting features" - false. Different designs have different limitations. C can't have precise garbage collection. Shared-memory threads can't be isolated and so can't be automatically migrated. Pure functional code can be rewritten by the compiler in a way that imperative code can not. A language that omitted any global construct would be intrinsically sandboxed against use of any functionality not injected. And so forth.
- raganwald 16y agoI 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?
- joe_the_user 16y agoAh, 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.
- eru 16y agoYou 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.
- MichaelGG 16y agoNot 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.
- JulianMorrison 16y agoThis 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.