I also find myself wanting to put detailed expected shape of input data and output data to make it clearer but when trying to put examples in the doc strings I'm getting a lot of push back from the repl. How do you folks deal with that?

also not sure if there is a way to link to the generic exercism page showing the problem statement if that helps with advice.

Why do you find that hard in the repl?

when I try to put stuff like `Example input (\A \A) -> output "2A") it yells at the use of the back slash and quotes.

so then I'm trying to throw in more back slashes as escape thingies but it turns into an unreadable mess

Ah, so more about clojure's string rules than the repl?

Are you using editor integration?

yeah. I would like if anything in the doc string is just ignored but it seems when I evaluate the function in my repl if I've added doc strings like the example above it no longer works.

There's some tickets around for heredoc, but I think they're unlikely to happen. I've never found it so much of a problem though. Characters are an unfortunate edge case.

ok cool. So one thing I've found with reading clojure (including stuff I wrote a week ago) is not understanding what the expected data looks like. Maybe I'm making too big a deal out of that though.

No. I think docs are important.

Don't get me wrong.

I try to write that stuff down.

ok. good. because looking at my functions there can you tell what they even do?

naming was hard. haha

Vaguely. It was a little tough though.

lol, right?! That's how I feel reading everyone's clojure code. Maybe that's how I feel reading any code though, I don't know

When I read library code, not so much. When I read application code, all the time.

I'd prefer application code didn't feel that way though

at least my confidence is growing that I'll be able to hack up a solution to a problem now. I'm just not so sure I'll understand my own solution after a little time has passed. baby steps I guess

You get better at reading the implementation over time to predict.

I keep thinking if I could just see the shape of expected data for input and output I would be in a good place. Haven't figured out the best way to solve that desire. I guess if I find some code in the wild I could try and get it in the repl and play around with it.

Anyways, thank you for the chat! I'm still open on suggestions for how to improve this solution too

The =1 stuff is a bit suspect, you're right :)

yeah, it doesn't sit right with me. The thing is input can be like "AAABCCC" but the output can't be "3A1B3C"

Your code fails if something appears more than 9 times. This would require the length to be 2 digits, and you're only ever considering one. You can use the fact that mapcat treats nils as empty seqs to improve the special case a bit, and also, regex groups to help you separate the count from the element instead of using last and butlast eliminating the bug I mentioned above. Some destructuring later, here's what I ended up with:

(defn encode [txt]
  (->> (partition-by identity txt)
       (mapcat #(let [[n x] ((juxt count first) %)]
                  [(when (> n 1) n) x]))
       (apply str)))

(defn decode [encoded]
  (->> (re-seq #"(\d+)?([a-zA-Z\s])" encoded)
       (mapcat (fn [[_ n x]]
                 (repeat (Long/parseUnsignedLong (or n "1")) x)))
       (apply str)))

The juxt might be going too overboard and into golfing land. You could do:

(defn encode [txt]
  (->> (partition-by identity txt)
       (mapcat #(let [n (count %)
                      x (first %)]
                  [(when (> n 1) n) x]))
       (apply str)))

thanks for the advice! I got some feedback from the exercism mentor too so will be doing some refactoring with both your suggestions in mind.

My solution does work for occurrences more than 9 times though. I remember having to go back and tweak it when getting that failed test. But now it passes. I think that's what the + after my \d regex covers.

You're right, I read that wrong.