The page may have begun in an era when each of the few books available was heroic, you could read them all, and critical reviews were not really needed. But nowadays, ...Is euthanasia an option for this page? Improving it could be a hard job, and thankless, only to have it get outdated again. Unless you're ready to boldly and unapologetically limit it to 2 categories of 3 books each that you strongly recommend - With a scope of approximately "every book with Clojure in its name" it's quite a haystack, and the blurbs are still necessarily anodyne. clojure-docs does not throw tomatoes, and isn't expected to. And so, case in point (naming no names) - the single, solitary, sole, only objectively terrible book about Clojure that I ever bought is on this page with a bland blurb. This is a book whose 1- and 2-star reviews on a big bookstore site are correct and remarkably restrained and polite. Er - so - to make a long story short - clojure-doc could be forgiven for ceding this scope to the bookstores' global search for "Clojure" plus customer reviews.

That's a very valid option. I could simply defer to https://clojure.org/community/books as I'm doing with a few other sections of the site at this point.

Looks like Joy of Clojure 2nd edition is listed twice

@U01GQNJFP6U Yeah, I was trying to update some of the editions and then realized some books were listed multiple times -- once for each edition they had -- and others only had older editions and when I updated some of them, I ended up with an out of order list 😞 I think @U0HG4EHMH’s suggestion is good -- don't bother duplicating what's already on http://clojure.org (and don't try to list every book) -- so I'm retiring the ecosystem/books page at this point. Since CDS was originally created, a lot more content has been added to http://clojure.org so a big part of my initial cleanup work on CDS is going to be retiring outdated pages that have since had equivalent content added to http://clojure.org, and then making another pass over CDS to add links to those relevant pages... it's going to take several passes 😐

Well @U04V70XH6, I'd love to help if I could! Not sure what that would look like, but I'll try to keep an eye on the clojure-docs repo

Sequence or array?

But I'd write a short function using loop, I don't think it exists

(set! *unchecked-math* true)

(defn seq->arr
  [^Iterable xs ^objects arr]
  (let [it (.iterator xs)]
    (loop [i 0]
      (when (.hasNext it)
        (aset arr i (.next it))
        (recur (unchecked-inc i))))))

sequence in this case. nice, thank you, that looks great

There are some array copy methods in Java collection. I’d check which works faster. I suspect you could get into some fast paths using native stuff

iirc the .toArray methods allocate a new array and don't take an array target

System.arrayCopy takes a target,but the source has to be an array, not a Collection

Its not idiomatic but ham-fisted has an indexed-accum operator that allows your reduction to be indexed. This is faster than the iteration pathway for most (maybe all) sequences:

user> (def src-src (eduction (map #(+ 10 (long %))) (range 1000)))
#'user/src-src
user> (crit/quick-bench (seq->arr src-src arr))
Evaluation count : 17064 in 6 samples of 2844 calls.
             Execution time mean : 35.241389 µs
    Execution time std-deviation : 213.540713 ns
   Execution time lower quantile : 34.947208 µs ( 2.5%)
   Execution time upper quantile : 35.405822 µs (97.5%)
                   Overhead used : 1.515197 ns
nil

user> (crit/quick-bench (reduce (hamf/indexed-accum 
                                 acc idx v
                                 (aset ^objects arr idx v))
                                nil
                                src-src))
Evaluation count : 42384 in 6 samples of 7064 calls.
             Execution time mean : 14.201449 µs
    Execution time std-deviation : 264.329593 ns
   Execution time lower quantile : 14.008505 µs ( 2.5%)
   Execution time upper quantile : 14.656309 µs (97.5%)
                   Overhead used : 1.515197 ns

Found 1 outliers in 6 samples (16.6667 %)
	low-severe	 1 (16.6667 %)
 Variance from outliers : 13.8889 % Variance is moderately inflated by outliers
nil

If the collection supports reduction it is I think always faster than iteration. At worst it is equal.

Are you running the app in a REPL session or regularly? If it is the former you need to eval def-db-fns for that file. If it is the latter I don’t think that’s a good idea but you can add a file watcher and eval the same macro.

I run it like ‘lein run’, so that’s regular right? Maybe I should try running it as a REPL session?

If you haven’t watched @U04V70XH6 presentation I can’t recommend it enough. Like you, I did lein run for years without realizing others weren’t doing that! https://youtu.be/gIoadGfm5T8

Thanks a lot, checking it out shortly! 🙏

@U9FEN7GF6 https://clojure.org/guides/repl/introduction#:~:text=A%20Clojure%20REPL%20(standing%20for,code%20expression%20at%20a%20time.

From the reference: > Keywords are like symbols, except: They can and must begin with a colon > Symbols begin with a non-numeric character and can contain alphanumeric characters and *, +, !, -, _, ', ?, <, > and = (other characters may be allowed eventually).

A rule of thumb - don't keywordize string keys. :) Unless maybe if you know that they contain only what keywords explicitly allow.

also, what the reader validates things more strictly than you can create with the keyword function.

(keyword "this is a horrifically, terrible, no() good idea[] at all")
:this is a horrifically, terrible, no() good idea[] at all
profile=> (type *1)
clojure.lang.Keyword

Hm. Guess I missed that in the reference. Thanks for pointing it out 🙂