> hardly even a language. More like a collection of macros.

You just described Forth, and a good portion of Lisp. Both of which are great, groundbreaking, and productive languages.

> an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility

Very eloquently said. However, compared to other dynamic languages like Lisp, Perl, Ruby, and Python, it doesn't strike me as particularly free or flexible. The ability to create and use DSLs directly within those languages really displays true flexibility and freedom, IMO.

Of course, you don't always want unlimited flexibility and freedom in a language; it's why a particular type-safe languages with a very restrictive borrow checker is so popular.

DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation.

Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.

We apparently have a very different definition of DSLs. Both jQuery and Lodash are, to me, libraries with lots of functions. A DSL, to me, would be a change in the underlying language being interpreted.

i.e.

    describe file("foo") do
      it { should exist }
      it { should be_owned_by "root" }
    end

vs.

    _.map(["a"], function(s) {alert(s)})

  describe("something", () => {
    it(should(exist))
    it(should(be_owned_by, "root"))
  });

Also

  _.map(["a"], s => alert(s))

Or just

  _.map(["a"], alert)

Except your rspec example isn't a change to the underlying language is it? Also, Check out mocha for the JavaScript equivalent.

Also, when you use only one function of lodash, you can't call it a language, but there are chains and flows for creating powerful pipelines for collection processing.

Operator overloading in Python made the Pandas library possible where you can treat a DataFrame syntactically like you can in R, which is really nice for data science.

"Made it possible", or "made it look like R"? add() vs. + is just a mild inconvenience IMO compared to the inconvenience of overloading abuse that I normally see ( like sqlalchemy IMO). I'd personally rather know what to expect from an operator.

Also, it adds up (no pun intended). You're right that add() vs. + for a simple case when you only do it a few times is no big deal. But it is a bigger deal when you do it a lot, and the arithmetic can be a little more complicated.

We could by analogy apply this argument to adding integers and floats together. It's more convenient to use the + operator for that, but someone could argue that an add() function is just a minor inconvenience, so why bother overloading the + operator?

That is until you have to use it hundreds of times.

It's not just arithmetic, it's also being able to use comparison operators to filter, which is really convenient. What languages like R do at the syntactic level is make the programming language closer to math, where you can do things like add vectors or multiply matrices using simple operators.