This is an interesting topic and glad to see someone experimenting. I spent some time on code typography a few years ago and wish I could have spent more time on it. I like a lot of these ideas and hope we will see both structured editing and structure-informed reading be more popular.
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'm geuninely curious, is this how these books are typeset?
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.
I really think it's awesome that Sean is experimenting here and there's lots of good ideas. I disagree with one idea here, which I've also seen advocated in places like the Hasklig font.
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.
You're right that "it's more like math" is a vapid argument by itself. Personally, `star` versus (×) feels like a wash, in particular. Most of the multiplication I've done by hand has been with a dot (•) and not a `star` or (×), anyway.
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.
"Looking more like math" is not so vapid. As Leslie Lamport says, programming is hard because thinking is hard. Fortunately, we long ago invented and mostly debugged something to make thinking easier: Mathematics. But, it turns that not only is mathematics a great tool for thinking, it's arguably the best such tool we've invented so far.
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.
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.
Math notation is all over the damned place. It's like certain areas of math are allergic to standardized notation or minimization of complexity. Parameters to "functions" go after the function name, or in subscripts, superscripts, in positional slots around symbols like Σ.
Lets not even go to the annoying tendency to use single letter variable names.
I certainly agree that notation is important. However, what I'm talking about is tweaks at the smallest scale—just the glyph or glyphs you use to represent a single symbol. I don't think there's that much value deviating from ASCII characters or character-pairs in order to use a more mathy glyph.
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 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.
You are describing the Platonic view mathematics[1]. The nature of math is far from a settled question among philosophers of mathematics, but both Plantonists and Non-Platonists agree that good notation is a crucial factor in our ability to actually do math[2].
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.
Being able to represent the same things in different ways is simply captured by the syntax/semantics dichotomy from disciplines like programming language theory. There is no need to invoke philosophy.
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)
Of course, we use ASCII representations because that is what is convenient vis-à-vis QWERTY. We use QWERTY, because that is what was convenient to learn, because generations of typists were already trained on the typewriter, and because programming was once a menial task, assigned to the kind of people that “only typed” for a living.
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.
> Sticking with the ASCII representation does have one real thing going for it: it visually represents the way you type it.
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.
PragmataPro has ligatures -- it is a great typeface for Haskell and Agda (in general as well, but especially those!) http://www.fsd.it/fonts/pragmatapro.htm
It isn't free, but it is very well designed and appeals to my sense of aesthetic. Well worth the money.
Apologies for the side rant, but wow, that seems way too condensed for my tastes. One of my few complaints with FiraCode is a feel like its too condensed (and compensate by upping it a point over what I tend to keep Consolas at).
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.
Note the use of sidebars to indicate nesting without wasting much horizontal space.
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.
The Fortess programming language [1] was a Fortran successor (with a bit of APL influence) that was meant from the beginning to be seen through a "syntactic stylesheet", so that one would see and operate at the level of mathematical operations and not with the ASCII source code. [2]
Having a pop-up that displays an error "not found" as soon as you start typing—making it look like you made a mistake before you've even finishing doing what you're doing, looks really annoying. You'd constantly see these little red alerts appearing and disappearing below where you type.
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.