Clojurians Log v2
off-topic
Just mentioned by Julie Sussman at the re:Clojure conference:
Also up-and-coming from Gerald Sussman (middle of next year, they estimated) https://www.amazon.com/gp/product/B089423GC6/ref=ppx_yo_dt_b_d_asin_title_o00?ie=UTF8&psc=1&fpw=alm
Still waiting for the Clojure edition ;)
But meanwhile I have the printed Scheme version here. Should really just read it.
Having it in JS feels exciting to me for exposing the ideas in SICP to a much wider audience.
Yeah, I agree!
And this could eventually lead people to CLJS too
@eggsyntax Have you read Grokking Simplicity by Eric Normand? A lot of FP presented in JS.
Haven't yet, but planning to at some point. Not a fan of JS, to be honest, but I've read a fair amount of Eric's blog and it'll be neat to see a culmination of those ideas. Perspective from two hours later on SICP/JS -- looking back, I feel like part of the magic of SICP was starting with something so simple that you could grasp it in its entirety, and building the rest from there. I'm curious about how well that'll translate to JS with all its idiosyncrasies -- maybe they start with a tiny subset of JS and build from there? Maybe build it into what JS might have been if it'd been built today in a more considered way rather than being added to piecemeal over decades from a rushed start?
I'm definitely no fan of JS either but Eric's book is good (although the JS hurts my eyes at times 🙂 ).
When I went through (some of) SICP many years ago, I used Python, since that seemed the most appropriate language that I knew at the time and Clojure didn't yet exist. I definitely didn't get the magic feeling of building everything from the ground up but it was still very interesting. I feel like doing it in Clojure would be similar.
(And JS, though I have no desire to do that :-)
I would really really welcome a Clojure version of SICP
@dharrigan there is this project: http://www.sicpdistilled.com/ but I think it stalled
5 years stalled :s
but thank you for the link, will read what is there...
any opinions? https://twitter.com/borkdude/status/1335310728199335936
if it's impure, I would prefer get-classpath!
how impure would you consider reading from an atom to be on a scale of 1-10?
The other function is called add-classpath (without exclamation mark, same as Clojure used to have)
well, on a scale from 1-2, it's a 2.
user=> (doc add-classpath)
-------------------------
clojure.core/add-classpath
([url])
DEPRECATED
Adds the url (String or URL object) to the classpath per
URLClassLoader.addURLfor counter-examples
I think the ! is more important for a function like get-data than add-data as add-data is more likely to imply that the operation is impure.
Does the classpath only grow? or can it shrink?
The function deref itself also hasn't an exclamation mark btw :)
right now we only have add-classpath so right now it can only grow
the point of deref is to conduct a side effect. I think the ! helps especially when it might not be obvious that a function is impure. If you think get-classpath successfully conveys that, then it's probably fine.
the question wasn't: get-classpath or get-classpath! but rather classpath or get-classpath
but I can we can extend the poll to three options
spec uses registry for getting the registry from an atom, but get-spec for getting a spec by some key
so maybe get- also implies some lookup thing and some container thing
personally, I feel like you gain more by saying "watch out! this is impure" and having a ! than any downside of having a ! , but I'm probably in the minority and it's probably fine either way.
if that's the convention established by core clojure code, there's definitely a benefit to matching convention
Boot uses get-classpath: https://github.com/boot-clj/boot/blob/master/doc/boot.pod.md#classpath
If it is subject to change call it “current-classpath”?
not bad
I use "current" in these cases too.