So I recently learned about de Bruijn indices ( https://en.wikipedia.org/wiki/De_Bruijn_index ) and it occured to me that it could be used as a "solution" for Clojure's lack of nested #() functions, allowing things like:
(map #(every? #(< % 5) %)
[[1 2] [3 4] [5 6]])
If the inner function needed to access the outer parameters, we just increment the number of %
s according to the number of levels "outwards" we want to jump, so there's never any ambiguity:
(map #(every? #(< % (count %%)) %)
...)
I think there's another reason to not nest #()
(babashka currently allows it, that's an oversight and will change): it's more unreadable. I would say, just use fn
and meaningful arg names.
Yeah I'm not disputing that - no doubt it was a conscious language design choice to avoid readability disasters, I've just always been slightly annoyed with how #()
doesn't compose and thought this was an interesting way around it
(This comes up sometimes when writing throwaway code to inspect data, I'll write a quick #() argument to max-key
just to find that oh, it's not compilable because of an enclosing form)
I'm trying to write a good and proper bash script for some particular dev task. But the more proper it becomes, the harder it gets to write it. "I need an array of arbitrary values that might have spaces and newlines". A voice in my head: "babashka would help here". Me: "Yeah, but it's just one place." "I need to diff two arrays". The voice: "babashka". Me: "Maybe later". "I need a function that accepts N arrays and returns another array, and that correctly handles edge cases with empty arrays". Yep, it's babashka time.
I would have reached for Python or Clojure at the first step there ๐
Bash is one of those things that I always actively refused to learn beyond a stackoverflow copy/paste. Seems like the most arbitrary syntax ever ๐
@borkdude is that before you did babashka? ๐
I think it's the same kind of satisfaction you get from solving type system puzzles, not problems, which Rich mentioned in one of his talks. You're fighting with an arcane tool but when you get it finally working, you have this sense of satisfaction. But you could have just avoided spending all that time by just using Clojure. :)
100% agree.
honestly bash is pretty cool, just too niche for me to learn and keep warmed in my brain-cache
I remember playing around with developing some make-like task runner that sent commands to a JVM daemon. the advanced features you get from bash + basic GNU toolbox is pretty amazing
:bikeshed: if I was building a framework whose core public API was very clojure-y, but I also wanted to deliver a monadic API with things map
, bind
, return
, etc. what could I call that namespace?
foo.monad
?
I was thinking about foo.monad
but then I started wondering if there was a clearer way to name it - maybe a lot of people who do Clojure know monads, but not everyone
Hereโs their opportunity to learn :)
In my experience itโs better to give something a precise definition that can be learnt once and understood forever more than a friendly one that is ambiguous and confusing or misleading
exactly, therefore I suggest foo.monad-is-just-a-monoid-in-the-category-of-endofunctors
. And maybe slap a .core
in the end just to make it familiar ๐
lol
I see your point marrs
I say this as someone who still couldnโt tell you what a monad is, despite having learnt Scala cats well enough to have used it successfully in a real project. Not sure what the lesson of this experience is
I expect the reason that people would reach for the monadic API would be either for performance or because they just sort of enjoy the aesthetics of algebraic composition ๐ so advanced usage
On the subject of scripting shells, Iโm a recent convert to Fish
There was a blog post making the rounds a while back where a Common Lisp (I think) programmer compared CL and Clojure REPLs and explained some of the features Clojure editors/REPLs don't have that CL does. Anyone happen to remember that post and have a link handy? My Google-fu isn't strong enough to find it, it seems. In general, if you have any wisdom to expend regarding some of the more advanced REPL features that CL/Scheme/Racket have but Clojure doesn't, I'm interested.
I think conditions are the biggest feature missing from Clojure compared to CL or Scheme
just from a dev UX standpoint, the ability to interactively halt your program on an error, modify, then resume it where it left off is pretty awesome
Thanks! That rings a bell, and I think itโs something that was also mentioned in the blog post.
There was a brief interaction in #beginners channel yesterday on this, starting here: https://clojurians.slack.com/archives/C053AK3F9/p1615601443403100
Thanks! Iโll check that out.
Which included someone sending a link to this project on Github, which lists several similar things that people have created to do interactive kinds of debugging/dev at a Clojure REPL (I haven't used any of them, but its README of other projects looks like a pretty nice list to go through, if you want to see whether they do what you want): https://github.com/clojureman/special
re condition systems, there was a great talk at the conj a couple of years ago about this in Clojure context https://www.youtube.com/watch?v=zp0OEDcAro0
Thank you! Will watch that. ๐:skin-tone-2: