[falcolas]

The tradeoff for anything "simple" is that you are then left to pick up the pieces (with libraries or your own code) if you want to do anything "complex".

As an example: C doesn't have the complication to the language of having "built in" types for hashes or lists. This makes the language easier, since you don't have to learn the extra syntax and grow the mental model of how they were implemented. On the other hand, if you need a hash or list - you need to create your own (or adopt someone else's implementation via a library).

C is a simple and powerful language, but there's so much you have to do yourself, that it's easy to get something wrong.

Clojure (and lisps in general) hide their complexity in macros. This level of abstraction can be great, until you have to dive into the macro and see exactly how it's manipulating your code. Or write your own and troubleshoot the resulting dynamic code.

[nickbauman]

The tradeoff you're referring to is summarized "Powerful but doesn't provide much." JavaScript comes to mind. This is not the case with Clojure. Most macros are basic and straightforward. Their power is, of course, unparalleled in other languages feature sets. With great power comes great responsibility, eh? And you don't have to use macros. Not that much is implemented in macros. I think you have some valid insights but you may be overstating your case.

[falcolas]

> This is not the case with Clojure.

Well, it actually is the case, it's just that they've built out the core library with a ton of functionality; intermingling the actual Clojure keywords (there's only ~17 of them) with the convenience macros and functions built up from those two primitives. Someone wrote all of those functions and macros. Hundreds of functions and macros were built by the language creators to give the functionality of a complex language.

> Not that much is implemented in macros.

74 of the functions exposed in the core api alone are macros. Perhaps the most often used one is "defn" (and somewhat ironically "defmacro").

[astine]

    intermingling the actual Clojure keywords (there's only ~17 of them) with the convenience macros and functions built up from those two primitives.

It sounds like you are drawing a distinction between the core Clojure language and the macros and functions in the core Clojure namespace. This is not really a valid distinction. That's the thing about Lisps, that much of the language is implemented in the language itself. Macros make the language easier to extend by both the language designer and random developers and users in appropriate cases. You can keep special forms to a minimum. Those those functions and macros are considered part of the core language even if they aren't special forms.

[juliangamble]

In case you're interested, Lisp can be implemented with 7 primitives (some say 5). So in a sense Clojure went overboard to increase the verbosity of Lisp to make it easier for newcomers: http://stackoverflow.com/questions/3482389/how-many-primitiv...

[nickbauman]

... so it sounds like we're in violent agreement.

[sklogic]

> Not that much is implemented in macros.

And this is exactly what is wrong with Clojure and its community. An unexplainable lack of ability to embrace macros and all the power they can bring.

I could never understand a single anti-macro argument, they are all too detached from the reality.

[goldfeld]

Is it really lack of ability to embrace, or a desire for simplicity of understanding? (which is also reflected in working with plain data structures in all kinds of libs). I think core.async is a great use of macros and suggests the Clojure community has ability to use it where it makes sense.

[sklogic]

Nothing can improve simplicity and readability more than macros. They make sense most of the time, almost always, not just in some edge cases.