Comment by munificent | Hacker News Reader

Comment by munificent | Hacker News Reader

Parent Full thread

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.

[1]: https://xkcd.com/435/

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" is not so vapid.

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.

[1] https://en.wikipedia.org/wiki/Vector_calculus_identities#Ope...

> making programming look more like math

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.

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.

[1] http://plato.stanford.edu/entries/platonism-mathematics/

[2] http://introtologic.info/AboutLogicsite/whitehead%20Good%20N...

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.

[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.

> 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.

https://en.wikipedia.org/wiki/Compose_key https://github.com/hugomg/xcomposer

×÷ aren't really common mathematical notation. Julia does multiplication the proper way, e.g. 4a for 4 * a.

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.

> the logical way to produce ≥ is to type >=

Says who? Going from the glyph, I would expect it to be ">" + "_" (underscore). On a typewriter, it would be ">", backspace, "_".

Reply on news.ycombinator.com