Languages are driven by the platform. There is no Clojure platform that people want to use, so no one uses Clojure.
If a language isn't bound to it's own platform, it can share a platform and displace other tools like python, go, and rust do with C and C++ (docker is go; docker-compose, dnf is python; etc).
Scala has carved out pat of the jvm platform (spark, kafka). Clojure has not.
A common onramp is command line tools, but Hello world in Clojure takes 670ms to run. This is a total non-starter.
time clj -M hello.clj
Hello world
clj -M hello.clj 1.05s user 0.12s system 175% cpu 0.672 total
If Clojure is so great, where are these cathedrals that people have made that should make it a no brainer to pick up Clojure? Around what are we circling the wagons?
Scala world is not that functional if you measure it by real-life usage at least. Most of Scala code I've seen was mostly OOP sprinkled with functional tricks.
If you don't want to have to manually compile your app then you can use https://babashka.org/
How many platforms do you think Clojure has?
Could you show me how?
I've had so many programmers look at code I write and proclaim: "wow that looks impossible because of the parenthesis" and that would never touch anything like it because it seems so different.
Some people do take the time to learn how it works, but many just have a knee-jerk reaction to it and then forget about the language itself.
What makes it different is that syntactic constructs are also expressed with the same syntax and there is no special syntax, so control flow constructs use a syntax similar to function calls.
This is particularly exuberant in Arc where what in many languages would be:
if (<cond1>) {
<then expr1>
} else if (<cond2>) {
<then expr2>
} else if (<cond3>) {
<then expr3>
} else {
<else expr>
}
(if
<cond1> <then expr1>
<cond2> <then expr2>
<cond3> <then expr3>
<else expr>)
It is thus that most Lisps have somewhat more redundant syntax:
(cond
[<cond1> <then expr1>]
[<cond2> <then expr2>]
[<cond3> <then expr3>]
(else <else expr>))
match x {
<cond1> => <expr1>,
<cond2> => <expr2>,
<cond3> => <expr3>,
_ => <expr>,
}
let message = match maybe_digit {
Some(x) if x < 10 => process_digit(x),
Some(x) => process_other(x),
None => panic!(),
};
https://doc.rust-lang.org/reference/expressions/match-expr.h...
(-> something (manipulation-of-something) (nextmanipulation) (anothermanipulation))
instead of:
(anothermanipulation (nextmanipulation (manipulation-of-something something)))
Often, you can remove some parenthesis in the first case as well.
I really love this. It is also very easy to just wrap it in a let or a function. This alone should open the eyes of anybody, who has written at least some Shell script somewhere or does some data analysis. If it doesn't, maybe the person isn't actually that great of a thinker or a practitioner and you would be better off around other people professionally. Frankly, who are the people, who cannot grok moving the opening parenthesis before the method/ function? I don't think I have ever met anybody like that - I only read/ hear about such people in comments or at conferences and I haven't heard a name yet.
LISPs forces you to maintain the stack for the parse tree in your head, something humans aren’t that great at — s-expressions are the programming language equivalent of center embedding, which is quite alien for human languages (the depth is three at most: compare that to your favorite lisp program)
A deeply nested syntax is beneficial for UI work because you can correlate the structure of the code with the interface/document being rendered. S-expressions for HTML/UI in the form of Hiccup-style templates are equally good (if not better) for the same reason.
In JSX however, there is a clear syntactic distinction between behaviour (C-like JavaScript syntax) and interface descriptions (HTML-like element constructors). In Lisps, the uniformity makes it harder to quickly distinguish "behaviour" from "data", which is kind of the point, but comes with a trade-off in readability.
Maybe in theory, but in practice it's easy to tell because in the case of hiccup, the data is data (as vectors) and behavior is behavior (as function calls), those have different syntax in Clojure.
Lisps are excellent at manipulating trees, which is exactly what HTML and the DOM is.
Note that you're taking for granted that the document must necessarily be a nested tree structure, which then behooves us to follow in the code.
Which may be right and good (and in any case is foisted on us); but the assumption bears spelling out.
But on the second part I think that's the same as for most languages. You end up with nested scopes at the same degree as any c-like language really. But most lisp programmers tend to break out into new functions a bit earlier than let's say JS programmers. I'd argue that normally you'd have to keep track of less depth in a normal Clojure program than you would in a JS program, simply because of how a programmer usually works in those languages.
Compare:
something.first().second().third()
(third
(second
(first
(something))))
(-> something first second third)
That's not the complete picture.
The early Lisp manual had a definition for Lisp syntax. The Lisp syntax was based on M-expressions for code and S-expressions for data.
Basically what now is
(append (quote (1 2 3))
(quote (a b c)))
append[(1,2,3);(A,B,C)]
Then we have so-called S-Functions, which work with S-expressions. append is such an s-function.
McCarthy then defined a mapping from M-Expressions to S-Expressions, thus that M-Expressions could be represented (not just written, but also in memory) as S-expressions.
In the next step he defined new S-functions called apply and eval, which took M-Expressions as S-Expression data and computed the results of apply or eval operations.
Example use of apply:
apply[(LAMBDA,(X,Y),(CONS,X,Y));((A,B),(B,C))]
Thus such a program would use both code in M-Expression format and compute with code in S-Expression format.
Since these S-functions apply and eval could be themselves translated to s-expressions and get executed, the specific S-functions apply and eval could get executed by a s-expression evaluator.
The code above would then be written:
(APPLY,(LAMBDA,(X,Y),(CONS,X,Y)),(QUOTE,((A,B),(B,C))))
(apply (lambda (x y)
(cons x y))
(quote ((a b) (b c))))
Thus the idea of a simple s-expression meta-programming system made the idea of an additional step of m-expression syntax reading/printing less attractive.
something.first(other.foo(bar.f(x, y)).memb, z).second(x.y()).third(a, b, c)
(third
(second
(first
(something))))
With the above indentation, it's very readable to me; it's very clear that calculation starts with (something) and moves in an outward direction.
(-> something first second third)
(defun app ()
(init)
(event-loop)
(cleanup)
(exit 0))
(let* ((a (first (something)))
(b (second fi))
(c (third se))
...)Most aren't fond of Lisp syntax, regardless of how you dress it up, and thus writing in Lisps doom you to have fewer people to hand over your code to, and I don't think that scarcity is useful. I suspect the reason most don't like s-expression is that it forces the human reader to maintain a "mental stack", an exercise humans are not too good at, as demonstrated by human languages aversion of center embeddings.
But most mainstream languages have chained function call notation as a feature.
Furthermore, foo.bar().baz()... chaining is a fairly recently emerging idiom. It has been possible in a number of languages for decades already, but somehow didn't take off. You would hardly see chains of foo.bar().baz().xyzzy() in 1990 vintage C++ code bases, even though 1985 vintage C++ would easily support it.
Anyway, there is a dialect of Lisp which has integrated the dot syntactic sugar into S-expressions, according to this basic idea:
This is the TXR Lisp interactive listener of TXR 257.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
Poke a few holes in TXR with a fork before heating in the microwave.
1> '(quote x) ;; i.e. just like we have a 'x -> (quote x) sugar ...
'x
2> '(qref x)
(qref x)
3> '(qref x y) ;; we can have a x.y -> (qref x y) sugar
x.y
4> '(qref x y z)
x.y.z
5> '(qref x y z w)
x.y.z.w
6> '(qref x y 3 w) ;; (let's not when it's ambiguous with floating-point)
(qref x y 3 w)
7> '(uref x) ;; ... and a .x.y (uref x y) sugar
.x
8> '(uref x y)
.x.y
9> '(uref x y z)
.x.y.z
10> '(uref x y 3 w)
(uref x y 3 w)
11> '(qref (a) (b) c (d) e f (g))
(a).(b).c.(d).e.f.(g)
12> (new list-builder).(add 3).(add 4).(pend '(5 6 7)).(pend 8).(get)
(3 4 5 6 7 . 8)
In the first place, list-builder is an implementation mechanism under the build macro, which expresses it like this:
13> (build (add 3) (add 4) (pend '(4 5 7)) (pend 8))
(3 4 5 6 7 . 8)
This chaining business is a minor benefit (if at all) of the dot notation. The main motivation is to make programming with structures and OOP more ergonomic. It has a big impact for programs that use data structures, because the use of data structures and OOP can pervade the entire program, and is a driver behinds its structure.
Anyway, anyone discussing S-expressions under the assumption that they do not have a dot notation that can be used for function chaining is simply unaware of the research having been done in this area in the TXR Lisp project.
This knee-jerk reaction you're having is exactly the ones I'm talking about :)
I think a lot of the readability issues come from lisp syntax being unfamiliar, not from some intrinsic impenetrability.
And then even more from being associated with functional programming, also unfamiliar to a lot of people.
Look at common lisp nested for loop[0]. Are they really that hard to read?
And then there's the minimalism of lisp syntax. Once you know how to call a function and the few data literals (list, vectors, set, ...), you know 90+% of the syntax.
Compare with python, where you also need to learn class syntax, annotation syntax, for loops, if, while, comprehensions, etc.
And the list keeps growing, there's new features being added continuously. In lisp, if the language introduces a new construct, it's still going to be just symbols in between two parenthesis.
[0] https://lispcookbook.github.io/cl-cookbook/iteration.html#lo...
But then Python is probably the worst example to compare Lisps to, as Python sees whitespace as a significant character that can affect if the program can run or not.
Dynamic typing is why I eventually switched. Haskell scratches the same itches that Clojure did, but the compiler and type system are immensely helpful, and keep saving me from tripping over my own feet.
I am very much waiting for some "extremely" constraint subset/flavour of Haskell that gets some adoption(I do not think I am alone in this lobby). No crazy stuff, no "just read the types", no "its just a small extension". But I also know that it is not really feasible without breaking the IO enforcements.