We'll see -- it's a good question. That doesn't necessarily follow, though: at best, Querki's never likely to have as much power as Scala itself, and that certainly is debuggable.

I suspect that this will wind up as yet another argument why Querki will gradually wind up more and more strongly typed. That hadn't been the original intention -- in certain ways, Querki is intentionally *un*typed -- but I'm gradually coming to realize that the data pipeline itself can and probably should be very strongly typed. That will make it easier to write in (specifically, it'll make it easier for the system to do hand-holding, and suggest sensible options); it's also likely to make debugging much easier.

But like I said, we'll see. I'm deliberately allowing myself to be radical here, and I suspect it *will* be a long and serious project to get to the point where folks find it easy to debug Querki code. There's going to be a lot of experimentation, and some hard lessons.

OTOH, if you're concerned about Querki *itself* being difficult to debug -- that's not quite the least of my concerns, but it's not high up there. That's the beauty of Scala's extremely strict type system: most bugs don't even *compile*. Which doesn't mean there are no bugs, but the number is actually surprisingly low given the size and complexity of the code. (And the *vast* majority of the bugs are in the client-side Javascript, not the server.) There's a lot of test automation that still needs to happen, but I believe we'll be able to achieve reasonable robustness without *crazy* effort...