[kansface]

The answer to the question "where should complexity go?" is always "as low as possible". Complexity at higher levels interacts with more code and begets more complexity. The lack of generics or macros is complexity that is forced on the end user which could be handled by the compiler (language devs).

[enneff]

Implementation complexity is not the issue.

The issue is that a programmer needs to understand how the generics model works and how it interacts with every other feature of the language. That makes the language more complicated, which (as you say) leaks into the higher levels.

Generics is just one of many features that Go could have, but does not because it makes the language bigger.

[pjmlp]

Simple languages shift complexity to the programmer's shoulders.

[Svip]

Writing more code is not the same as more complexity. Irritating, perhaps, but not more complexity. A larger language overhead to keep in mind is more complexity.

[pdpi]

More code is more complexity from a maintenance point of view. You have to maintain n copies of the same code, specialised to n types. Find a bug in one, hopefully you'll remember to correct it for all n.

[MaulingMonkey]

So if I have a larger language overhead to keep in mind, that's more complexity, but if I have a larger codebase overhead to keep in mind, that's not more complexity? You're trying to have it both ways, IMO.

[Svip]

That depends on the addition of code obtained by limitation of features in a language. If the additional code base is so severe, that it increases the complexity significantly, I'd argue you have chosen the wrong language for the job.

Of course, a codebase in it and of it self can be complex, regardless of language (and even if the language is well suited for the job), but I am only talking in the context of when features (or lack thereof) in a language increases the codebase complexity.

But a few more lines in the same function to do the same thing as a single line in another language, is not more complexity, that's just more lines. It's not like the lines now are somewhere obscure or in another function.

[MaulingMonkey]

> That depends on the addition of code obtained by limitation of features in a language. If the additional code base is so severe, that it increases the complexity significantly, I'd argue you have chosen the wrong language for the job.

Agreed.

> Of course, a codebase in it and of it self can be complex, regardless of language (and even if the language is well suited for the job), but I am only talking in the context of when features (or lack thereof) in a language increases the codebase complexity.

Agreed.

> But a few more lines in the same function to do the same thing as a single line in another language, is not more complexity, that's just more lines. It's not like the lines now are somewhere obscure or in another function.

And here's where we begin to disagree.

I delete redundant comments in code, even if they're correct.

This is significantly more effort than leaving them alone: I have to recognize they're redundant, check VCS history to ensure I'm not missing something, create a changelist, request a code review for the changelist, wait for the reviewer to verify I indeed didn't missing something, submit the changelist, verify the changelist still builds (you never know when you'll hit a bizarre compiler bug, corrupted file, conflict resolution related typo), merge the changelist back to the mainline...

This is a significant amount of work! But I feel it's justified: they're increasing the complexity involved with reading the code. The more pointless redundant comments I'm reading, the less important things I can remember, and the more likely I am to skim over something important such as a bug.

This is not additional cyclomatic complexity in the codebase. Structurally, the complexity of the fundamental operations my program performs haven't changed - I haven't touched anything that should affect the final executable output in any meaningful form at all. But I'm still making it simpler* to read.

(* a synonym of simple to note: noncomplex!)

In non-comment code, the problem is much worse. More code means more opportunities for typos, more code which must be read to grok the actual execution of the code. If you thought bugs got missed when I was skimming past the comments, well let me tell you, it's way worse when I start skimming past the code! And this happens to everyone.

There are still a few people who don't mind writing all their programs in straight up assembly. Sure, it's a bit more code, but all the if and while conditionals from C aren't reducing the cyclomatic complexity of their programs either compared to structured programming with conditional jumps. They say there's more important things to worry about than pure line count - and they're entirely correct. They're writing codebases in assembly that I'd find much more readable than some of the codebases I've read in much much higher level languages.

But having addressed the more important stuff I'd still like to address the less important stuff. It eventually adds up, and I've seen it make me more productive. (This has encouraged me to try many different languages... so far not Go, I've yet to come up with a problem which makes it the right language for the job.)