Are there any plans for exposing a Clojure API? Given that it's implemented in Clojure, seems like it would be a natural fit. Interop with Java is nice but can be cumbersome compared to the more natural calling conventions and idioms (threading macros instead of `..` builder patterns, etc).
Reader macros/literals allow for explicitly differentiating between built-in data types, and provide semantic meaning to otherwise indistinguishable forms. For example, defining a function:
In Racket, you write `(define (foo arg1 arg2) (+ arg1 arg2))`. Why isn’t `(foo arg1 arg2)` evaluated as a function? It’s a list and it isn’t quoted, so it should be evaluated. However, `define` is a macro (I think, might be a special form), so that list isn’t evaluated and doesn’t have to be quoted. That violates the basic tenant of “unquoted forms wrapped in a list are evaluated as fiction calls.”
In Clojure, you write `(defn foo [arg1 arg1] (+ arg1 arg2))`. The [] is a reader macro, a vector literal. It communicates that it’s not a function call but simply data (in this case, a vector containing two symbols).
Maybe I’m just used to it but I find this stuff really helpful.
I would agree more with this view if there was also an explicit indicator for lazyness: in (define (foo arg1 arg2) (+ arg1 arg2)) the two parts (foo arg1 arg2) and (+ arg1 arg2) are both interpreted specially; the former as a data structure and the latter as code with delayed execution.
I'll probably have a compatibility option to enable them but my primary reason is that it is a less elegant design. If the benefit of `and` and `or` is linguistic comfort then that goes away with `and=` (at least for me).
If you don't care about code reviews, why care about a PR process? don't protect the branch and just make your commits. The notion of a pull request is you're requesting someone pull in your changes. But you don't want them to review those changes?!
I roughly agree with you but in your deps.edn example, how would you like the tool to respond? Your map/dictionary/object has an uneven number of forms, so what else would you like it to say?
The mistake the programmer has made is copy-pasting a line that wasn't meant to be copy-pasted. The error is gobbledegook about implementation details of the deps file, saying a map is malformed in a file that has 5x maps and not much more to bring in 2 dependencies. The error message itself isn't the problem as much as the spartan design of the deps file that leads rookies into screwing up in a way that isn't obvious what went wrong. There are a lot of easy syntax errors here that give no useful error message explaining what went wrong. There isn't even a hint how many maps are needed to bring in those 2 dependencies (turns out, 4). It'll bleed newbies if they try to figure out this file.
I think their should be a "lein-for-deps-template" that subtly guides people in the right direction by starting the project up with 2+ dependencies. Lein dodges this by using a list-of-list data structure where this mistake is harder to make (copy and pasting stuff in brackets is the right strategy in lein) and there is much more boilerplate in a project.clj to hint what our aspiring Clojure programmer needs to fill in.
My problem here is that the entire way through that story, at no point is there a simple prompt in the official reference documentation telling people what a deps file with multiple dependencies should look like. Even finding the examples of 1 dependency is quite deep in and seems to be an advanced topic (you'll note the sibling comment that considers dependencies an advanced topic for people who already know the language well enough to reflexively get maps right, and it says a lot about the actual complexity of deps that the official guide to installing dependencies thinks 2x dependencies is out of its scope).
I just tried breezethat and had to scroll past 6 ads (two screenfuls on my iPhone 10) to see a single result. I know ads are necessary but this is punitive.
Wow, massassi.net is quite a trip through time. I spent many many hours on your site, playing Jedi Knight with friends and randos through GameSpy. Endless hours of entertainment toying with JED, trying to perfect my own levels, or installing various mods and texture packs.
Thank you for the effort, you gave me quite a few cherished memories.
Clojure has that built-in and it’s great. Works wonders when testing things too: write a small test in a comment block and you can edit/evaluate a function then move to the comment and see the result immediately.
Are there any plans for exposing a Clojure API? Given that it's implemented in Clojure, seems like it would be a natural fit. Interop with Java is nice but can be cumbersome compared to the more natural calling conventions and idioms (threading macros instead of `..` builder patterns, etc).