Learnable and Expressive Visualization Authoring Through Blended Interfaces

L'Yi et al. 2024

osf.io/preprints/osf/pjcn4

we explore the design space of blending multiple visualization authoring interfaces for supporting authoring tasks in a complementary and flexible manner. To evaluate the effectiveness of blending interfaces, we implemented a proof-of-concept system, Blace, that combines four common visualization authoring interfaces—template-based, shelf configuration, natural language, and code editor—that are tightly linked to one another to help users easily relate unfamiliar interfaces to more familiar ones. Using the system, we conducted a user study with 12 domain experts who regularly visualize genomics data as part of their analysis workflow.

One reason I suspect for the success of regex is the (horrible but) compact notation that makes them suitable for command-line tools such as grep. I would love to have a grep-like tool based on a real (recursive descent) parser with a notation that I can actually remember. Not sure if my requirements are compatible, but... you don't get what you don't ask for!

Note that "command line" isn't really a requirement, but I don't see how such a tool could ever become widespread (and thus widely available, optimized, tested, ...) if it expects some richer environment.

I agree and am inspired to wonder/seek-to-express why I think that this is worth the trouble...

It might be something along the lines:

• Generating code is incredibly useful and will lead to even higher-level languages and notations.
• A "command line" is 1D-think based on 1950's hardware. 2024 hardware is capable of presenting multiple windows. Maybe the concept of "command line" needs to be overhauled to mean a 2D canvas of "windows". For what I describe, you only need 4 windows (source code, grammar, rewrite, read-only output).
• Deep down, I think that the concept of a single program must be liberated from consisting of only a single syntax. To me, a program is a composition of snippets written in many syntaxes (using an IDE that glues them all together to make a whole). A 2D "command line" supports this notion (i.e. a "better" IDE).
• The concept of "compilers" allowed us to crawl out of the trenches of programming in assembler. To me, the concept of "t2t" may let us crawl out of the tranches of using single-syntax general purpose programming languages like Haskell, Python, Javascript, etc.
• There is a huge gaping chasm between the two extremes (1) REGEX, and, (2) CFG-based parsers. Can something fill this gap?

Your second point is something that most people would agree to. To the point that we have dozens (maybe even hundreds) of GUI frameworks that could do the job. But none of them has the market share that would make it suitable for software infrastructure. The other CLI feature that no GUI framework offers is embeddability. You can run a CLI tool from every existing programming environment.

The best answer I know to your point three is Racket. Its main weakness is that implementing a new language is still too much effort, because Racket is targeted at complex rather than simple languages. Also, t2t allows inspection of the output, whereas Racket's compilation chain produces very opaque code representations.

The best intermediate I have found for my own needs is Glamorous Toolkit, which comes with a parser engine (SmaCC) that is fully integrated into the environment (Pharo) and the developer tools. Not t2t, but t2s (text-to-smalltalk) with a decent user interface.