Fork me on GitHub
#parinfer
<
2017-10-24
>
shaunlebron00:10:01

it goes beyond programming syntax though

shaunlebron00:10:26

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

shaunlebron00:10:50

they called it and others like it “algebraic notations”

shaunlebron00:10:28

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

shaunlebron00:10:24

polish notation was created to remove parens around 1920.

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

shaunlebron00:10:46

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

shaunlebron01:10:42

I’d be willing to say that familiarity with algol syntax is not a prerequisite for disliking parentheses clutter in lisp

shaunlebron01:10:05

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

shaunlebron01:10:41

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

cfleming01:10:37

It’s also untrue IIRC, for non-trivial blocks of code. e.g. fn(1 + 2) vs (fn (+ 1 2))

cfleming01:10:14

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.

cfleming01:10:12

But right, just shouting down people who are suffering with it is unlikely to do any good.

dominicm08:10:12

I wonder if M-expr were: 1) has less perceived paren clutter 2) not adopted/built because the syntax improvement was not that significant.

cfleming08:10:21

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.

cfleming08:10:58

Likewise comparisons, in something like (< width 10) I always have to mentally shift the < to ensure I’m comparing in the right direction.

cfleming08:10:39

Parens were only a problem briefly, and prefix isn’t terrible (and has its own advantages), but it’s still not natural to me.

dominicm08:10:06

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.

wilkerlucio11:10:21

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

shaunlebron16:10:12

@wilkerlucio cool, looks nice, thanks for sharing

shaunlebron16:10:52

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

shaunlebron16:10:14

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

shaunlebron16:10:41

it’s all very weird

shaunlebron16:10:31

i ended up just creating cljsjs packages

shaunlebron16:10:04

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

shaunlebron16:10:09

i still dislike that parinfer and codemirror have to be referenced as global vars when included as foreign-libs by the cljs compiler

wilkerlucio17:10:02

@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

wilkerlucio17:10:26

but would be nice if we could just import, does the cljsjs packages that you created have the externs for it?

shaunlebron17:10:44

externs are there yeah

shaunlebron17:10:05

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

shaunlebron17:10:26

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

wilkerlucio17:10:30

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)

wilkerlucio17:10:01

yeah, I saw cljs-oops, I just think goog.obj works well enough, trying to reduce deps

shaunlebron17:10:02

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

shaunlebron17:10:28

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