## Typographic Programming Languages

Its been more than a year since we've looked at code typography last. Josh is running a series on Typography in programming languages:

## Comment viewing options

### Don't like

Wow, to be honest, this looks horrible. Take the second post: Far too many different font styles intermixed, disharmoniously. Some of them competing for which is shouting loudest at you, and the one winning by far is for one of the least important aspect (library function names). And using small caps for something where case is actually relevant is an obviously bad idea. From my point of view, this is the opposite of good typography -- which is supposed to be subtle, almost unnoticeable at first, improving readability, not harming it.

And do not get me started on colours. The syntax highlighting that some people use in their editors already makes me cringe. It is Las Vegas, not Legibility. The suggestions in the first post make it even worse, adding background colour and visually heavy boxes that completely destroy the reading flow. Like fonts, colours have to be used cautiously, not inflationary, if they are supposed to be an improvement. Otherwise, it's more like this.

(Btw, the sample program in the second post is broken: x.apply(console.log) won't work on half of the browsers.)

### Vim syntax highlighting

I find the colour highlighting used Vim works for me, to the degree that when I am using a system that does not have it, I definitely miss it. Looking at the first example I find the boxes and background colour changes too much. The second example just looks a mess, in general too many fonts just make a document unreadable.

I find the use of bold acceptable, and maybe italic. I used to find the default black and white output of a2ps on C/C++ code acceptable.

So i find the sweet-spot is restrained use of colours and styles for keywords, literals, and meta-syntax (includes / comments etc).

### My personal experience of

My personal experience of syntax highlighting is that I appreciate when it makes obvious some parsing tasks that I would have to do myself otherwise:

- lexing string literals and comments (I find that having comments in a different font, eg. italic, helps making them easy to abstract away)
- recognizing keywords as opposed to identifiers (bold, or a different color, is fine for keywords)

I think the question should not be "what do we want to highlight?" but rather "how does it help to have this highlighted?". Your conclusions are otherwise essentially the same as mine.

### Keywords

I think keywords, where they are recognised as tokens, and are therefore not permitted to occur elsewhere in the syntax make sense to me. For example:

let let = let in let


Although it is possible to make some sense of this with backtracking parsers, usual way to avoid ambiguity is to treat 'let' as a reserved word that always introduces a let binding, and is never a variable name. In such cases the highlighting helps distinguish the special syntactic behaviour.

The same thoughts apply to comments, literals, and meta-syntax.

IE, for me colour coding makes sense in terms of the syntactic category a token belongs to, hence an expression would all be the same, no need to pick out functions, variables or operators.

It helps to have this highlighted because the syntactic-categorys behave differently, keywords take parsing preference over other interpretations, as do comments. Its very helpful to have all code between begin-block and end-blocks marked.

### using small caps for

using small caps for something where case is actually relevant is an obviously bad idea

I think the idea was to create a new language with these properties. This isn't 'syntax highlighting'. This is 'typography as syntax'. JavaScript just provided an initial example.

Whether we consider this good/bad typography is a separate issue. I also found it pretty ugly. But I did like the small caps idea.

### Fair point

OK, fair point. That would make more sense.

### I would not buy a car from

I would not buy a car from Ling, though I heard he was very successful.

### Correction

She was very successful. ;)

### Semantic Highlighting

I prefer syntactic highlighting to nothing, but what I'd really like to see is semantically driven highlighting - e.g. use of colors based on the types of words or their associations. I'd also like to see a user-guided model, where we can highlight based on what we need at the moment, or which module/aspect we're working on.

### word, +1, etc.

yes, i have day-dreamed of a way for the ide to gently color things that interact. so things that are related statically, and then eventually also even things that are run-time related. there's all sorts of things that could be investigated. and if we gather run time stuff we can do things like colorize based on performance or security or resources or whatever else. seems like there's more we could do than we have already done.

### Coloring for optimisations

Harlequin Dylan which became Functional Developer and is now Open Dylan had syntax coloring in the editor for the optimisation the compiler was performing on method dispatch.

You could see whether methods had been inlined, statically determined or were virtual dispatched by the color. It was pretty nifty.

### We had this in the Scala

We had this in the Scala IDE, and to be honest...it was quite ugly. Not only ugly, but it wasn't very useful as a guide for the reader.

In truth, color is a scarce resource: if you overuse it, it becomes useless and annoying. Instead, dramatic color-change should be used sparingly as a highlight; slight color changes are alright (e.g. colors that are very close to each other to be recognizably different but easily ignored).

I've been very conservative about color usage in YinYang. And having most of the code be a shade of black is actually useful: highlight keywords and constants in a different color, but reserve most of the dramatic color budget for meta text.

### color doesn't have to be overused

"What we need is subtlety... and lots of it!"

Just because one might use colors (as in, different hues) doesn't mean they have to be a rainbow or anything un-subtle. There's an art in such things (maybe even a science or two). So don't throw the baby out with the bathwater, please.

And, for Pete's sake, if you trust a bunch of programmers (other than me, the exception to prove the rule) to pick the color scheme then duh it will have high probability of sucking. It is like expecting any kind of Linux desktop to ever not majorly suck, etc.

### So you fix the use of color

So you fix the use of color as part of your language design.

### modal highlighting; be careful of what's always on

People in this thread seem to have so many ideas for ways that color could be used to show various aspects of their code. As much as, for example, highlighting poorly-performing code might be useful, it's tricky to determine which visualizations are so important that they are always on by default. Tom Lieber did some nice work on always-on programming visualizations, and he did the hard work of finding some that are especially useful if they're present 100% of the time (not through highlighting, IIRC).

Color seems especially situated to be used modally. DSLRs have image review modes that do things like blinking highlight clipping, and the new Lytro model hightlights near and far depths with blue and orange.

Font size might be somewhat useful. I think Adobe's previous experimentation focused on this for generating quick module overviews.

Font styles, weights, and capitalization seem pretty silly to me as a comprehension aid. I can mostly just distinguish between serif, san-serif, and block, but mixing them in a line of code looks messy and ugly, especially when the differences are so dramatic like they are in Josh's examples.