no it is no longer maintained

any chance theres a semi maintained fork somewhere?

What was it based on? Atom?

there was one guy doing a project trying to get it back to life when I checked a year ago and he has done some work but I don't know how far he got, AFAIK most of the clojure community uses emacs, cursive, calva on vscode in that order. I don't think it was based on atom: https://github.com/LightTable/LightTable/blob/develop/project.clj

what I did instead is to break down card actions into individual reusable effects which are sequenced into a game state reducer that also generates the effect sequence into the game state map

Interesting. What else can you tell me about this project?

It’s dawned on me that I should use some flavor of Datalog for this project. I’m going to rewrite the underlying state to use a Datalog DB and then revisit the event / action model. So much of this game revolves around querying the state of the game for very specific cards (or a set of very specific cards). So my model of actions will likely involve support for arbitrary datalog queries against the game’s state.

It sounds like you want a rules engine. Zach Oakes, the creator of the odoyle-rules library, has a demo of creating a Diablo-like hack & slash game using it and modifying the rules on the fly to alter game behavior: https://m.youtube.com/watch?v=XONRaJJAhpA https://github.com/oakes/odoyle-rules

Oh, I remember watching that when it first came out. I’ll review it again. Thank you!

mine is a digital TCG with spells and what not.

I thought of using a database for the game but just opted to use a simple map for the game state first. I also store a random seed with the game state so random events are reproducible, very useful for debugging, but needs native Java Random functions

It seems to me that people in general avoid nested destructuring because oftentimes it's more confusing than helpful.

It sounds like a bad idea to me. Can you give an example where it would be helpful?

I think it's better to just use a let

Admittedly it's been only a couple of times that I thought that something like this might be useful but an example would be

(defn get-handler
  [{:keys [header]
    :let [{:keys [content-type]} header]
    :as request}]
  ; Do something with request or header or content-type
  ...)

In let it's not really a problem since kind of "already have it" Mostly in function definitions. Would also kind of help in documentation on describing the shape of the input.

In the above example I know from the function's signature (it might be presented to you as a caller from your text editor/IDE), that the shape of the input would be something like

{:header {:content-type "something goes here"}}

I think spec is the answer to that and may become more integrated with defn in the future

@U064X3EF3 I think I agree. On a side note, I haven't been following any recent Cognitect developments. There were rumours of spec2 going around? Today I prefer using something like malli because of it's edn/data nature, but I'd like to have something more ubiquitous. What's in the pipeline for spec?

for this specific case you can already do this @U0105D1EL4B

(fn [{{:keys [content-type] :as header} :header
      :as request}]
  ...)

The only impediment is that you can’t “nest” structures if you try to pull part of the path out with :keys. All parts of the path must be explicitly pulled out. So if you have a structure of {:a 1 :b 2 :c {:d 3}} then you can get to :a, :b and :c with :keys but if you want to get to :d then you have to pull :c out separately and explicitly:

(let [{:keys [a b c] {:keys [d]} :c} {:a 1 :b 2 :c {:d 3}}]
  [a b c d])

[1 2 {:d 3} 3]

The above pulls out and binds c before it pulls it out to destructure for d. @U5NCUG8NR’s approach should only pull it out a single time, and then destructure the value bound the c

(more explicitly, Joshua’s method calls get on the map once, and mine calls it twice)

It's called in contexts where the transducer context doesn't provide an init value to the reducing function, but one is required.

e.g. if you manually apply a transducer to a reducing function before passing to clojure.core.reducers/reduce, you expect to see the 0-arity be called.

there are some great blogs on this, if you google "these aren't the transducers you're looking for". There's also some nice footguns/inconsistencies between (reduce) and (transduce) I think

can you link the article you're referring to? I can find none by that name.

http://clj-me.cgrand.net/2014/10/08/these-arent-the-reducing-functions-you-are-looking-for/

thank you 🙏