So given that, the main challenge for me was code navigation. I used Visual Studio at the time and it allowed me to jump to method definitions, call references, jump to the start/end of a method etc. So the worst thing was long methods as 1) I had no efficient way of navigating them except to read each line 2) it was hard to keep track of all the things the method did. Breaking up code into smaller pieces with good naming of each method helped speed up my understanding and navigation of the code a lot. It also simplified the mental model in my mind.
Another important trait of easy to read code is the rule of "Big picture" first. I.e. if you have a `main()` method you will find it first in my files, only then followed by sub methods which are called by main(). Same holds for types: first comes the class and then it's followed by any type which might be required for a class attribute. So, when opening a file you immediately get the big picture and depending on the granularity you want to build for your mental model you can continue reading by scrolling down. When the model is good enough, you can skip the rest of the file.
I find this pattern to the contrary of how others design their files. There are people who list all details and sub methods first before telling me only further down the road how these details are put together. This forces me to read a lot of code to build a blown up mental model which might not be necessary for the current task at hand.
Module declarations ( 3 lines)
Parser type declaration ( 1 line )
Implementation details you don't care about (47 lines)
Actual grammar (20 lines)
An alternative would be separate the details from the grammar, but then I would expose those implementation details in an interface, while in fact the rest of the program is only interested in one function that parses everything.
Or, you could write from bottom to top. It's OCaml, so you know the big picture cannot be at the top. Now a case could be made for a language that reads toplevel statements from bottom to top…
- those that prefer high-level overviews first, then drill down to learn details later
- those that want to thoroughly understand each smaller building block first before dealing with bigger picture concerns
For example, I jump right into projects and skim the docs and start hacking stuff together without learning the nuts and bolts, whereas my cofounder likes to read the theory behind the library, then read the source code before even starting to write a single line that uses the library. Both approaches are valid, I've just found most people tend to strongly prefer one approach or the other, and it's helpful to identify what a person's preferred approach is when working with them.
Interesting! I am not visually impaired (not beyond what can be fixed with reading glasses), but I have always worked like that with code.
This restriction applies to whether you are coding, browsing the web (on Stack Overflow), reading XML (shudder).
So the importance of a mental model is critical, because without maintaining context of where you are, you can get lost and spend too much time rediscovering your surroundings. The better your model the faster you can navigate and the less effort required in general.
I wonder if programming like that would force an improvement in my code: kind of like programming through a keyhole, rather than the information overload of 20 documents open simultaneously.
Maybe an Emacs mode with Intellisense, that only showed a line at a time, with syntax highlighting?
I wish a good blind programmer would write a book. I really think there are great gains to be made in programming, when we find ways to optimize the way we build and maintain our mental models of an application. I suspect blind programmers have some good insights to share.
[1] https://engineeringblog.yelp.com/2018/10/a-guide-to-software...
"Ask HN: How should a programming language accommodate disabled programmers?" https://news.ycombinator.com/item?id=18414562 (164 points | 8 days ago | 116 comments)
I bounced it off of my new writing partner[0] and she's interested in collaborating on it. If you're in software and you know a blind person that's working on something difficult, high impact, or otherwise noteworthy please reach out to me. It would be great to chat with them. The more that society appreciates the blind and understands their day-to-day the better it will be accommodated.
[0] She's the former Sr Editor of The Walrus (essentially Canada's The New Yorker), so she's quite good.
Code is plain text, and development environments can be navigated with keyboards. If I were to suggest that a blind developer needed my help, I would have something thrown at me. Luckily, the aim is not so good.
Mozilla is currently hard at work on DeepSpeech for transcription and Text to Speech, which could be huge for accessibility. I hope it continues to improve :P
That helps a lot because with a screen reader “slash star <comment text> star slash” is significantly more listenable to when compared to “slash slash <one line> slash slash <another line> slash slash <third line>…”
Surprisingly this is the only thing I cannot seem to find around my IRC logs… Digging through the logs other things that were called out to make comprehension harder for blind people are:
* Unicode identifiers;
* Boilerplate you cannot easily skip past without losing context (common in e.g. Java);
* Typos (esp. if done on purpose, inconsistently);
All this comes from their preferred interface being a screen reader which, I believe, is true for most blind programmers.
Or "referer" in HTTP because that's what the standard uses. Or "creat" when discussing the UNIX system call or a function with the same purpose on another platform.
To the point of the article, I try really hard to make sure that things like this don't happen, ideally before a typo like that gets merged.
This may be even more important for the rest of the code. Who cares about the parentheses after the `if` keyword? No one, they're just there to delimit the condition. Likewise the curly braces, they just delimit a sub-block. Their absence should not stop the screen reader from spotting the end of the `if` block. They should say "end if" regardless. Same goes for Python.
Structural editors have mostly failed, but maybe some specialised version could be more useful to blind people?
One useful thing seems to be using an auto code formatter and requiring the code is always autoformatted. Manually ensuring indentation is right is very awkward, just running clang-format, or whatever, is simple.
also fun to listen. This is his screenreader: https://soundcloud.com/freecodecamp/zersiaxs-screen-reader