apply concat

thanks!

Or, if you need the result to be a vector: (into [] (mapcat identity) data).

wow nice, genius

i like apply concat

(into [] (mapcat identity) data) could just be (into [] cat data)

Yeah, was about to check and say. :) Keep forgetting about cat.

usually, the best answer is to back up one step and use mapcat instead of map

Even though I am a cat person myself.

lol

I usually use (eduction cat data)

I haven't heard of such a thing, but sounds like a useful tool to have.

Yeah. I have had to do this task a couple times, and it's very mechanical, I feel like even if some dark corners can't be resolved (more dynamic imports?) that doing 80% would be a big improvement.

(Like just as a concrete example, I know you can re-`def` vars in a namespace via a REPL, but like conventionally that’s not really how we recommend like anybody…hot reloads anything in a prod, I think? It doesn’t seem like the same level of intention/support as in the Erlang/BEAM VM for example?)

For what it's worth, lein-monolith has a feature that lets you see how all of your subprojects depend on each other. But that's the only instance I can think of diagrams being made for a project. I expect anything else to be a high-level overview of some code and meant for documentation rather than planning.

Anything like that would actually be useful… thanks!

Diagramming relationships between functions is occasionally useful to me - diagramming relationships between stateful systems (especially stuff like databases and scheduled jobs) is pretty much always useful. And of course, anything that involves interaction certainly benefits from diagramming. I really enjoyed the book "Sketching User Experiences" - it gave me insight into how design can be supported by drawing very well at the prototyping stage. Also, IME diagramming software (omnigraffle, etc) is almost never as generative or helpful as pen and (dot grid) paper. It doesn't matter whether the diagram stays up to date; the friction of pen on paper clarifies my thoughts enough for me to move forward.

https://www.elsevier.com/books/sketching-user-experiences-getting-the-design-right-and-the-right-design/buxton/978-0-12-374037-3

I can see how class diagrams representing relationships between Enterprise Java ™️ objects and SetterGetterFactories and the like would get tedious quickly.

This is all awesome affirmation that there’s use in this, at least in some areas… looking at the sketching user experiences book now.

My feeling is that generally diagrams are useful mostly for the people that make them

If you need to make one for an audience, I prefer just creating them by hand rather than dealing with generated output. It’s often better, even if it glosses over some minor detail

They definitely are only intended for me.

Ah, perfect!

Well, actually… that’s not completely true: me but also to share with you all so that you can quickly scan my plan and suggest a better one.

Whatever you like wins :)

Actually, the latter is a bigger reason… but I’m sure as I sketch out my approach I’ll realize a lot.

Diagrams in my experience are often half truths. You could get validation from someone here, but whether it’s a good solution for the business and its goals winds up being a different argument altogether.

Ah, gotcha. Makes sense. My projects are so basic, though, at this point, drawings and review may be of more use. But noted.

Not discouraging them by any stretch!

I know… and you had a really good point… which is that the ‘overall picture’ isn’t really going to be represented as well as other things.

I should also probably consider pseudocode, or bodiless functions… maybe with docstrings.

Nitpicking a bit on whether or not they are in service of your goals. They certainly can be. Just depends.

@U0X9N9ZK5 I have created and used this in the past https://github.com/jpmonettas/clograms

it is for creating diagrams from your source code, not before, so for documenting how a system currently works. It can also be used to statically explore how a codebase works