This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (7)
- # aws-lambda (3)
- # beginners (65)
- # boot (43)
- # cider (7)
- # cljs-dev (12)
- # cljsrn (15)
- # clojure (284)
- # clojure-austin (32)
- # clojure-brasil (4)
- # clojure-dusseldorf (4)
- # clojure-germany (1)
- # clojure-italy (40)
- # clojure-spec (21)
- # clojure-uk (69)
- # clojurescript (97)
- # core-async (11)
- # cursive (19)
- # data-science (1)
- # datascript (6)
- # datomic (30)
- # dirac (2)
- # emacs (4)
- # events (2)
- # fulcro (76)
- # graphql (38)
- # juxt (1)
- # lein-figwheel (1)
- # leiningen (6)
- # luminus (4)
- # lumo (13)
- # mount (4)
- # off-topic (24)
- # om (28)
- # onyx (32)
- # other-languages (1)
- # parinfer (40)
- # pedestal (1)
- # portkey (47)
- # re-frame (21)
- # reagent (4)
- # ring (4)
- # ring-swagger (3)
- # rum (1)
- # shadow-cljs (115)
- # spacemacs (5)
- # sql (14)
- # unrepl (1)
- # yada (3)
even when ALGOL and LISP were first created, the former was considered natural from the outset
because it followed normal conventions from mathematical notation that had been around for some ~400 years
and around the same time, lambda calculus used prefix notation for function application, but parens were often omitted by assuming left-association:
((M N) P) => M N P
I’d be willing to say that familiarity with algol syntax is not a prerequisite for disliking parentheses clutter in lisp
the feeling of “clutter” is a function of both layout and count, and saying that there are less parens in Clojure than other langs is ignoring the other half of the problem
I think it represents an interesting conflict of two cultural memes: 1) “free will”—you can and should be able to look past these parens that you will get used to, and 2) “empathetic designer”—it’s my fault as the designer that the path of least resistance led you away
It’s also untrue IIRC, for non-trivial blocks of code. e.g.
fn(1 + 2) vs
(fn (+ 1 2))
I actually saw a study somewhere which I can’t find now where they counted parens/delimiters across different codebases, lisps did end up with significantly more.
But right, just shouting down people who are suffering with it is unlikely to do any good.
I wonder if M-expr were: 1) has less perceived paren clutter 2) not adopted/built because the syntax improvement was not that significant.
I actually do think that parens are overblown, but prefix notation is still difficult for me sometimes.
(/ (+ 1 2) (* 3 6)) is just harder to scan than the infix equivalent.
Likewise comparisons, in something like
(< width 10) I always have to mentally shift the
< to ensure I’m comparing in the right direction.
Parens were only a problem briefly, and prefix isn’t terrible (and has its own advantages), but it’s still not natural to me.
Comparison operators are a struggle for me. Partially because the only thing I can remember is "the crocodile eats the bigger one", meaning I have no idea which is which.
@shaunlebron you asked me to share here once I got it out, so here it is, today I'm releasing OgE, OgE is a graph explorer for Om.next query syntax, the editor uses parinfer to help the user to write their query fast 🙂
i like how you setup the dependencies here: https://github.com/wilkerlucio/oge/blob/9c974be973cc629dfa0351187616e76497d4dff9/src/deps.cljs
and i had trouble figuring out how to setup these transitive dependencies between foreign libs
i suppose I could add a
:requires key for parinfer-codemirror to point to
cljsjs/parinfer-codemirror to have the compiler throw an error if they can’t be found
i still dislike that parinfer and codemirror have to be referenced as global vars when included as foreign-libs by the cljs compiler
@shaunlebron the deps was more a need then a feature, hehe, I needed that because OgE is supposed to be used as a library too, I didn't wanted to shared because I'm afraid of naming munging on adv compilation (also, there is currently a bug, I can't add externs there, if I do I break the compilation, antonio monteiro said there is no current way around it, so I believe him), in my case I'm calling those using
goog.obj helpers to avoid the advanced compilation issues
but would be nice if we could just import, does the cljsjs packages that you created have the externs for it?
nice, I might give it a try to the cljsjs packages, and I think you should add the :requires, since they are a real requirement there (and helps on the load ordering)
yeah, I saw cljs-oops, I just think goog.obj works well enough, trying to reduce deps