This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-05
Channels
- # adventofcode (50)
- # announcements (1)
- # asami (29)
- # babashka (56)
- # beginners (19)
- # calva (62)
- # cider (12)
- # cljs-dev (1)
- # clojure (42)
- # clojure-europe (214)
- # clojure-france (4)
- # clojure-italy (1)
- # clojurescript (58)
- # community-development (4)
- # cryogen (6)
- # cursive (7)
- # data-science (1)
- # events (3)
- # figwheel-main (1)
- # fulcro (21)
- # lambdaisland (3)
- # malli (17)
- # mid-cities-meetup (1)
- # off-topic (38)
- # pathom (3)
- # reagent (7)
- # reclojure (1)
- # reveal (15)
- # rewrite-clj (11)
- # shadow-cljs (30)
- # sql (21)
- # test-check (14)
- # tools-deps (1)
- # vim (21)
- # xtdb (5)
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
Having it in JS feels exciting to me for exposing the ideas in SICP to a much wider audience.
@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 :-)
@dharrigan there is this project: http://www.sicpdistilled.com/ but I think it stalled
if it's impure, I would prefer get-classpath!
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.addURL
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 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
spec uses registry
for getting the registry from an atom, but get-spec
for getting a spec by some key
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