This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-22
Channels
- # announcements (1)
- # beginners (109)
- # boot (2)
- # calva (26)
- # cider (6)
- # circleci (6)
- # cljsrn (3)
- # clojure (77)
- # clojure-dev (5)
- # clojure-europe (28)
- # clojure-finland (1)
- # clojure-hamburg (1)
- # clojure-italy (21)
- # clojure-japan (13)
- # clojure-nl (36)
- # clojure-spec (22)
- # clojure-sweden (4)
- # clojure-uk (105)
- # clojurescript (91)
- # community-development (8)
- # cursive (60)
- # datascript (3)
- # datomic (4)
- # emacs (33)
- # fulcro (19)
- # graalvm (38)
- # hoplon (4)
- # instaparse (1)
- # jobs (1)
- # leiningen (22)
- # off-topic (14)
- # pathom (2)
- # perun (4)
- # planck (5)
- # re-frame (10)
- # reagent (1)
- # reitit (11)
- # rum (11)
- # shadow-cljs (97)
- # tools-deps (82)
- # vim (53)
Morning! I've been writing a little demo to show people at work Clojure - it's a "port" of a kotlin app that does a few rest calls, a bit of transformation, consumption from kafka, into clojure
@guy, edn topics? never heard of that - is that data stored in edn format on topics?
Yeah @U11EL3P9U We have avro, json and sorta âinternalâ edn topics.
If you have clojure kafkastreams app using all the data, it seems silly to turn it into json and back agian
k, thanks. Actually, it's a little demo showing the ingestion of data in JSON format (from one of our production streams) and doing an upsert via a restful api call
morning
this reminds me some discussions around similar topics. so perhaps worth mentioning that there are edn parser libs for other langs/platforms too
although you could possibly argue that transit is more for this kind of thing reallyâŚ
(def my-map {:a "A value"
:blarg :another-value
:foo {:test "A nested map"
:c :d}})
(def my-map {:a "A value"
:blarg :another-value
:foo {:test "A nested map"
:c :d}})
cursive has the later as the default, which I sorta see makes sense, esp with large edn files with lots of submaps
imho makes it easier to read, but <shrug> since I'm a total n00b at this, just gaining feedback
The clojure style guide, "https://github.com/bbatsov/clojure-style-guide" doesn't say one way or the other which is preferrable.
I just find all the white space hard on my eyes, and itâs weird to me that adding a later key changes all the spacing of earlier ones potentially.
I personally tend to prefer the former (unaligned) unless youâre emphasising some pattern. I find aligning breaks the flow of clojure code. Otherâs prefer aligning. Itâs just a preference. FWIW Rich Hickey doesnât align either; but some would say his unconventional approach to formatting java means heâs not to be trusted on such things đ
I personally donât mind his java formatting. There is a certain logic to it.
Though I do prefer a more classical style.
Definitely can see the logic or it, I just remember the first time I looked at the Java stuff in Clojure and thinking, (with more than a little awe...), âthis man gives precisely zero fucks...â.
15 years of Java work, debating all the little style and convention issues, and Rich just comes along with a stonking rendition of, âI did it myyyyyyyy way!!!â đ
Yup, 100% agree. I remember first looking at his Java code, thinking - "Was this code autogenerated?"
Anyhoo, thanks peeps for the feedback, I guess it all comes down to (as in much of life) as "it's up to you..."
I have all my let
and {}
values aligned, makes it much more readable and aesthetically pleasing to my eyes. I use the CIDER settings to vertically align and aggressively indent on my own projects.
I donât indent as it looks messy to me - and different editors will try and do different things to it ime
and line-endings are inconsistent across different platforms too, and there's the whole 100-year-tab-space-war thing, so i agree @alex.lynham, better to just put everything on one line
tbh my default for clojure is âwhatever paredit does for me is probably correctâ đ
đŻ â though clojure-mode is what typically does indentation in Emacs but point still stands. clojure-mode, and originally probably lisp-mode is essentially what the style guide was based on.
aha TIL
I assumed it was paredit bc of the structural side
major-modeâs normally do the indentation⌠though minor-modeâs might do it too⌠not sure tbh
but itâs usually your language mode thatâs doing it
but donât quote me on that â itâs Emacs and might as well be the wild west đ
I think that this does raise the intriguing question of, âwhy does the way we view code have to correspond to how itâs stored?â. Why do two people, on the same team, with different preferences, have to fight it out? Why canât I just configure my editor to give me my preference, and they, theirs?
indeed, another old argument đ
There is also a movement pushing for a gofmt approach⌠https://news.ycombinator.com/item?id=18620309 which makes sense; but I canât see it happening.
@wesley.hall the easy answer (particularly in C) is that we encode intentions that can't be inferred into our indentation.
We are struggling to write a formatter that works for one case that makes people happy, let alone a customizable one for individuals.
@dominicm Indeed. I would imagine that this kind of things might be difficult in some language, but this should surely be another strength of Clojure right? If we are really drinking the, "code is just data" cool-aid. Then why not decouple code and presentation. Why can't my editor config be "CSS like"?
@wesley.hall common misconception, clojure is harder (depending on how you measure). Because of how macros are formatted.
People want to format macros differently depending on the specific details of the macro
You can put that formatting info into the macro def though
For example cider reads this info according to this spec: https://github.com/clojure-emacs/cider/blob/master/doc/indent_spec.md
But then you need a running JVM, graal cannot help with this because you need an evaluator. This is another point of contention.
Not sure you need eval for this. You donât need to expand the macro, you just need to be able to read syntax and resolve symbols to their definitions, and when a symbol resolves to a macro parse the :style/indent
off the defmacro
form.
You should be able to do this statically for 99% of cases⌠but I could be missing something.
Whether to be static or dynamic is pretty contentious in itself. You can cover most cases by just doing core & core libraries, but people still get upset
Well thatâs a difference between cider and cursive; there are clear trade offs with eachâŚ
My point is that to use :style/indent
for formatting you can do it reliably with either approach.
so cider can do it dynamically
and a 3rd party graal based command line tool could do it statically
theyâd just need parse-clj available or an equivalent
yeah tools.reader would do it
havenât seen trin before
ok so trin is expanding on what Rich did in REBL
yeah just read further⌠maybe not
but could possibly support that use case but handle the case of anonymous functions and their transitive deps
which Richâs reflection implementation didnât
naturally
phew! I just got my head around destructuring nested maps (for binding in a let)
but you know what, it was fantastic - just playing around, trying out different things and having the repl report back an error, or missing names, was great!
Hello, my name is John. It has been two years since I wrote my last macro...
âDonât write macros unless you need to, but really someone else has probably done it alreadyâ
we have 67 defmacro
and 5432 defn
... sometimes there is no substitute for a macro
how would that work @dominicm?
@mccraigmccraig it probably wouldn't tbh :) everything is out of order
Indeed. There are lots of funky tricks you can do for more advanced macros⌠calling macroexpand in your macro is one neat trick đ, adjusting expansion orders / walking syntax are others.
Also things like: https://github.com/ztellman/riddley