Experiments in Code Typography (2014)
research.microsoft.com
research.microsoft.com
That said: this project could benefit from working with an actual typographer. Even people who agree with the principles of these ideas will likely revolt at the examples shown and think it's because the ideas are bad.
There is tons of purely optical tuning that could be done to make the snippets look better. The leading needs to be increased if the horizontal spaces are going to be so wide. The parenthesis should be centered around lowercase letters, kerned more loosely, and made thinner at the curves. Many of the operators and special characters could also benefit from a programming-specific take. Typographic detail might also suggest other opportunities: for example, spaces between items in a list might be made wider than those of sub expressions within each item.
In my work I started by laying out the results I wanted in TeX, giving tons of power over small typographical details, and it paid off. Even though some of the ideas were duds, the presentation was aesthetically pleasing enoug that many people were willing to try it.
I was at a conference a few years back and one of my favorite presentations was a guy from O'Riely. Up to that point most of their works were converted from docbook with XSLT to pdf,epub, or html. He had been working on HTMLBook[1] to write books in asciidoc, convert to (x)HTML5 and the conversions were written in CSS and used an antenna house processor.
It was an XML conference, so all things latex was a bit taboo. But in general, we handle a lot of XML in publishing.
One of the first things that many people who get into code typography try to "fix" is using the "real" mathematical symbols for the various operators that programming languages represent in ASCII. Using × instead of `star` (ugh, no way to escape an asterisk in HN's shitty markup format), ÷ instead of /, etc.
This is based on the assumption that the math notation is superior. Maybe because it's older? Maybe because it's used in mathematical papers and texts? Maybe because they assume readers are more familiar with that, or maybe new programmers? Maybe just because of the general cachet of "correctness" that math carries with it[1].
I'm not sure why, but either way, I disagree with this assumption. I do admit that a new programmer has likely seen more × than `star`, but I think that's a small hurdle. Certainly, at this point in my life, I've seen != a hell of a lot more often than I've seen ≠. != is the canonical symbol for "not equals" in my mind.
Sticking with the ASCII representation does have one real thing going for it: it visually represents the way you type it. If I was a brand new programmer coming to a program using Sean's UI, I might be able to read the ≥· a little more easily (though the dot would confuse me), but I wouldn't know how to produce it.
The most compelling case for "looking like math" is when the ASCII representation is clearly imitating something that could be rendered in a more pleasant and smooth manner. Like a plain arrow (->).
> Sticking with the ASCII representation does have one real thing going for it: it visually represents the way you type it.
Which is why we should have easy ways to switch between views of code. There might be views which are hard to translate between, but typography seems to be one of the most low-hanging fruit.
The people that object to making programming look more like math seem to think that the goal is to make programming serve mathematics, but the actual result is that (just as with physics) math ends up in better service to programming.
I think what we're really talking about is making programming notation look more like traditional math notation.
Math is math no matter how you write it.
Anecdotally, it's easier for me to think in terms of operators rather than functions or methods, even though they're all the same thing.
[1] http://plato.stanford.edu/entries/platonism-mathematics/
[2] http://introtologic.info/AboutLogicsite/whitehead%20Good%20N...
Programmers care about syntax, too. But it's not like we've collectively figured it out yet. But I wouldn't be surprised if it turned out that we were further ahead than mathematicians in some ways. :o)
I'm a fan of most of the other math notation programming languages use: parentheses for grouping, infix operators, function call syntax, etc.
I think there is a lot of room to improve the visual display of code, but I don't think much of it is as the token level.
I absolutely agree - the power of mathematics isn't so much that people find it easier to read ∊ for set membership testing, or ⊥ for nil/undefined, it's that one can encode new concepts concisely in new notation. For example: div, grad and curl [1]. What's needed isn't more maths symbols in code, it's more flexible syntax markup.
[1] https://en.wikipedia.org/wiki/Vector_calculus_identities#Ope...
Looking more like math _in itself_ is vapid. Sure, you can make cases for why looking like math is good. But by itself it's vapid.
> Fortunately, we long ago invented and mostly debugged something to make thinking easier: Mathematics. B
Don't conflate mathematical notation with math itself. The great thing about mathematics are the analytical insights, not how those insights are written down.
Is it really the case that we "invented and mostly debugged something to make thinking easier" in the notational sense? Math notation, like most notation, seems as arbitrary as any other invented notation. Was there really some rigour behind it which you can use to claim that it makes "thinking easier"? The question itself of "making thinking easier" through notation is beyond the scope of mathematics. But there are of course interdisciplinary mathematicians.
Lets not even go to the annoying tendency to use single letter variable names.
IMO, this is more of an issue with special symbols being tricky to type. I used to be symbol-phobic like that until I learned how to configure how the Compose-key behaves in my system. Now all the symbols I commonly use (greek letters, funny arrows and some math stuff) are very easy to type. I went ahead and replaced the latex macros in my thesis with their unicode equivalents and things became immensely more readable.
https://en.wikipedia.org/wiki/Compose_key https://github.com/hugomg/xcomposer
As often happens with technological progress, the invention of the typewriter caused a regression in some areas; namely, an appreciation for gorgeous typesetting. Sometimes those kinds of tradeoffs are clear wins, but we know that there exist better kinds of input devices than QWERTY (e.g. chorded keyboards for raw speed or virtual keyboards for maximum flexibility)[1]. So, there’s no reason to strictly discount the value of rich typography, especially since at some point both QWERTY and ASCII will disappear.
Here are some advantages of introducing robust typesetting to programming environments:
• It’s prettier.
• It affords equal readability in both color and monochrome [2].
• While your focus is on the narrow cases such as “!= versus ≠”, the strikethough is generally useful. For instance, a freed/disposed variable could be denoted by striking through its name.
• Typography could be used to reflect code quality, especially if bad code looks bad. For instance, every time the same variable is assigned a value by a programmer, its font size increases by 1.1 ems.
• Using smart quotes would, on average, make denoting string literals easier because we would usually not need to include dumb quotes in the string (admittedly, this has less to do with typesetting, but it is an argument against the tyranny of ASCII/QWERTY).
[1] Even though a physical QWERTY keyboard is faster (for me), I usually prefer typing HN comments using the virtual keyboard of my iOS device, because I have ready access to such things as accented characters, em- and en-dashes, and smart quotes.
[2] Here's an example from an experiment I did some time ago: https://github.com/noblethrasher/typography/blob/master/fs-t..., I would have considered it an unqualified success but for want of italics in Visual Studio.
And the logical way to produce ≥ is to type >=, though of course there is still the hurdle of setting that input mode in your text editor.
Says who? Going from the glyph, I would expect it to be ">" + "_" (underscore). On a typewriter, it would be ">", backspace, "_".
The author might not be aware of it, but Python does actually have this syntax feature, for this exact purpose.
Both should be well known to HN readers.
It isn't free, but it is very well designed and appeals to my sense of aesthetic. Well worth the money.
It's kind of surprising to me that in this day and age of 4k monitors with crazy large dpi that Condensed is still a selling point for code fonts. As cool as a matrix green screen full of inscrutable characters looks in film, we've got modern tools to organize and navigate source files and can actually afford whitespace these days. We no longer have to optimize for volumes of code per screen and most of us are no longer paid by line of code, we can work smarter than that.
HN mobile devs, please take note! I like what you've done thus far to keep the mobile view compact, but it is hard to see the indentation. Sidebars may help, if kept grey and not too intrusive.
[1] https://en.wikipedia.org/wiki/Fortress_%28programming_langua... [2] https://software.intel.com/en-us/articles/first-impressions-...
I would NOT go back.
This, however, seems like a bit much.
*abusing