Rubyists try too hard to emulate natural language syntax, but in the process forget that natural languages are not particularly clean - in fact, more often than not they are highly dependent on contextual information, not just semantically, but even syntactically.

Ultimately, natural languages and programming languages serve very different purposes: communication in natural languages is highly dependent on context for resolving ambiguity (e.g., if we took this discussion to a non-programming forum, everybody else would be like "WTF is going on?"), while programming languages are all about making it possible to be pedantically precise without reducing convenience.

* Category functions in Objective-C

* .NET extension methods

I agree. And I think that Rust has one of the simplest semantics around in programming languages: the method resolution rules are quite simple, because there is no method overloading and all extension methods have to be explicitly imported to be used. These two restrictions are important for maintainability: the former means that the compiler "never guesses"—multiple applicable methods are a compile time error—and the latter means that you never have to guess about where a method comes from, because it was always defined either alongside the type or defined as part of a trait that was explicitly imported at the call site.

Whenever a project takes me into modifying that codebase I get that sinking feeling you get when you realize you left your wallet at a restaurant or that your car has been towed.

http://www.infoq.com/presentations/Language-Expressiveness

tl;dw: there are many types of expressiveness in programming languages, and they're all important.

Likewise syntax is important too, but often downplayed by the PLT community. Case in point: your post!

Django models are definitely more self-documenting than Rails models, which seems like a result of the Python legibility culture.

That seems like a odd restriction/asymmetry. What's the rationale?

Since safety and soundness is one of the primary goals of Rust, problems like this do crop up and are surely what I see as the hardest part of designing a usable language.

[1] http://smallcultfollowing.com/babysteps/blog/2013/10/10/fn-t...

    fn foo() {
      println("hai")
    }
    
    fn main() {
      let xs = ~[1,2,3];
      for _ in xs.iter() {
        std::task::spawn(foo)
      }
    }

    fn add1(x: &int) -> int {
        *x + 1
    }

    fn main() {
        println!("{:?}", [ 1, 2, 3, 4, 5 ].map(add1));
    }

I'd agree that unconstrained metaprogramming can make code hard to read, and Ruby especially tends to go overboard. One of the goals of Objective-Smalltalk is to create a language with cleaner extensions points, making semantically consistent extension/adaptation easier. We'll see how it works out :-)

I was thinking specifically of the expression problem:

> The Expression Problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).

http://en.wikipedia.org/wiki/Expression_problem

Now, I'm not saying Rust solves the expression problem, nor that what I'm calling "expressiveness" here maps to it, even. Just that we can easily argue over what "expressive" means.

> Libraries like RSpec might be "nice", but they are certainly not "easy-to-use", and I don't think I would call them quite "clean", if I look at their source code.

The whole point of the quote is that the source code is ugly. I think we're in violent agreement here.

Also, it's not only about ugly internals, I wrote several RSpec tests that looked like a perfectly reasonable "natural-languigish" expression of what I wanted to, but did not work at all, because of the tricky mechanics underneath happened not to support this particular combination of incantations. In the end you have to understand all the ugly internals to know which of the "nice" calls will work and which not, and I all the time see people shooting themselves in the foot because of not having this understanding, e.g. not wrapping some bit in a lambda in Ruby and having something evaluated at the wrong time etc.

It doesn't actually complicate the language to allow stuff like this: it just naturally fell out of having traits and methods, which we needed for other reasons.

You can say this about any programming language feature or concept.

However that being said 2.days.ago is not a particularly differentiating bit of magic because as has been stated elsewhere every object oriented language that allows extensions of primitive types will allow this.

The main question here though is whether 2.days.ago is a good design and does it really demonstrate expressiveness, which as has also been stated above related more to the concept of "small pieces, loosely joined"

2.days.ago breaks encapsulation and abstraction and inverts the flow of control (parameter calls function).