Fork me on GitHub

or you might need to change all matter of things

Kelly Innes00:01:20

Makes sense. I think that encourages writing functions that take their arguments in a certain order


with feed this is not a breaking change


there are ways to write that kind of thing in -> too

Kelly Innes00:01:12

I don't mind as->, I think it's nice. However I've tried out doing similar stuff with Lodash in JavaScript using flow and sometimes end up with some partialRight type stuff simple because of the argument order.


they just aren't as nice


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


where it concerns adding new things to existing code


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


#1 don't use positional arguments


#2 copy and paste the function with a new name leaving the old one in place


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.

πŸ‘ 5

a question: say I write code that programmatically changes -> to comp. does this affect the semantics of the program?


it is complicated


but likely no, assuming you get the transformation correct


(the change to comp will add an extra strackframe, which likely won't break anything)

βœ”οΈ 5

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


Why would you refactor -> and not just nest as-> or ->>


aesthetics, quadron doesn't like the look of it


I don't like to mutilate my perfectly wholesome lambda just to make -> happy


If you don't like the esthetics, you could adopt -<> or it->


Its the macro version of your feed


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


Which take their collections first

πŸ‘ 5

switching from -> to 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

πŸ‘ 5

the cure for that is, as I said, passing maps, leaving functions in place instead of changing them

βœ”οΈ 5
πŸ’‘ 5

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 map, filter ops on a collection. while I find myself using -> for doing assoc, dissoc, 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:

πŸ‘ 5
Carlos Garcia09:01:02

I'm from Venezuela

Carlos Garcia09:01:36

I'm the new noob πŸ˜…

Vincent Cantin09:01:24

❀️ 5

Hi all, I'm trying to build this project:, following instructions here: When I run clj -A:figwheel --build dev --repl, I keep getting the error:

Exception in thread "main" java.lang.RuntimeException: No such var: cljs.repl/*repl-env*, compiling:(figwheel/repl.cljc:1368:15)    
I have clj version 1.9.0 and leiningen installed from AUR repository.


no idea about the error, but you might get more help at #klipse


That var was introduced with ClojureScript 1.10. Perhaps you are using ClojureScript 1.9?


The dependency in deps.edn is 1.10.64


Well, it actually landed in the 1.10.126 build.


1.10.238 was the first 1.10 release FWIW


(non-beta release)


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.


If I revert to a version from July, everything works perfectly.


Any help would be appreciated.


is there a cap (8?!) to the number of go processes?


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)


i am simulating a network with a lot of nodes, assigning a go-loop to each one


sure that is fine


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


the size of the threadpool just limits the number of go blocks that run in parallel


so if you run go loops without doing channel ops, you can end up taking over the threadpool as well


(and that is only for the clojure version of core.async, the clojurescript version shares the one javascript thread)

βœ”οΈ 5

hi ppl, I'm with some problems using re-matcher sometimes it finds the match and other don't. For example consider this code:


but re-seq and re-find are able to find matches