This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-07
Channels
- # babashka (7)
- # beginners (218)
- # boot (1)
- # chlorine-clover (2)
- # cider (36)
- # cljsrn (8)
- # clojure (71)
- # clojure-dev (9)
- # clojure-europe (11)
- # clojure-france (1)
- # clojure-italy (5)
- # clojure-nl (5)
- # clojure-uk (24)
- # clojurescript (9)
- # conjure (16)
- # cursive (65)
- # datomic (76)
- # devcards (21)
- # emacs (1)
- # etaoin (1)
- # figwheel-main (47)
- # fulcro (37)
- # hyperfiddle (9)
- # java (2)
- # kaocha (1)
- # malli (11)
- # music (14)
- # observability (8)
- # off-topic (32)
- # re-frame (13)
- # reagent (2)
- # reitit (5)
- # ring (3)
- # shadow-cljs (40)
- # slack-help (17)
- # spacemacs (15)
- # tools-deps (5)
- # xtdb (16)
https://www.youtube.com/watch?v=WyjWUdkwPaQ Amazing sound/song by Burna Boy ... feels like summer in my heart
https://openjdk.java.net/jeps/378 I didn't realize Java was about to add this feature. Are there plans to add recognition of these new string/text block literals to the Clojure compiler/interpreter?
clojure doesn't use the java compiler anywhere, so I don't see how it would be relevant
I guess the java compiler is used to compile clojure itself, but clojure doesn't really need string literals like that?
there's no clojure interpreter, the compiler turns all input into jvm bytecode before running it
I guess it would be clearer to say that eval
turns input into bytecode before running it
(`compile` also exists, for when you want to write bytecode to disk instead of running it)
For me this is a text block š (valid since 1.0/2008)
(def html "
<html>
<body>
<p>Hello, world</p>
</body>
</html>
")
the difference is you need to escape \
I guess
supporting multi-line text blocks has been requested, considered, and rejected multiple times in Clojure's history and we are not going to add it
the rationale is mostly a) we've done fine without it and b) would break all Clojure parsers in existence
String as a datatype is also bad, you are better off using clojure collection literals containing strings and writing your io functions to take collections of strings instead of using big string literals
my two least favorite API decisions are concretizing File for input / output and String for the result of accessing input / source data to output
clojure.string fns all depend only on CharSequence by design
but I'm sure there are many less careful places
but I'm sure there are many less careful places
cargo cult unixism?
It was so nice that they can be nested but also āinvalidā in the general list sense for the sake of efficient IO and avoiding expensive copy operations.
I keep intending to play with erlang
my current "new language" project is assembler (learning ARM assembler and reading TAOCP), but erlang is definitely on the list
no OS!
what I'm seeing is that a lot of what I'm learning (especially via TAOCP) applies to the jvm (via the ASM.java lib that clojure uses to compile classes), luajit, wasm - there are a lot of things that provide APIs that try to look like a CPU architecture, and its useful for debugging, security, or getting highest performance possible from tight spots in code
I'm thinking about making some lisp helpers to generate assembly code, and I'm realizing that path leads to making a bootstrapping compiler after a few steps