This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-20
Channels
- # aleph (3)
- # beginners (14)
- # cider (70)
- # cljdoc (30)
- # cljs-dev (1)
- # cljsjs (6)
- # clojars (7)
- # clojure (88)
- # clojure-greece (1)
- # clojure-italy (3)
- # clojure-nl (17)
- # clojure-spec (1)
- # clojure-uk (54)
- # clojurescript (48)
- # code-reviews (2)
- # cursive (28)
- # datascript (3)
- # datomic (20)
- # docs (1)
- # emacs (16)
- # figwheel-main (17)
- # fulcro (13)
- # graphql (2)
- # hyperfiddle (2)
- # jobs (2)
- # nyc (1)
- # off-topic (39)
- # parinfer (1)
- # re-frame (37)
- # reagent (225)
- # remote-jobs (3)
- # ring (3)
- # ring-swagger (1)
- # shadow-cljs (110)
- # spacemacs (10)
- # spirituality-ethics (1)
- # test-check (3)
- # tools-deps (36)
- # uncomplicate (2)
- # vim (7)
so i "installed" clojure using leiningen (and boot too just to check it out) and in both it says I have clojure 1.8. Should I be using 1.9 or does it not even matter as a beginner? And if I did want 1.9 how would I do so? I actually just powerwashed my chromebook for unrelated reasons so this would be a fresh install.
in general, each project you create will have its own dependency on a specific clojure version
huh. ok. so the repl's using 1.8 won't really affect anything during my learning process then. and do i need the full jdk or can I get by with just install the jre?
the repl will use whatever clojure version is specified in your project, you are seeing 1.8 as just some kind of fallback behavior of the tools when invoked without a project
If you ever start learning about Clojure spec, then you will need Clojure 1.9, but until you get to that point Clojure 1.8 and Clojure 1.9 are nearly identical.
But yeah, if you are using Leiningen, switching between Clojure 1.8 and 1.9 is as simple as changing one line in your project.clj file, and I haven't used boot but would guess it is just as straightforward to choose.
For Boot, you set the Clojure version in ~/.boot/boot.properties
(since it only starts one JVM, unlike Leiningen).
yup, that worked easy peasy. thanks folks. i don't imagine i'll be at a level to really start using or understanding clojure spec anytime soon but more knowledge about how the ecosystem works can't hurt
I'm designing a data model for a somewhat complicated domain that will get turned into a json rest api, and I it occurs that I have a choice between making my entities out of nested maps according to subsection, or making them flat maps using occasionally longer keyword names. I'm not sure if there even is a "proper" way, but I can see benefits of both. Would you folks give me your opinions on this?
my opinion: +1 for flat maps. both when consuming and producing an api, nested maps are incidental complexity. which things should be nested in which? is a question which has no consistent answer. that said, when a flat model becomes too complicated, and loses coherence- that's a signal to create a different resource endpoint.
@achythlook in my view, the question is more whether you should normalize or not. if you are going to keep things structured (e.g. the ‘project’ map holds a vector of ‘task’ objects), then keep it structured: don’t try to build the structure into the key name. on the other hand, you may find that normalizing is actually easier to deal with (e.g., the ‘project’ map holds a vector of ‘task’ ids and the task objects are stored separately). i now prefer normalization, but there are definitely times when the denormalized view is the correct one