8

Argument which is always made in favour of Clojure is that.

The syntax is simpler and there is only one way of expressing code with no complicated rules.

However Scala has loads of different types of syntax and constructs as compared to Clojure.

But from last one week while trying to learn Clojure, I have noticed that the list of inbuilt macros are endless, Even though we write them with the same parenthesis syntax we need to learn how each works.

So in what sense is Clojure's syntax simpler ? For LISPers it might be but for people from a different background learning different constructs in Scala seems simpler.

So from a neutral point of view, which syntax is simpler and readable?

1
  • 6
    If you look in the Scala standard, its grammar is 7 pages long. as much as I like Scala, it does not have simpler syntax than lisp. Commented Apr 22, 2013 at 10:35

5 Answers 5

18

So from a neutral point of view, which syntax is simpler and readable?

Those are two very different questions.

Simpler means "composed of fewer parts". Clojure's syntax has fewer rules, ergo it is objectively simpler than Scala's.

Readability, however, is subjective. It mainly comes down to familiarity. For example, I find ECMAScript, C#, Java, D, Go, C++ and C to be nearly incomprehensible, but for someone who is used to reading that kind of syntax, they are fairly readable. This part of the question cannot be answered objectively or "from a neutral point of view".

6
  • 5
    +1: "Readability, however, is subjective. It mainly comes down to familiarity.": True. I have been playing with Scheme and Common Lisp lately (I am no expert in either of them), and I do not see why their syntax is considered difficult to read: it is very easy to get used to it.
    – Giorgio
    Commented Apr 22, 2013 at 11:30
  • syntax has fewer rules, but then again learning curve remains the same you have to still learn different macros, te way you have to learn different constructs. Even if they are written in with sam eset of symbols. Commented Apr 22, 2013 at 12:00
  • Yes, but the question was about syntax, not semantics. If that is what you want to know, you should clarify your question. Commented Apr 22, 2013 at 12:34
  • 1
    +1: This is a good answer to the OP's question. Interestingly, however, the idea that readability is entirely subjective is a common myth. It is logical to suggest that, given similar experience of two different languages, one language might be measurably more readable than the other, at least statistically. (Consider, for example, those esoteric languages that are highly unreadable even if you know them quite well.) Unfortunately, I'm not aware of any studies on this matter.
    – Kramii
    Commented Apr 22, 2013 at 12:45
  • 1
    @Kramii: I have many years experience with C++ and a few months experience with Common Lisp, and I find CL much more readable than C++. This either shows that Common Lisp is objectively much more readable than C++, or that my way of reasoning is closer to how CL works. Or maybe it just proves nothing at all.
    – Giorgio
    Commented May 17, 2013 at 12:22
4

When I work in Scala, there is often a phase of my development (especially with for comprehensions) where I have to make all the types work out correctly which is a big plus for big projects, but a definite negative for small ones. I expected that I could just forget types and focus on "getting the job done" in Clojure the way I vaguely remember doing in Perl or Awk, but so far it hasn't worked out that way for me. My experience is that instead of "making the types work out" in the code/compile phase, I am getting exceptions when I try to run my code. This is not a simplification; the problem hasn't gone away, it's just moved to a more dangerous/expensive part of the development cycle.

There is a delightful simplicity to Lisp-ish syntax. One of the big strengths of Emacs is being able to execute arbitrary lisp code by hitting a special key sequence at the closing paren of a block of code at any time in any buffer. The simple parenthesis-delimited nature of lisp syntax makes this elegant in a way that would be awkward (having to introduce curly braces?) in most other languages. Also, the regularity of (function arg, arg...) and (operator arg, arg...) makes thinking about functions and operators as first-class citizens and thinking about anonymous functions very natural, in a way that the infix operators of other languages like Scala do not.

My limited experience with Scala prevents me from saying that the syntax is simpler or more readable. Sure, there is some non-lispish syntax in Clojure using macros, but my perception is that these macros only open a little window into imperative thinking in a syntax that is otherwise very functional. Imposing a preference for functional or imperative syntax in the language can simplify things. I would have to give a point to Clojure, Java, and Haskell for this.

My concern with Scala is the same concern I had with C++ or Perl (though to a lesser degree); the syntax of the language accommodates several different thinking styles (Haskell and Java). This makes it fun to write, but could be problematic for readability. Even as I write that, I remember that Clojure supports Domain Specific Languages and wonder to what extent that undermines my point.

Your question is a very interesting one. Ultimately, the comparison is a complex one. But based on my current knowledge I would have to agree that the syntax of Clojure is simpler than Scala, but maybe not a whole order of magnitude simpler.

3

Even though we write them with the same parenthesis syntax

And that's basically the answer to your question.

we need to learn how each works.

While it is possible to introduce DSLs with a not so lispy syntax like Common Lisps loop using regular macros (I'll leave reader macros out of this), they are mostly used to control evaluation, and will still use regular s-expression syntax. One important feature is that even the more complex loop-like macros can be read using the same old sexpr reader.

While it's true that you'll have to learn about the different macros and the form of input they take, say Common Lisp's cond with its more nested vs. Clojure's cond reducing one layer of nesting, that doesn't only hold for macros, but also for regular functions. Imagine a usual function taking a quoted list of a particular structure as an argument – you'll still have to conform to the expected input structure, whether the function transforms code, expects some kind of alist, plist, a tree or something entirely different.

Whenever you encounter new functionality, there will be some API you'll have to learn. That would also hold for a language that only allowed strictly function(arg1, arg2, …, argN) syntax – you'd still have to learn what the expected arguments are, what side effects occur, and what the output of any given function is.

What's easier about Lisp syntax compared to a language like Scale, is that everything is represented more or less the same, and also that the code itself used these representations and data structures (that would be the homoiconicity everyone is talking about). This difference in syntactic complexity would become pretty clear if you tried to write a Lisp or Clojure parser and then a Scala parser. You'll have to cope with a much more complicated grammar – more complex rules concerning precedence, whitespace, ambiguities, more exceptions, and so on.

3

From the wikipedia definition:

In computer science, the syntax of a programming language is the set of rules that defines the combinations of symbols that are considered to be correctly structured programs in that language

Since clojure is a lisp, you have s-expressions + the list of reader macros and that's all.

In scala, you have classes, case classes, implicit lambda with _, implicit keyword, traits, generic annotations, variance annotations, etc

Clojure has a simpler syntax because features can be implement as macros or special forms. This is impossible with scala, in his you have to add syntax in order to support some features.

-1

Macros aren't syntax.

Arguing ecosystem or basic library complexity is a completely different discussion.

Not the answer you're looking for? Browse other questions tagged or ask your own question.