[sooheon]

Formatting helps for presentation, just as it does for human text.

  (defn fac [x]
    (if (= x 1)
      1
      (* x (fac (dec x)))))

> (I (wanted) (to learn ((some)) Clojure in the past) but [quickly] ([(realized it was (not) for me)]))

This is missing semantics for morphology. Delimiters aren't strewn about randomly, they precisely delineate the AST.

[sooheon]

Totally not serious stab at actual semantic representation of your claim in clojure.

  (state-claim
   (but
    (past-tense
     (desire (learn me clojure)))
    (past-tense
     (realize me (not (good-fit? me clojure))))))

[benas]

Yes of course, that's incorrect and provocative in purpose. The point is not about the syntax, but about expressiveness: A programming language should make it easy for a human to express (write) his intentions in code and for other humans to interpret (read) those intensions in a natural way. In other words, the gap between the developer's natural language and his/her programming language should be minimal (and this is regardless of the developer's natural language, be it English or whatever).

[Silhouette]

In other words, the gap between the developer's natural language and his/her programming language should be minimal

I'm not sure that follows from the original claim at all.

Mathematics has plenty of problems in when it comes to obscure terminology and regrettable notations, yet still vast numbers of people prefer the conciseness and precision of mathematics to using natural language when they want to discuss concepts in science, engineering, programming, etc.

At some point, if you're going to work in a technical field, you're going to need terminology and notation to match. Newbies to the field need to learn those before they can understand what is being said "naturally". The alternative is to attempt to dumb everything down to the point where newbies can understand it straight away but, assuming it is even possible, this risks losing a lot of effectiveness in communications between everyone who does have more experience.

[benas]

Writing code is different from writing mathematical equations. Developers (humans) prefer meaningful variable names, method names, expressions, etc. Comparing this to maths where conciseness is key is not the best analogy IMO. And it is not about experience (btw, I have no problem being one of these newbies who "need to learn those before they can understand what is being said "naturally""), it is really about expressiveness to reduce the mental effort to match things (what I have in mind and what I see in code). That's why there are many attempts [1] to create programming languages that are as close as possible to people's natural languages.

[1]: https://en.wikipedia.org/wiki/Non-English-based_programming_...

[yogthos]

My team has been hiring and training coop students for years, and it takes on average a week or two for students to become productive with Clojure. Furthermore, students with less programming experience actually have an easier time picking it up. So, I completely reject the argument that Clojure syntax is somehow less natural, it's simply different from syntax people are used to. Most people who doesn't have an existing bias pick it without any problems.

[Silhouette]

Developers (humans) prefer meaningful variable names, method names, expressions, etc.

Well, isn't that part of the premise we're debating?

Mathematical papers and books tend to have the advantages of dealing with only a handful of concepts at any given time, and of presenting their mathematical content in relatively small doses, both of which allow concise notation to remain both unambiguous and accessible enough to be useful. Anything other than the smallest programs probably do not enjoy the same advantages, so it makes sense that programmers tend to use longer names for entities that are relevant over a larger area. However, this argument still allows for short names to be used in programs as long as the scope is also small, and it says nothing at all about the relevance of natural language for representing programming language constructs.

We have some experience with programming languages that do try to read very much as natural human language. COBOL is probably the most famous example, and in that language even basic mathematical concepts like comparisons can be written out in words. We don't write much COBOL today, and it's hard to believe that the verbosity isn't a contributing factor in that.

[benas]

No, you are deviating from the main point: natural expressiveness. So let me back up: If you think "if (= x 1)" is natural to humans, then try to ask someone in the street "is equals this that?" and let me know about their reaction. My point is that the natural way of asking such questions is:

  * "Is this equals to that?" and not "is equals this that?"
  * "Is this bigger than that?" and not "is bigger this that?"

And this is regardless of the language (be it English or whatever, see https://news.ycombinator.com/item?id=22811168). I'm not going to debate this to death, so feel free to disagree. Again, I have nothing against Clojure, I'm just trying to argue in a constructive way.