Fork me on GitHub
#beginners
<
2018-07-20
>
Chase00:07:59

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.

hiredman00:07:17

in general, each project you create will have its own dependency on a specific clojure version

hiredman00:07:42

there isn't really a system level clojure install

Chase00:07:07

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?

hiredman00:07:33

you should be ok with just the jre

hiredman00:07:11

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

andy.fingerhut01:07:26

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.

andy.fingerhut01:07:22

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.

seancorfield01:07:46

For Boot, you set the Clojure version in ~/.boot/boot.properties (since it only starts one JVM, unlike Leiningen).

Chase02:07:20

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

zaphodious18:07:05

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?

jonahbenton19:07:53

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.

justinlee19:07:09

@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