Short symbols ↔ Variable names

[tfiers]

Just a minor comment on UX.

While reading the Lotka-Volterra example, I felt like I wanted a representation of the equations with short symbols, to get a feel for their mathematical 'Gestalt'. I.e. to have a one-glance overview of the form of the functions (and thus their behaviour).

Not to say that I don't like the fully spelled out variable names -- they are very useful.

I'm thinking of a synthesis of the two. Maybe with a global toggle to switch between both representations;
and a hover tooltip on symbols to see their full name (/ description).

Big fan of the ideas in this project, by the way.

[khinsen]

Thanks for your comments and suggestions!

This is in fact a topic on which I am rather undecided myself, so I have been playing with different styles. Mathematical tradition suggests short names, but is that for reasons still valid in the digital age? When you write by hand on paper, you obviously want short names. As you note they are also advantageous for quick reading, once you have internalized their meanings. On the other hand, in software there's an emphasis on meaningful names, for good reasons as well.

Your suggestion of putting a longer name on a hover tooltip sounds very interesting. A bit like a docstring on a symbol.

[khinsen]

I'd then actually want docstrings on everything: on sorts and ops to say what they represent, on rules to explain what they do. Which goes well with another idea I want to try out: group rules into related rule sets, the docstring would then go on that set.

[tfiers]

That sounds great.

Related, "backlinks" (like in Roam etc) on each variable would be useful too.

Then you could jump to definition of a variable, or see all places in the prose where that variable is discussed.
(just like in an IDE or with the recent GitHub code jumper tool)

[khinsen]

All that would be nice indeed, but implementing such features would require way more JavaScript than my competence (and willingness to learn) permit. For now, Leibniz outputs plain HTML+CSS, using just some JavaScript inherited from Scribble. There's also the experimental [branch using Pollen instead of Scribble], the main goal being to integrate the XML definition of Leibniz contexts inside the same HTML document displayed to readers. In that branch, there is no JavaScript at all.

The enormous overhead of adding user interface features in the Web universe is one reason why I started exploring a completely diffferent approach to implementation, using GToolkit and thus the Pharo language in order to have a user interface toolkit that is both powerful and manageable for part-time developers like myself.