Fork me on GitHub

so far i’ve enjoyed using tools like map filter and reduce


especially map vs using loops


my question is this… if you want to iterate based on a condition being met, is your best bet (is it idiomatic) to use loop and recur in a function?


in particular as it relates to 4clojure problem 66, but i dont want to give anything away


not sure but maybe filter or my favorite into


@chadhs: are you asking how to do something like while in other languages? Take a look at reduced


thanks martin i’ll check it out


does it make sense to start learning clojurescript if i dont have experience with clojure?


@zefreak: Totally, learning it will also learn you clojure at the same time


Clojure and clojurescript share most of the functions, there are not that much differences


I recall some kind of beginner end to end web tutorial called something like clojureone but I can't find it... any hints?


Once upon a time there was ClojureScript tutorial that was hosted at but that now redirects to clojurescript on


@parameme: it wasn’t a ClojureScript tutorial, it was a ClojureScript One tutorial which is now long deprecated

dnolen12:01:35 is the one that covers both front/back end I believe


Looks superb!


cool, thanks


Any way to grab all dependencies for that tutorial series? Be nice to work on during a plan ride, but fear I would get 4 lessons in and not have access to some library needed.


As a github project I imagine you could download a ZIP archive.


Yeah, I meant more these things: :dependencies '[[adzerk/boot-cljs "1.7.170-3"]])

Josh Horwitz19:01:10

I’ve worked through a few books but I am looking to dive deep into the Clojure world


Hi @joshua.d.horwitz ! Have you looked at the puzzles? That’s a good way to hone your skills and get deep understanding of Clojure’s rich world of functions.

Josh Horwitz20:01:25

I have a little bit, they are waaay harder than I though, I thought I had a better grip than I acutally do!


Yeah, that’s what makes it rewarding because it gets you from "familiar" to "understanding".


What’s your programming background?

Josh Horwitz20:01:40

and a lot of grazing knowledge of others


Cool. Probably the hardest thing about Clojure for folks coming from a Java / OOP background is shifting from the encapsulated state / mutation mindset to the raw data / pure function mindset. So it’ll depend on how far afield from Java you’ve "grazed" 😸


Yeah, that’s a big improvement over what was on the old site.


(I still need to submit a few PRs to get Boot mentioned more prominently wherever Leiningen is mentioned! 😈 )


I got it into the Tools section on the Resources page but feel it deserves a higher profile.

Josh Horwitz20:01:54

Thanks guys! I agree, I can understand the syntax and write a function, but getting ober to the raw data/ pure function mindset is tough

Josh Horwitz20:01:52

Thanks! I appreciate the help. It’s nice because there is actually a really cool Clojure shop in the city I live in


I'm kind of struggling to refactor my code into different namespaces. I'm getting bitten by a circular dependency error, though. Is there a sane way of splitting code that all depends on the others from time to time? For instance, a utils namespace is fine since it never uses anything outside it, but gameplay and actions are two things I want to separate but can't because gameplay can trigger actions and vice versa.


@danielcompton: You set the BOOT_JVM_OPTIONS environment variable.


does that do it for the app or for Boot?


Or are in the same JVM?


They are the same — there’s only one JVM involved with Boot.


Leiningen has two: the Leiningen JVM and then the second JVM it fires up for the app itself.


We calculated :jmv-opts dynamically in project.clj for Leiningen so that was a big change for us when we switched to Boot. We solved it by writing a wrapper shell script for Boot (which ended up being much simpler than what we used to do in Leiningen anyway) and not having the overhead of a second JVM spinning up for a lot of things was a nice bonus.


hey @slester maybe one way of thinking about this, particularly in a game which probably has an event loop of some sort, is to look at the role that data can play both in decoupling dependencies between functions and in improving overall program comprehensibility. The act of "triggering" an action via some logic in gameplay could be implemented by sticking a map describing the action, e.g. { :action :something :payload {}}, onto an event-loop queue. Then the code handling the event-loop can decide what functions to execute in response to popping off a specific action map. This general pattern is called a "dataflow architecture" and it can really help in managing complexity. One of the things that's nice about this is that it becomes easy to recreate particular game situations just by saving and replaying the event data.


@jonahbenton: interesting, I'll have to chew on that a bit before I fully understand it probably


@slester: sure, apologies, that was a pretty packed response.


the core idea to think about is replacing one of the dependencies where functions are calling functions directly- gameplay calling action functions, or actions calling gameplay functions- with a pattern where a function puts a piece of data on a queue or channel, and then something else processes the data on that channel.


@slester: @jonahbenton’s suggestion can definitely be a good approach in my experience. A couple of other approaches to consider: - Circular dependencies can often be a code smell, suggesting that there’s some cleaner way to think about your architecture. - Sometimes circular deps are best addressed by adding an abstraction layer of protocols. - Worst case, if you’re sure there’s not another approach you feel good about, you can resolve some of the deps at runtime.


@jonahbenton: @eggsyntax: makes sense! And yes, definitely 'code smell' because I'm relatively new to full-fledged applications in Clojure. In the past they haven't really required multiple namespaces or anything intermediate-advanced


Clojure folks also, in my experience, are more comfortable with big namespaces than, eg, java programmers are comfortable with big classes, since namespaces are largely just an organizational convenience. So that’s another option too if your project isn’t too big — just combine the namespaces simple_smile. But that wouldn’t be my first approach unless I just wanted to kick the can down the road.


@eggsyntax: I originally had everything in one big file with some (declare)s up top. 😞


reading about multimethods is blowing my mind @_@


@slester You might really enjoy Stuart Sierra’s discussion of Clojure’s solution to the Expression Problem:


@slester: In addition to the excellent advice you've already been given I would encourage you to refactor you code often, even if everything breaks - the more you do it the easier it gets.


Also, I like to start with one file/ns and only break it up as the need arises over time.


I'm in the middle of refactoring my Alexa Skill for the 3rd time.


Cursive does a great job of giving you clues about circular dependencies and such. And has decent refactoring features as well.


Although not as much as I would like. 😞


I was fighting with parens in Cursive last night. I hand to go back to Light Table to get anything done. Once I'm more proficient in Clojure I think I'll give Emacs another try.


that's odd - I love parens in Cursive - and you can toggle paren-matching if you break it


@meow: I know the feeling of refactoring breaking everything 😞 I’m now in the “everything is broken” stage.


Clojure is easy to fix - you'll get it.


although the error messages are ... um ... (insert something gentle here) ... can't ... sucky