| > Ruby has a beautiful and consistent object / module system, I don't program much with objects, so I don't know what to expect from them, but after programming in a language that treats modules seriously (Standard ML), I can't accept anything less than the following from anything that calls itself a “module system”: (0) Implementor-side abstraction: Fine-grained control over which implementation details are exposed to different parts of a program. (1) Client-side abstraction: The ability to define a module as a function of another, yet to be supplied, module. Ruby's “module system” doesn't quite cut it. > a beautiful integration of functional and object oriented programming paradigms Functional programming in Ruby is possible, but a gigantic pain: (0) Partially applied functions are mildly inconvenient. (1) Higher-order functions that recursively pass themselves a modified version of their function argument(s) are not so mildly inconvenient. (2) Now imagine actually debugging such beasts when you make a mistake. Unit tests don't help because they overemphasize the concrete cases, when higher-order functions are all about abstracting as much as possible. At a more fundamental level, functional programming is value-oriented, and programming with compound values (not the same thing as compound objects) in Ruby isn't the path of least resistance, to put it mildly. > Yes, Ruby has warts. So do all the other languages you listed. I wasn't commenting on the languages themselves, but rather the philosophy of their designers. C++ has more than “warts” - the language as a whole is a monstrous abomination, but the philosophy of not accepting unneeded performance overheads is aesthetically pleasing IMO. |