@Szabolcs Many thanks for this example, @Szabolcs. We are looking into it too, and hope to have a fix very soon. We are improving Dataset in multiple ways, and WL 12.1 has focused on increased interactivity, Grid-like styling capabilities, storage of data in place, copy-paste, and other FrontEnd-related things. Summary boxes and similar typesetting constructs are important to identify and understand expressions, but they should not make the system much slower, of course.

@CarlLange Thanks @CarlLange.

@b3m2a1 @C.E. you might enjoy this

Stephen will be streaming today at 1:30 CST. It'll be a continuation of last week's stream where they discussed COVID-19 data and models. youtube.com/user/WolframResearch

also: twitch.tv/stephen_wolfram

@user21 haha, that’s hilarious.

Christopher's command of Wolfram Language on the livestream is quite impressive.

@kirma Yeah. I'd never seen someone who is comfortable with Query, haha.

His first instinct was to do this:

{{1, {a, b, c, d, e, f, g}}, {2, {a, b, c, d, e, f, g}}} //
 Query[All, {1, Query[2, 6]}]

Instead of mine, which would be this:

{{1, {a, b, c, d, e, f, g}}, {2, {a, b, c, d, e, f, g}}} //
 Map[{#[[1]], #[[2, 6]]} &]

But I certainly see how once you have a complicated enough query, and you want to modify it, his way seemed more efficient than having a linear chain of operators. Sort of just insert the new thing structurally where it makes sense based on the expression.

But for my own readability right now, it's still easier for me to parse a linear chain of operations than a complicated Query I think.