How type influences readability
fonts.google.com
fonts.google.com
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 upgraded my keyboard from Cherry Red to Blue, so my Haskell is now strongly typed.
Self-awareness on familiarity is important for any developer to have before declaring code as readable or unreadable :)
Also.. another thing that improves readability - no ads :)
Related: Here's a programming font (non-monospaced) that adds extra padding to the left of the capital letters for faster reading of camelCase.
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.
(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.)
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.
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.
Latin lowercase is much more pleasant in comparison.
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.
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.
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 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.
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).