or you might need to change all matter of things

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

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.

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)

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

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

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 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: https://stuartsierra.com/2018/07/06/threading-with-style

@hiredman Ascii85 looks cool

Hi

I'm from Venezuela

I'm the new noob 😅

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:

Exception in thread "main" java.lang.RuntimeException: No such var: cljs.repl/*repl-env*, compiling:(figwheel/repl.cljc:1368:15)    

Any help would be appreciated.

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

no

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)

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