2.days().from_now()

says that we are performing the action 'days' on the object '2'. What could that possibly do? Well there're a bunch of options and none of them are obvious. It's weird and counter-intuitive. And then we go and perform the action 'from_now' on whatever the result of that was.

I don't mind 'fluent' style interfaces as long as they don't mess up the normal meanings of what objects and methods are, but sadly they usually do. Another classic sign of a bad interface is that with many of these fluent interfaces it's not obvious whether a particular thing should be a chained method call or argument, and if it's an argument, whether it should be got by calling a method, using a field or what.

Code should read like clear code. English should read like clear English. These are not the same things, and efforts to make them the same usually make a mess of both.

This stinks of principle over pragmatism.

Using the sugar offered by expressions like this requires a bit of knowledge of the development environment. I accept that it's a bit of a different syntax from some other languages, but that doesn't make it unclear at all.

Speaking to Ruby (where ActiveSupport is from), we all know that it's a language that focuses on providing flexible syntax and "multiple ways of doing things", in contrast to some other languages which restrict flexibility to provide more consistently structured code. I don't think it's a bad thing at all to have these options available, and I often find my intentions are much clearer when writing, say:

  if post.created_at < 5.minutes.ago

  if(post.created_at < (datetime.now() - timedelta(minutes=5)))

  NSDate *now = [NSDate date];
  NSDateComponents *delta = [[NSDateComponents alloc] init];
  [delta setMinute:-5];
  NSDate *fiveMinutesAgo = [[NSCalendar currentCalendar] dateByAddingComponents:delta toDate:now options:0];
  if ([[post created_at] compare: fiveMinutesAgo] == NSOrderedAscending)

TLDR: various constructs like this have their place, they're not inherently bad, but do require knowledge of the tools.

    if post.created_at < 5.minutes.ago

A more sensible syntax might be:

    if post.creation_date < now - 5*minutes

    if post.editable?

    fn editable(&self) -> bool {
        self.created_at < 5.minutes().ago()
    }

English parse tree is: ((less than (five minutes)) ago), whereas code parse tree is (less than ((five minutes) ago)).

    if post.created_at < datetime.now() - timedelta(minutes=5):

Also, one criticism of the Ruby version is the invisibility of the types involved. What type is returned by 5.minutes vs 5.minutes.ago? How do I know I can compare the second to a date attribute from ActiveRecord? The Python version is more verbose, but I think it's more clear that I'm using two datetime's and a timedelta.

  if post.create_at < 5.minutes.ago
  if post.created_at < minutes_ago(5)
  if ([post created_at] compare: [minutes_ago 5])

