Personally, I prefer performance over binary size. My usage is 100% local dev though, so I'm not sure how much this impacts other use-cases.

To start with, support for debugging sounds important to me, w.r.t. babashka. But then... sorry if these are stupid questions: 1. How large vectors need to be processed for the algorithmic complexity to have a visible impact? Visible -> because this is for pretty-printing, so it is only a case of being interactive with the programmer, or? Is it... vectors in the mega-byte range, for example? 2. Do people pretty-print mega-byte sized data structures a lot?

@U0359E1F02H 1) Yes, this would probably only used during dev time by programmers

2) I don't think so

I'm not exactly sure why fipp uses rrb vector

I'm just trying to see if I'm missing something, since I'm leaning towards saving space definitely, if it has negligible impact (=space for other bb features to come)

Not that you should put an unnecessary amount of time into this. But I bet you if anyone could whip up a benchmark in almost no time 🙂 Or maybe some other wizards will take the challenge and suggest a bit of code that generates large data structures to measure?

The surface area of fipp with rrb vector is here: https://github.com/brandonbloom/fipp/blob/master/src/fipp/deque.cljc

> I'm not exactly sure why fipp uses rrb vector "Because they can?" 🙂

If more libraries that would be useful to run in bb would rely on rrb vector, the argument to "not fake" it would become stronger

as of now, it's "not faked" on master

True. And switching over to rrb is a change that you can still make in the future then? Or, if someone complains about performance. My opinion only, and I'm a very small voice in this, but I'd "save" on the binary size whenever you can, sort of like saving for the future.

I tend to agree with that. If performance becomes a concern, we can switch

> I'm not exactly sure why fipp uses rrb vector I think it's because fipp starts with f for fast, and Brandon Bloom, the author, is a language and data-structures geek. I've always been tempted to use fipp because of that. For the current question, I also think it's safe to start with a simulation (using into).

Alrighty, pushed. Let's see in #babashka-circleci-builds if the 350-ish kbs go away

Yep, that worked. 350kb on macos and even 1.5mb or so on linux

“Programs must be written for people to read and debug, and only incidentally for machines to execute.” updated with respect to H. Abelson Don't care about speed or size as long as I have hashp and other debug tools.

@U01BDT7622X Alright. Let's try without rrb first and we can always improve. Here is the full sequence of what I did to make hashp work in babashka: https://github.com/brandonbloom/fipp/issues/81#issuecomment-1113957919 with babashka from master.

figured it out myself - the examples rely on being in the user namespace

easy once i saw that in the readme

We should update those examples. Where did you see those?

i searched "babashka csv" and found a github link: https://github.com/babashka/babashka/blob/master/test/babashka/scripts/csv.bb and this one https://cljdoc.org/d/borkdude/babashka/0.0.88-2 was where i got the answer that got me past it, although possibly not the best way?

that's a very old version on cljdoc there

yeah, i noticed that - it was #4 on my google search or something though, thus my click