[mholt]

I use complexity here the same way the Go community does: it is whatever its authors and users consider it to be. So chances are, if it slows down compilation, it's complexity. If it adds significantly to the grammar or syntax or keyword list, it's complexity. If it does things that can already be done, just differently, it's complexity. If it makes code less clear, it's probably complexity. (You get the idea.)

[twic]

> I use complexity here the same way the Go community does

To mean anything Go doesn't currently have?

[sanxiyn]

> I use complexity here the same way the Go community does

It is more important for the implementation to be simple than the interface.

-- http://dreamsongs.com/RiseOfWorseIsBetter.html

[wyager]

>If it does things that can already be done, just differently, it's complexity.

Doesn't that make programming languages themselves complexity? After all, you can already do anything in assembly.

That seems like a really weak argument. Sometimes having a more "complex" (in your terms) system leads to simplicity. For example, programming languages in general. Programming languages add "complexity" to computers over machine language programming, but the result is that making a program is a much simpler task.