If you see 2.days(), you know where to look for the definition, and the type system means that you can easily learn what 2.days() returns. In this case, 2.days() returns a `TimeChange` object (https://github.com/wycats/rust-activesupport/blob/master/dsl...).

`TimeChange` implements a `from_now` method here: https://github.com/wycats/rust-activesupport/blob/master/lib... which returns a `Time`.

This is a lot easier to reason about than global modifications to Fixnum in an untyped language.

And sure, you can always look up in the type system or (in a less well typed language) the documentation to see what it does. The point of writing clear code is that doing so should be a last resort and not something you force on developers in order to understand what's going on.

Readability is what we're talking about here, and TimeChange.days(2) or new TimeChange(2, Days) are both more readable options than 2.days() because a programmer knows what is happening without querying information that isn't written in front of them.

Well, all you have to do in Rust is to look at the imports, since you have to import the trait defining the method at the call site. Because Rust modules never span multiple files, and imports must be at the top of the block that they're used in, that import will always be before the call. There are also no global imports in Rust (at least, without using a deprecated feature flag), so the trait in question is always named explicitly.

Yet this is what Ruby does, AFAIK.

Numeric#days is an ActiveSupport method, not core Ruby. But yes, it does patch the behaviour into a core class.

This is a bit of a legacy of Ruby programming, and it's definitely bad to pollute the global namespace. However, I expect we'll see eventual use of Refinements (http://www.rubyinside.com/ruby-refinements-an-overview-of-a-...) now that they are available; this will allow classes to override core methods without affecting other classes out of scope.

Anyway, I know as close as possible to nothing about Rust. It seems blindingly obvious to me that `2.days()` returns some kind of duration, and `2.days().from_now()` returns some kind of time. So I've looked at the code, and that appears to be correct - `2.days()` returns a `TimeChange`, and `2.days().from_now()` returns a Time. I can't think of any other reasonable interpretation.

     new TimeChange.fromString("2 days from now")

  use 5.016;
  use warnings;

  {
      use autobox;
      use autobox::DateTime::Duration;

      say 2->days->ago;  # 2013-12-27T14:03:47 (stringified output of DateTime object)
  }

  say 2->days->ago;      # Can't call method "days".... (runtime error)

And yes, I was talking OOP since we were talking about ruby. Functional or logic programs also have their own rules that tell you how to understand them. If you want to create good programs you shouldn't mess with those basic rules in order to make the code look more like something it actually isn't.

It does what the language definition says it does: it tells the compiler to search through traits that were explicitly imported to find a method called "days" and calls that. (Since "int" is a built-in type, it has no methods except for those provided via traits that were imported, so traits are the only potential source of these methods.) If there is more than one matching method, Rust never guesses: it instead signals an error.

> I don't mind 'fluent' style interfaces as long as they don't mess up the normal meanings of what objects and methods are, but sadly they usually do.

In this case they don't. It falls out of what traits and methods already provide in Rust.

Every time I have to write something like

Calendar cal = Calendar.getCalendar();

cal.setDate(new Date());

cal.addDate(-2, Calendar.DAYS);

Date date = cal.getDate();

I want to claw my eyes out. Is this what you consider more clear, less cutesy, somehow more productive than just 2.days.ago ?

http://www.reddit.com/r/programming/comments/21pnl/just_say_...

I still do not have good answers to the questions I asked in that first comment.

Autocompletion clearly show what you can and can't chain, but admittedly it helps a little less when the DSL asks for a parameter of some type and you don't know how to start building one. Perhaps one way to evaluate the learning curve of an API is to count how many non-standard types appear in the signatures of its methods, excluding the `this` parameter.

This is how it works in C# (and .NET in general)

DateTime.Now.AddDays(-2)

Not wanting to overload integers with calendar functionality doesn't mean you have to make it so cumbersome.

Edit: typo

  DateTime.Now - TimeSpan.FromDays(2)

    date.today() - timedelta(days=2)

  Time.now - 2.days
  Time.now.advance(days: -2)

All these questions and more are why you should question "english as a DSL" methods. Granted, there's a ton of great libraries out there which do this well. Take Unfiltered's handling of parsing out requests for pattern matching:

  case POST(Path(Seg("api" :: "calls" :: name :: Nil))) =>

  case POST(Path("/api/auth")) & Authenticate(user) =>

TL;DR How much magic do you want to deal with?

Also, this example is simply wrong ...

    case POST(Path("/api/auth")) & Authenticate(user) =>

I really do understand your hint. But the examples you're giving are bad because they rely on totally non-obvious mutable state that's passed implicitly. This is indeed "magic", however it has nothing to do with syntactic sugar.

Btw, in Scala 2.10, thanks to String interpolation, you can also construct route-matchers such as this on [1]:

    case POST(p"/api/calls/$name/") =>

    case POST(p"/api/calls/${Integer(id)}/") =>

    case POST(p"/api/calls/$id<\d+>/?") => // note the optional ending slash

Also, whenever I see "2.days" or "4.kilobytes" in Scala code, it's certainly nicer than seeing "172800 /* 2 days in secs /" or "4096 / 4 kb */". Given that these are statically type-checked extension functions that do not modify the original Int type and that do not rely on some mutable local state passed implicitly, is this magic? My IDE doesn't think so.

[1] https://github.com/alexandru/shifter/blob/master/web-api/src...

Personally I don't think it's inherently good or inherently bad, it's just one of those things that makes good code better (concise & expressive) and bad code worse (inscrutable & brittle). Glass-half-full and glass-half-empty are both valid opinions on the matter, and I strongly suspect which way you leans towards depends heavily on the quality of other people's architecture that you have to deal with on a daily basis.

Almost never.

Where it makes code clearer and more concise, or where it simplifies an often-used idiom, and where it outweighs the benefit of sticking to principles—as I believe it does here—then breaking those principles is acceptable, in languages where coding conventions support this.

> Now, I should say that I almost never use 2.days, but the point is that it’s a benchmark of expressiveness: if you can write it, you can do all sorts of other flexible things.

I tend to use MiniTest, not RSpec. But I'm very glad RSpec can be built.

The result is the ability to express

    assert { :apple == :orange }
    assert { [:apple, :banana, :pear].include? :orange }

http://oldhome.schmorp.de/marc/bournegol.html