Right. Look at the many wonderful and widely used applications or websites implemented in those heavy DSL systems!

Here is the full list:

Let's look at DSLs that which they were DSLs. To be kind we'll limit ourselves to javascript.

On the building side we have Grunt and the less popular but still useful Jake.

Ember's property system is a DSL.

Angular's DI syntax is a DSL and as much as I love Angular there's really nothing to like about the horrible mix of ([{ that one has to use here.

Actually Ember and Angular and just about every meaningful javascript framework defines several small DSLs.

Pencil Code is an excellent learn-to-program DSL built on Iced Coffeescript.

Coffeescript's crazy syntax makes DSLs slightly more approachable than Javascript but only for a while.

Express and most server frameworks define a DSL.

Anytime you find yourself passing a non trivial config struct you're really playing with a DSL.

This is by no means a complete list.

In addition to HN (as noted by my sibling) Facebook has extended both PHP and JavaScript with their own DSL's and syntax. I'm sure there are many more, but a lazy comment deserves a lazy answer ;)

It is different.

Using DSL to describe your domain (application) is normal. One application = one domain.

Learning in addition 15 different DSLs for libraries and tools, just because it's cute, is not the way to go. Soon you will argue about the exact definition of monad instead of shipping code.

This is a funny comment to read on Hacker News.

He did say "wonderful" ;-)

For a good example, look no further than SRFI-41[1] which defines a language for "streams", lazy lists that may have no end. SICP covers this topic as well.

Macros are used to great effect in Lisp land. They can be used to great effect in JavaScript land, too. With great power comes great responsibility.

Does anyone know Arc well enough to point out some macros used in HN's source?

[1] http://srfi.schemers.org/srfi-41/srfi-41.html

unless I can import a macro like clojure then no thanks. javascript debugging is already a major nightmare since any object can be edited anywhere, i dont need macros multiplying that disaster.

Actually you could easily use macros to reduce this nightmare. And yes, I wish for sane module system in JS too - my ideal is Racket in this regard, especially after recent addition of nested submodules.

>javascript debugging is already a major nightmare since any object can be edited anywhere

No it really cannot, except if it's exported there.