Fork me on GitHub
#beginners
<
2019-01-01
>
hiredman00:01:05

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

quadron00:01:21

with feed this is not a breaking change

hiredman00:01:10

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.

hiredman00:01:26

they just aren't as nice

quadron00:01:33

yeah but I have to go back and change the code I've already written or write code that looks stuppid

hiredman00:01:16

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

quadron00:01:41

I'm not talking about novelty, I'm talking about the central idea to clojure which is immutability

quadron00:01:15

where it concerns adding new things to existing code

hiredman00:01:38

I would caution against having seen a talk about clojure and deciding you know what clojure is all about

quadron00:01:22

rich hickey himself seems to be very concerned with immutability of written code, just listen to him talking about Maybe

hiredman00:01:20

and in rich's talks he gives a lot of possible solutions to that kind of code brittleness

hiredman00:01:29

#1 don't use positional arguments

hiredman00:01:48

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

hiredman00:01:50

right? the real issue isn't with -> the issue is with the stuff you give to to -> changing its contract

hiredman00:01:19

so either make the contract more flexible (pass a map) or creating a new function if you change the contract

5
jumpnbrownweasel00:01:28

@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
quadron00:01:13

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

hiredman00:01:41

it is complicated

hiredman00:01:57

but likely no, assuming you get the transformation correct

hiredman00:01:37

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

βœ”οΈ 5
hiredman00:01:21

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

didibus00:01:10

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

hiredman00:01:55

aesthetics, quadron doesn't like the look of it

5
quadron00:01:30

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

didibus00:01:45

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

didibus00:01:00

Its the macro version of your feed

hiredman00:01:32

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

quadron00:01:12

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

didibus00:01:54

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

didibus00:01:04

Which take their collections first

πŸ‘ 5
hiredman00:01:30

switching from -> to feed doesn't obviate the need to keep up to date with those changes

quadron00:01:53

also, it does not help that forms within -> are now made to fit the -> contract and are not copy-paste-able

hiredman01:01:11

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
hiredman01:01:37

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

βœ”οΈ 5
πŸ’‘ 5
chrisulloa01:01:48

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.

didibus01:01:59

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.

chrisulloa01:01:29

This was helpful when I first started learning about threading macros: https://stuartsierra.com/2018/07/06/threading-with-style

πŸ‘ 5
Carlos Garcia09:01:02

I'm from Venezuela

Carlos Garcia09:01:36

I'm the new noob πŸ˜…

Vincent Cantin09:01:24

❀️ 5
rachit13:01:39

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)    
I have clj version 1.9.0 and leiningen installed from AUR repository.

rakyi14:01:26

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

mfikes14:01:18

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

rachit14:01:41

The dependency in deps.edn is 1.10.64

mfikes14:01:46

Well, it actually landed in the 1.10.126 build.

mfikes14:01:00

1.10.238 was the first 1.10 release FWIW

mfikes14:01:15

(non-beta release)

rachit14:01:43

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.

rachit14:01:59

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

rachit13:01:46

Any help would be appreciated.

quadron21:01:51

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

hiredman21:01:59

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

hiredman21:01:15

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)

quadron21:01:45

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

hiredman21:01:55

sure that is fine

hiredman21:01:05

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

hiredman21:01:04

go blocks are more or less cooperatively multithreaded running on their threadpool, every channel operation can yield the thread to another go block

hiredman21:01:56

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

hiredman21:01:44

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

hiredman21:01:07

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

βœ”οΈ 5
bartuka23:01:40

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

bartuka23:01:01

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