{"id":171309,"date":"2014-03-02T22:20:04","date_gmt":"2014-03-02T22:20:04","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/research\/project\/live-programming\/"},"modified":"2017-06-19T12:37:02","modified_gmt":"2017-06-19T19:37:02","slug":"live-programming","status":"publish","type":"msr-project","link":"https:\/\/www.microsoft.com\/en-us\/research\/project\/live-programming\/","title":{"rendered":"Live Programming"},"content":{"rendered":"
\"\"Programming today involves editing code while also running it in our head. To augment this mental simulation, live programming promises for much more fluid feedback between the programmer and a program that is executing while it is being edited.<\/div>\n
\n

A\u00a0PL designer used to be able to design\u00a0some syntax and semantics for their language, implement a compiler, and then call it a day. Today, however, languages are\u00a0supported by\u00a0sophisticated environments that, when designed together with languages, have the potential to significantly improve the programmer’s overall experience.<\/p>\n

One area\u00a0that\u00a0vastly benefits from language\/environment co-design\u00a0is\u00a0code typography<\/em>, which essentially defines the look and feel of code itself. This essay documents what I have done in my current YinYang prototype; I do not claim to be an expert and am simply trying to share my experience and obtain feedback.<\/p>\n

This is the third in a series of essays on advanced programming environments; the first is on usable live programming<\/em>\u00a0and the second is on managed time<\/em>.<\/p>\n<\/div>\n

Blocks<\/h2>\n
\n

A language’s statement blocks syntax has huge implications to how code will be laid out. There are many different styles to consider, but the two primary ones are curly brace<\/em> (C-style) or off-side rule<\/em> (opens in new tab)<\/span><\/a>\u00a0(indented python-style). I had always been a curly brace person, but typographically, code should be indented anyways, and braces serve no real role. Indentation is also easy to bring out via side bars with minimal horizontal spacing consumed; consider:<\/p>\n

There is also “expression only” Lisp-style syntax that lacks blocks; see A Few Examples of Lisp Code Typography<\/em><\/p>\n<\/div>\n

\n

Side bars become progressively darker as the indent level increases (one level indent is barely visible). The side bar of the block that the programmer is in is highlighted.\u00a0The environment auto-indents, preserving or increasing indent based on\u00a0whether the previous line ends in colon; the programmer may increase or decrease indent manually as needed. Unlike Python, short one line blocks can be expressed after the colon as a form of syntactic\u00a0brevity; e.g.<\/p>\n

Taken from\u00a0the current prototype;\u00a0it is amazing (and scary)\u00a0what can be done when\u00a0writing an editor from scratch.<\/p>\n<\/div>\n

Parentheses<\/h2>\n

Although curly braces are not needed to express blocks, their parenthesis cousins are still needed encoding method calls and explicitly specifying precedence. Whereas blocks define vertical chunks, parentheses help define horizontal chunks. For this reason, when not being edited parens have cell-like renderings where commas are rendered\u00a0bar delimiters. Consider:<\/p>\n

The same line of code highlighted is shown\u00a0when selected\u00a0(top) and when not (bottom). When highlighted for editing, parentheses and commas are rendered as this is what the programmer would actually type or delete. However, when the line is not selected, an easier to read table-like rendering is used with a\u00a0background that slightly darkens as the nesting depth increases.<\/p>\n

What happens when parentheses are nested too deep? At 2.5% background, the cell goes black at about 40 nesting levels.<\/p>\n

Operators<\/h2>\n

Unicode operators have been around for a while yet we do not use them much because they are hard to type. Rather than have programmers write directly in Unicode, YinYang supports Unicode renderings for plain-old ascii operators.\u00a0Consider the ascii token “>=” that is rendered as “\u2265\u2219”. Notice the little dot at the end: because the we actually write “>=”, the rendering has to have two characters to permit editing; deleting the dot is equivalent to deleting the ‘=’ character, causing the token to render as “>”. Unicode rendering occurs as the programmer writes ascii; consider:<\/p>\n

\n

var m = navigator.appName.toLowerCase().indexOf(“internet explorer”) == -1;
\nvar n = navigator.userAgent.toLowerCase().indexOf(“trident”) == -1;
\nvar nm = m && n;
\nif (nm)
\n{
\nvar img1 = new Image();
\nimg1.src = ‘https:\/\/www.microsoft.com\/en-us\/research\/project\/live-programming\/tp3.gif’;
\n}<\/p>\n

The user firsts declares a new b<\/strong> variable using the $<\/strong> symbol, which is rendered as \u00a7<\/strong>. The users then writes a ><\/strong> expression, appending\u00a0=<\/strong> to form \u2265\u2219<\/strong>, and then prepending ! to form \u2219\u2271\u2219<\/strong>. The digits 10<\/strong> are then appended to b<\/strong>, creating the rendering b10<\/sub><\/strong>; YinYang will always render trailing digits in an identifier as subscripts. Finally, the user deletes the first and last dot of \u2219\u2271\u2219 <\/strong>to go back to ><\/strong>.<\/p>\n<\/div>\n

\n

Renderings are provided by visual and intent composition. As examples of the former, => is rendered as \u21d2\u2219 and +++ rendered as \u2219\u29fb\u2219 based purely based on visual composition, while ! is rendered to and intended Boolean negation\u00a0\u00ac, but can also be added to many operators to derive \u226f\u2219 (!>), \u2219\u2271\u2219 (!>=), \u2260\u2219 (!=), \u21cf\u2219 (!=>), and so on. Note that the \u2219 is only rendered on selected lines and is otherwise hidden.<\/p>\n

Operators are rendered bold with a different color to prevent them from being confused with identifiers, which is especially important for multiplication (typed as * but rendered as \u00d7); consider:<\/p>\n<\/div>\n

\n

Even though x and \u00d7 look very similar, the \u00d7 operator stands out.<\/p>\n<\/div>\n

\n

Presentation<\/h2>\n

Putting it all together, we get\u00a0a\u00a0presentation\u00a0that is decent:<\/p>\n<\/div>\n

This code defines a Ball object whose position p and gravity g is parameterized by an enclosing mk method. Note that within the ball object, a method is defined using the Greek \u0394, which is written as “D_”. The code also contains some multi-part identifiers; underscores are used rather than rely on Camel case, but they are rendered as gray square dots (‘\u25aa’) within the code for better readability.<\/div>\n
\n

Note also that extra spaces are added to the code to enforce alignment. Although a proportional font (Segoe UI) is used, spaces are of variable width so that they\u00a0always end on a global alignment point.\u00a0This allows programmers to align their code when they want to at the cost of variable width spaces\u00a0that do not start from a globally aligned grid point.<\/p>\n

Here is the code for the Ball trait:<\/p>\n<\/div>\n

From these images, note the use of color in YinYang: keywords, dots, colons, and dollars\u00a0are colored bluish and are also bolder so they standout as landmarks. Constants are colored greenish while traits and methods are bolded as defined. We use color sparingly to prevent it from overwhelming the programmer, but we also have something better to use our color budget on.<\/p>\n

For an alternative take on color usage, see Lamdu<\/em><\/p>\n

Metatext<\/h2>\n

Metatext<\/em> is automatically supplementary text that augments the source text with commentary about\u00a0the program they are writing. In most programming environments, metatext is limited to error markers. YinYang, however, includes metatext directly in the programming environment to indicate syntax, type, and run-time errors as well as probe results; consider:<\/p>\n

Metatext was coined in Design Principles for the Enhanced Presentation\u00a0 of Computer Program Source Text<\/em>, which is also a good\u00a0early source on this topic.<\/p>\n

\n

var m = navigator.appName.toLowerCase().indexOf(“internet explorer”) == -1;
\nvar n = navigator.userAgent.toLowerCase().indexOf(“trident”) == -1;
\nvar nm = m && n;
\nif (nm)
\n{
\nvar img1 = new Image();
\nimg1.src = ‘https:\/\/www.microsoft.com\/en-us\/research\/project\/live-programming\/tp6.gif’;
\n}<\/p>\n

In this example, the programmer first defines “x”, as they type they\u00a0get various syntax and type errors in red; the programmer can easily ignore these and get a satisfying “nothingness” when they have completed the definition. After “x” is defined, they get a new error in orange: bar returns zero, so the division fails! Once they leave the line, the metatext disappears while the affected token remains underlined (only metatext for the selected line is shown). The programmer changes bar’s definition to eliminate the run-time error.<\/p>\n<\/div>\n

\n

The programmer then defines “y” in much the same way. Once defined, the programmer can “probe” the value of expressions by prefixing them with an “@” symbol; this metatext then appears in purple. As definitions are changed in the program, “@” probing metatext changes in real time.<\/p>\n

See the usable live programming <\/em>essay for more information on probing.<\/p>\n<\/div>\n

\n

Future Work<\/h2>\n

YinYang’s design is a work in progress. Not all of the decisions made will stand the test of time, and there are still many features to add. For one thing, YinYang only supports line breaks between block statements. Also, I have decided to heavily use proportional fonts in YinYang, but have no answer yet to the alignment problems that these bring; something like elastic tab stops are needed.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Programming today involves editing code while also running it in our head. To augment this mental simulation, live programming promises for much more fluid feedback between the programmer and a program that is executing while it is being edited. A\u00a0PL designer used to be able to design\u00a0some syntax and semantics for their language, implement a […]<\/p>\n","protected":false},"featured_media":0,"template":"","meta":{"msr-url-field":"","msr-podcast-episode":"","msrModifiedDate":"","msrModifiedDateEnabled":false,"ep_exclude_from_search":false,"footnotes":""},"research-area":[13560],"msr-locale":[268875],"msr-impact-theme":[],"msr-pillar":[],"class_list":["post-171309","msr-project","type-msr-project","status-publish","hentry","msr-research-area-programming-languages-software-engineering","msr-locale-en_us","msr-archive-status-active"],"msr_project_start":"2014-03-02","related-publications":[167041,164073,164503,164537,165574,166337],"related-downloads":[],"related-videos":[],"related-groups":[],"related-events":[],"related-opportunities":[],"related-posts":[],"related-articles":[],"tab-content":[],"slides":[],"related-researchers":[],"msr_research_lab":[199560],"msr_impact_theme":[],"_links":{"self":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-project\/171309"}],"collection":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-project"}],"about":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/types\/msr-project"}],"version-history":[{"count":0,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-project\/171309\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/media?parent=171309"}],"wp:term":[{"taxonomy":"msr-research-area","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/research-area?post=171309"},{"taxonomy":"msr-locale","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-locale?post=171309"},{"taxonomy":"msr-impact-theme","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-impact-theme?post=171309"},{"taxonomy":"msr-pillar","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-pillar?post=171309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}