For me, typed code is more readable than untyped code. As someone who writes & is very used to typed code.
Thinking back to a previous iteration of myself, learning C/C++, Javascript & (old, hint-less) PHP in my early 20s, typed code looked alien. Sure, if I'd applied myself a little to the reading, I guess I could've figured it out pretty easily, but I wasn't inclined to because it appeared impenetrable to me. In a similar way to regex or terse perl (though not as bad obviously).
TL;DR: It needs the advocacy because the readability gains aren't obvious/implicit.
The question is: if there were a weakly typed haskell (same/similar syntax & conventions, no strong typings), which one would a person familiar with haskell find easier to read?
Effective readability has two components: familiarity, & actual readability. We'll automatically find everything unfamiliar to be less readable, but once we're familiar with all options, which is most readable then?
I haven't seen one for readability, ease of maintenance and so on, since those are hard to objectively measure. There is one where they added Typescript and Flow annotations to JavaScript projects to see if it would have detected known bugs. It found about 15% of them.
Explicit vs. implicit typing may be more useful. A statically-typed language with full type inference may look identical to a dynamically-typed language.
The article doesn't really answer the 'how', but just list various things that CAN affect readability. Practically speaking more importantly than can is how much. I suspect that this is a very difficult problem to solve in the general case with varying cultures, contexts, learning styles, etc.
Also.. another thing that improves readability - no ads :)
I need to screenshot a better example. That one barely has actual spaces. I mean, when there's more code, it's not confusing (after 1 or 2 minutes :), because the actual space is 3.25 times wider than the left padding of the capital case letters.
I would also suggest increasing the spacing around the comma and [ characters (and probably others that aren't shown in that screenshot). I find that non-monospaced fonts make it hard to see where the cursor is in those situations, because there's so little space for it to fit.
The referenced article on glanceable reading links to a paper[1] with an interesting result. It finds uppercase text is more quickly recognised than lower case text for individual words.
The paper suggests customisable text settings in user interfaces may actually interfere with legibility, although it is not immediately obvious in which scenario this might occur.
> The significant interaction between typeface size and case shows that design factors can influence one another, as in this case the taller capital letters assisted readers in quickly distinguishing stimuli presented at a smaller typeface size. Consider, for example, an interface where the user may enlarge or reduce the text size. The present data suggest that this seemingly minor degree of control could have unintended consequences. Reduced lettering height could lead to interactions with other design decisions, and surprising emergent issues. More generally, the customizability of operational interfaces is called into question, as end-users may choose combination they consider aesthetically pleasing, but are ultimately operationally detrimental.
Since we read code more than we write code, I highly suggest you try out a variable width font in your editor. I've been using a slightly tweaked Avenir for years and I love it. Fixed width fonts were a hack to make displaying code on terminals easier 40 years ago, we've long outgrown any need for them.
I had a similar thought once, and while I still think the idea is correct, I just haven't found any variable width font for which this works for me. Most fonts have very narrow punctuation symbols. That makes sense for the visual flow of natural language text. But in code, symbols need to stand out just as much as letters. Monospace fonts achieve this perfectly, even if mostly by accident.
(BTW this is also the reason why I don't use "code ligatures" -- mashing symbols together is the opposite of what I want to read code clearly.)
The one that bugs my friend the most is that the minus is a totally different width from the plus in most variable width fonts.
Personally I have not found this to be a big problem. Brackets are visible enough and indentation is the main way I see them anyway. I would LOVE to see a serious attempt at a variable width font for coding but already for me the benefits outweigh the drawbacks.
I'm fine with this in theory and have spent plenty of time running variable width fonts in code editors. In practice their non-alphanumeric symbols like brackets and carets aren't designed and set correctly for the significance those characters have in code. In prose they are meant to be clear enough but unobtrusive, with a fair bit of play between the tradeoffs in either direction being acceptable.
It's not an insurmountable problem, probably any skilled typographer could do a great job at it on a given typeface. Probably even just a committed amateur with fontforge could do an acceptable job in a weekend. But I'm neither and I don't know of any "code variant" variable-width fonts yet.
Plus the last few years this problem more or less resolved itself for me. There are a number of incredibly high quality code-specific fonts now, plus there are now fixed-width fonts so tightly designed with this in mind they aren't even obviously fixed-width unless you have a practiced eye for typesetting. You can get very close to the same result without giving up aligned columns, which is one advantage that is still fairly relevant.
I would love to see a serious take on a variable width coding font. I have a friend who made some edits to Avenir for me, making the minus as wide as the plus and making spaces that come at the beginning of a line wider to make space-indentation more obvious. I've never had any problems with brackets and carrots but of course these font choices are some of the most personal of coding decisions.
Seems like "languages" have evolved within a monospace world, or more accurately, as human being design programming languages, few, if any, have done so with proportional fonts in mind, which is likely to make adoption difficult?
One of the images suggests that the presence of ascenders/descenders makes lowercase easier to read at a glance than all-uppercase, due to differing word shapes. But the text doesn't seem to elaborate further; does anyone know of any studies that support this? I'd be curious to see how the potential for "distinct shapes" affects readability across scripts, considering not just English but also Arabic, Davanagari, East Asian ideograms, etc.
A personal data point: lowercase Cyrillic is not more pleasant/expedient to read than uppercase. Lowercase letters in Cyrillic are mostly squashed down uppercase.
Latin lowercase is much more pleasant in comparison.
I always find these arguments overstated. Obviously, there are ways to make things hard to read based on the type. It is rarely the long pole.
This article is odd, in that every bad example is just purposely bad. Yes, having characters overlap each other will make it harder to read. Also yes, putting too much space between characters will make it harder to read. No, this does not imply that there is a set proper space between characters or words that will help.
> No, this does not imply that there is a set proper space between characters or words that will help.
There isn't one 'right' setting for readability — the best choice is to let the user decide via options. Not all apps/websites have enough text to warrant having dedicated readability options. But those with large amounts of text should have some way of doing this. IIRC the Nook app does a very good job with this, offering even more text options than the Kindle app.
Right, this was what I meant by it not implying there is a correct answer.
And I don't think it isn't something that should be studied. I just find articles like this way overstated. They are using what I would call strawman arguments for most of the "bad" things they show. Or with odd pictures of eyeballs and angles for what appears to be sophistry.
I'm sympathetic to the idea that oO0 all look almost too similar in many type faces. I'm... actually less convinced that is a problem for most places than is often put forward. (Yes, I remember "passwords" on old video games being a nightmare when you didn't realize this was the case. I, oddly, don't remember a single time since then that this has been a problem.)
I regularly get texted passwords for work, and the difference between I and l on my default Android SMS app is one or two vertical pixels difference in height. O and 0 are also pretty similar, but o is clearly different.
I'm curious what sort of passwords you are texted that you are expected to type in? Only "passwords" I get texted on a regular basis are purely numeric, such that this is a non-issue.
I was surprised the diagrammed sentence had a three-way split at the top, instead of noun phrase and predicate phrase (which would have been subdivided into the verb and the preposition phrase). We never diagrammed sentences when I grew up — I only ever did it in linguistics classes in college. Is it normal to have three-way splits in sentence diagramming?
In the tree in which a sentence is decomposed, some of the groupings of the branches are purely conventional, not based on any objective criteria.
Around any verb there are several phrases with distinct roles: agent (subject of transitive verb), patient (direct object), subject of intransitive verb, subject of predicate linked by copula, instrument, beneficiary (indirect object), nominal/adjectival predicate, various kinds of circumstances (manner, place, time, direction, cause, purpose and many others).
Especially in the case of the transitive verbs, where frequently many of these roles are simultaneously present, there are no good reasons for grouping some of the roles together with the verb into a "predicate phrase".
The useful decomposition is into a verb and a list of roles, some of which may be implicit. This is like parsing a procedure invocation in a programming language, into a procedure name and a list of arguments, some of which may be implicit.
There is also little benefit in splitting first a "noun phrase" with one of the three roles that are usually called "subject", but which do not have much in common, except that they are more frequently the topic of a sentence than other roles, and because of that in many languages the verb agrees with them (which is a redundancy that does not add information, even if it may aid in correcting errors).
I think a 3 way split is a good compromise to favor communication over theoretical purity under a linguistic model. Sure, they could show it as a tense phrase that takes an NP and T' as children, with a T and VP child of T'.
But, if you are targeting a general purpose audience, striving for that level of theoretical correctness just hurts readability for no benefit.
HN's fonts are pretty bad on the scale of readability. Yet everybody reads them just fine. I think these font-designers are trying to solve a solved problem.
