Keep your source code SIMPLE

I’d suggest you watch Rich’s talk “Simple made easy”. [1]

It’s one of his main points that something like a language being “hard to approach” can be overcome by spending a little effort to learn it (as opposed to sticking with something like Kotlin just because its easy to pick up because it’s familiar). The benefits of learning the unfamiliar (in his case, he’s speaking specifically about Clojure) being that it allows you to write code that is much simpler to reason about.

I have no particular beef with Kotlin (or most any languages... right tool for the job and all), but I have lately become infatuated with Clojure and many of Rich’s viewpoints.

[1] https://www.infoq.com/presentations/Simple-Made-Easy/

That is very, very far from the truth. You obviously haven't probably tried Clojure.

I think, among all the languages being actively used in the industry (in business, not academy), Clojure perhaps can be crowned as the simplest of them all. The ingenious of Rich Hickey was to design it the way that the essentials were made simple and complicated stuff either unnecessary or pushed onto the edges of the ecosystem.

Clojure can be learned à la carte - from the basics to more advanced things. Or if you want to dive straight into more difficult topics, you still can do it, and preliminaries would be minimal.

I can argue that Clojure is easier to learn than Kotlin, Python, Javascript, or Ruby. That is not a mere opinion - I know many people for whom Clojure was the very first language. And they tried to apprehend other PLs later, and it was a confusing and frustrating experience for them.

It is easy to start with Clojure. One simply needs to be less skeptical about things that people (mostly those who are unfamiliar with the language) criticize it for:

- They say, "It is hosted on JVM. JVM means Java, and I hate Java", and therefore ignore the fact that JVM is a very robust piece of tech, and you don't need to write any Java at all to use Clojure, you don't even really need to know Java.

- They say, "JVM has a slow startup time." But once you try Clojure's REPL (which is a real REPL, unlike in other, non-lispy languages), it becomes a non-issue.

- They say, "It is a Lisp, and parentheses look scary." But once you learn structural editing idioms, it becomes so frustrating to deal with all the punctuation in other languages.

- They say, "It is dynamically typed." But once you learn Clojure.Spec you may discover that you can do things with it, that most type-systems simply can't.

I encourage everyone to try to learn some Clojure, because it is fun.

I'm not a FP expert, but I do try to use FP as much as possible and yes, I agree that there is some serious dorkiness possible with certain PLs.

Anecdote, not data, but I've found that Rust, Erlang, and F# (if MS stack) tend to be in the sweet spot of expressive enough without drowning in symbols, without being as mushy as, say, Python/Ruby/pick something.

> I asked for an objective definition of what over-commenting would be.

I don't think what you're asking for is possible. It's an inherently subjective standard.

If an objective definition were possible, then it'd be possible to write a static analysis tool that reads both your code and the comments and flags "over-commenting on line 23, under-commenting on line 457". That could be done with sufficiently advanced AI, but at that point it would just be the subjective opinion of the tool's author being enforced.

over-commenting is explaining in pseudo-english what you've written in code. Prentend you are at the United Nations but you speak all the langauges, so you don't need a word-for-word translation. You don't understand to motivations of every speaker though, nor their cultural influences and a million other factors, so context is super important. In the briefings you get some of the information is not new; but if the vast majority of what you're told is obvious or discernable from what people say, you're looking at over commenting. It's not a yes-no thing but a balance of evidence, subjective opinion.

And, strangely, it's the only response to the gp's request to define of over-commenting, yet it is downvoted to below definitions of good commenting.

So. Weird. The other responses didn't properly implement the requirement specification.

I am so confused.

That's what was asked for! Why on earth is the comment that properly delivers the expectation being discussed as though it's wrong?

Yes it's an example of over commenting, which is exactly what the gp wanted.

Depends on the area of the code you look at, but they can be fairly sparse, yes:

https://github.com/python/cpython/blob/master/PC/python_uwp....

I'd say that redis is probably a better example of gold standard clean C code, though, and they follow the rule of "don't comment unless it's decidedly non-obvious" pretty assiduously:

https://github.com/antirez/redis/blob/unstable/src/ae_epoll....

I'm not sure what you mean. Comments are for explaining code that IS there.