[chriswarbo]

> For the sake of eliminating an if, you are lifting everything else into what is effectively a separate language with the original code embedded in that language. Overall, that doesn't look like a win to me.

Whenever I write Java (or Java-like OO), I always have this exact "separate language within a language" feeling.

I'm supposedly working in a high-level, object-oriented, loosely-coupled, message-passing/dynamically-dispatching world of classes and instances; yet an awful lot of code is actually written in a separate language of "primitive values" with opaque control structures like if/then/else, for/while, etc.

Compare this to e.g. Smalltalk, where "ifTrue" is a method on boolean objects, "timesRepeat" is a method on integer objects, etc.

[mannykannot]

Opaque control structures like if/then/else? They seem to be pretty clear when used in human languages.

[chriswarbo]

"Opaque" as in completely uninspectable, unknown and unknowable to the language itself; as opposed to methods, which can be discovered, inspected and manipulated via reflection.

[pekk]

What real difference does it make whether repeat is a method on integer objects or whether it takes an integer argument?

[chriswarbo]

Because a method on an integer object would mean it works in the same way as all library and application code; and therefore can be used as-is, or avoided by those who don't want it, or replaced if something better comes along.

Having "for" not be a method on an object means it's something completely different: a magical keyword control structure, a gift from the irreproachable language designers to the lowly language users; since mere users cannot be trusted to make such decisions for themselves.