This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # aws (27)
- # beginners (67)
- # boot-dev (1)
- # cider (25)
- # cljs-dev (6)
- # clojure (192)
- # clojure-europe (1)
- # clojure-gamedev (1)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-russia (1)
- # clojure-spec (9)
- # clojure-uk (12)
- # clojurescript (41)
- # cursive (1)
- # datomic (22)
- # figwheel-main (4)
- # funcool (1)
- # hoplon (1)
- # kaocha (11)
- # klipse (7)
- # off-topic (1)
- # overtone (1)
- # pathom (24)
- # portkey (9)
- # re-frame (129)
- # reagent (3)
- # rum (1)
- # spacemacs (1)
- # specter (6)
Makes sense. I think that encourages writing functions that take their arguments in a certain order
flow and sometimes end up with some
partialRight type stuff simple because of the argument order.
yeah but I have to go back and change the code I've already written or write code that looks stuppid
look, if you are learning something new, you should expect it to look different and strange to you, and you cannot hold the newness against it, because that will go away
I'm not talking about novelty, I'm talking about the central idea to clojure which is immutability
I would caution against having seen a talk about clojure and deciding you know what clojure is all about
rich hickey himself seems to be very concerned with immutability of written code, just listen to him talking about Maybe
and in rich's talks he gives a lot of possible solutions to that kind of code brittleness
right? the real issue isn't with
-> the issue is with the stuff you give to to
-> changing its contract
so either make the contract more flexible (pass a map) or creating a new function if you change the contract
@veix.q5, I don't see anything wrong with avoiding -> and ->> if you don't like them. You can always change your mind. I remember being wary of them for a while myself, because they aren't perfectly general (due to the fixed parameter position as you said). I started using them when I ran into lots of common cases where they fit quite well and for me they increase readability quite a bit now.
a question: say I write code that programmatically changes -> to comp. does this affect the semantics of the program?
(the change to comp will add an extra strackframe, which likely won't break anything)
but I would just recommending getting comfortable with
-> if you plan to read clojure code written by others or share the clojure code you write, in general the various threading macros are used more often then comp is
I see it as some what analogous to learning another language that was pretty strict on subject, object, verb order in sentences, but insisting on using a tortured sentence construction so you can order things similar to how you would order them in your first language (assuming it in'ts sov) because you like that better
maybe i am being pedantic here. but as i said, i used to use -> a lot. but every time, i just find myself reaching for a more general form. I was just wondering if there is something to be aware of -> being a macro and all and the fact that I'm not well-versed in macro stuff
There's also a visual queue to -> and ->>. Its a convention, but one that is nice to follow. ->> is used for lazy returning functions, as it takes the collection last, while -> is for threading eager things
feed doesn't obviate the need to keep up to date with those changes
also, it does not help that forms within -> are now made to fit the -> contract and are not copy-paste-able
the functions you pass in to
feed are adapters from what feed expects to what your other function takes, and when you change what other functions take, you'll need to update your adapters
the cure for that is, as I said, passing maps, leaving functions in place instead of changing them
I think threading macros are really just to make code readable. Whether you decide to use them or not is up to you. But I would agree it is probably a good idea to understand how to use them considering how ubiquitous they are. If you need to deal with inconsistent position of args then you can always use anonymous functions or nest threading macros.
->> is very convenient for using many
filter ops on a collection. while I find myself using
-> for doing
update ops on a map.
Feed can work also. It's true what @hiredman is saying. If you are still learning Clojure, its best to stick to the idoms and give them a shot. They can take a while to click. Like I feel maybe you don't use let enough. Or you're trying to thread too many things that weren't designed together, having to reach for as-> for example should be extremely rare. That said, Clojure is a Lisp, and can adapt to what you prefer. If you're familiar with the language and idioms. I think it's fine for you to modify what you don't like. So in that case, go ahead and use
feed. You'll see also after using that too, if you truly like it better.
This was helpful when I first started learning about threading macros: https://stuartsierra.com/2018/07/06/threading-with-style
Hi all, I'm trying to build this project: https://github.com/viebel/klipse, following instructions here: https://github.com/viebel/klipse/blob/master/contributing.md
When I run
clj -A:figwheel --build dev --repl, I keep getting the error:
I have clj version 1.9.0 and leiningen installed from AUR repository.
Exception in thread "main" java.lang.RuntimeException: No such var: cljs.repl/*repl-env*, compiling:(figwheel/repl.cljc:1368:15)
That var was introduced with ClojureScript 1.10. Perhaps you are using ClojureScript 1.9?
Hm, I'm also seeing a bunch of other issues with the latest commit in this project. For example,
lein fails with
clojure executable not found.
there is a cap on the size of threadpool the processes run on, a which you can change using a system property that is somewhere on the docs
if you find yourself having issues with the limit it is often the case your are running stuff in go blocks that you shouldn't (blocking the threadpool)
just make sure you only use the parking (not blocking) channel operations (the single ! variants) and don't block (do blocking io, wait on a lock or promise, etc) in your go blocks
go blocks are more or less cooperatively multithreaded running on their threadpool, every channel operation can yield the thread to another go block
so if you run go loops without doing channel ops, you can end up taking over the threadpool as well
hi ppl, I'm with some problems using
re-matcher sometimes it finds the match and other don't. For example consider this code: