Clojurians Log v2

it goes beyond programming syntax though

even when ALGOL and LISP were first created, the former was considered natural from the outset

they called it and others like it “algebraic notations”

because it followed normal conventions from mathematical notation that had been around for some ~400 years

polish notation was created to remove parens around 1920.

(1+2)*3 => * + 1 2 3

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.

Hahaha

So true

@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 🙂

OgE can be found at: https://github.com/wilkerlucio/oge

@wilkerlucio cool, looks nice, thanks for sharing

i like how you setup the dependencies here: https://github.com/wilkerlucio/oge/blob/9c974be973cc629dfa0351187616e76497d4dff9/src/deps.cljs

I was helping timothy pratley setup parinfer on a cljs project yesterday

and i had trouble figuring out how to setup these transitive dependencies between foreign libs

it’s all very weird

https://github.com/shaunlebron/parinfer-codemirror-cljs-example

i ended up just creating cljsjs packages

i suppose I could add a :requires key for parinfer-codemirror to point to cljsjs/parinfer and 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?

externs are there yeah

but really, i use cljs-oops to avoid externs now

essentially a simpler way to do what you’re already doing with goog.obj

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

ah, i missed that it helps with load ordering, makes sense

that’s the only downside—that it’s not a part of core, but it never will be

true