7 ms·
What aspect do you dearly miss? (Honest question, I've never understood the S-expr trade-off, especially if macros are off the table).
by nilliams 10y ago
What aspect do you dearly miss? (Honest question, I've never understood the S-expr trade-off, especially if macros are off the table).
- pka 10y agoProbably paredit. It's really so much better than non-structured editing. That said, there are structured editing plugins/modes/editors for other languages too. However, looking back at Lisp/Clojure now I really don't like the syntax anymore. I don't care about the brackets, it's absolutely true that you learn to look past them in a matter of days, but the homogeneity and the "denselesness" really impact my ability to quickly parse an expression. Infix syntaxes make reading code much easier, imo.
- roboguy12 10y agoI thought that at first too about infixes being better (I've only been using Clojure for a few months), but I'm beginning to find the opposite. The only times when I miss an infix syntax is when doing math 1 + (2 * 10) - (12 / 3) is so much easier for me to read to read than (- (+ 1 (* 2 10) (/ 12 3))) But when working with functions, I much prefer the standard Clojure syntax.
- malloryerik 10y agoI believe the parens are off by one in the Clojure example and that it should be: (- (+ 1 (* 2 10)) (/ 12 3)) ;=> 17 I've found the threading operator can help in these cases. (-> (+ 1) (+ (* 2 10) (- (/ 12 3)))) Or, line breaks can clarify: (- (+ 1 (* 2 10)) (/ 12 3)) or at the risk of overdoing it: (- (+ 1 (* 2 10)) (/ 12 3)) Now I know at first glance that I'm subtracting the results of those two lines from each other. Indeed the last two might be almost as clear as the infix, and are without any order of operations rules. Also some don't like colored parens but I find them very clarifying.
- pka 10y agoI have to disagree. f x . g reads just so much easier than (comp (partial f x) g)
- d_t_w 10y agoStructural editing, paredit, 100%. I say that not being particularly accomplished with it. 15 years of programming Java, now 3 in Clojure, would dearly miss slurp and barf, the lesser appreciated virtues of homoiconicity.
- aaron-santos 10y agoI took some time to think about this because it started off as a feeling and not a list of reasons. For me it's mostly centered around control structures - if, for, switch, case (scala's pattern matching). Clojure's control structures are syntactically composed of ()'s and []'s. Scala's aren't. They are a coded into the language's grammar[1][2]. Clojure's ns forms parallel Scala's package and import statements, but are again Clojure's are syntactically composed of ()'s and []'s. I know it's a relatively small point, but control structures make up a significant portion of programs. As a side note, I took a look at a Clojure grammar also specified for antlr[3]. My initial thought would be that Clojure's grammar would be appreciably smaller. It is, but not by as much as I was expecting. There are a lot of very little additions to the reader that add up [4][5][6]. [1] - Scala's syntax http://www.scala-lang.org/files/archive/spec/2.11/13-syntax-summary.html http://www.scala-lang.org/files/archive/spec/2.11/13-syntax-... [2] - Examples https://github.com/lrlucena/grammars-v4/blob/master/scala/scala.g4#L96 https://github.com/lrlucena/grammars-v4/blob/master/scala/sc... [3] - https://github.com/laurentpetit/ccw/blob/3738a4fd768bcb0399630b7f6a6427a3066bdaa9/clojure-antlr-grammar/src/Clojure.g https://github.com/laurentpetit/ccw/blob/3738a4fd768bcb03996... [4] - http://clojure.org/reference/reader#macrochars http://clojure.org/reference/reader#macrochars [5] - https://yobriefca.se/blog/2014/05/19/the-weird-and-wonderful-characters-of-clojure/ https://yobriefca.se/blog/2014/05/19/the-weird-and-wonderful... [6] - See "Special Characters" http://clojure.org/api/cheatsheet http://clojure.org/api/cheatsheet