[benas]

I have nothing against Clojure, but I agree with Donald Knuth who said: "Programs are meant to be read by humans and only incidentally for computers to execute." [1].

I could be wrong, but I don't find Clojure to be "simple" for humans to read (or write). Here is an example from the blog post:

  So let’s write a simple one. Let’s write the factorial function.
  (defn fac [x] (if (= x 1) 1 (* x (fac (dec x)))))

Note the "simple one" here. I don't know for others, but this is not simple for me as a human to read, understand and reason about. For instance:

  if (= x 1)

As a human, I read this like "if equals x one", which does not translate to my natural language where I would say "if x equals one". So I need an additional mental effort to do the translation. This is not the case in other languages where "if x equals one" would be written like "if x = 1" or "if (x == 1)". If the gap between the natural language and programming language is big, it is difficult for a human to use that programming language. And for Clojure, this gap is big IMO.

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

[1]: https://news.ycombinator.com/item?id=16430751

[2]: https://twitter.com/b_e_n_a_s/status/1244417191556063234?s=2...

[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.

[filoeleven]

Here’s a trivial extension to one of your examples:

  (if (= a b c) true)

In JS it looks like this:

  if (a == b && b == c) return true;

Let’s build an even bigger one! Clojure:

  (if (or (= a b c)
          (not= d e))
      true)

And in JS:

  if ((a == b && b == c) 
      || d != e) 
    return true;

More verbose, contains some weird symbols, and I’m not sure that my line breaks are helping anybody.

Wanna see if an “array” is full of the same value?

  (apply = [2 2 2])

In JS:

  [2, 2, 2].every( (val, i, arr) => val === arr[0] )

These are not pathological cases.

[sooheon]

> If the gap between the natural language and programming language is big, it is difficult for a human to use that programming language. And for Clojure, this gap is big IMO.

English is not all natural languages. Verb-subject-object is the 3rd most common ordering in human languages[1]. Infix is not the only mathematical notation either[2]. I think we all benefit from mind-expansion from learning new languages.

[1] https://en.wikipedia.org/wiki/Verb–subject–object [2] https://en.wikipedia.org/wiki/Polish_notation

[benas]

Did I mention English? That still applies to any language. If the developer's natural language is Russian, the mental effort to translate what the developer wants to express in Russian in his programming language should be minimal.

[sooheon]

> my natural language where I would say "if x equals one".

You gave an english quotation as an example of your natural language.

My only point is that there is no objective "natural" ordering, what is natural to each person depends on their starting point. Because this is somewhat arbitrary and provincial, it is good to be exposed to alternatives.

[SaxonRobber]

Don’t try to reason with clojure zealots, they are just as bad as rust zealots and also less relevant.

[benas]

Thank you. This is really the impression I have right now after reading all these replies (and those on twitter as well).. Even though I'm trying to argue in a constructive way from the beginning.