What syntactic features of programming languages ​​are problematic for blind programmers?

While this is a very interesting question, it is a matter of personal preference and preference, so I will answer as if you asked me personally. Note. My working system is Windows, so I will focus on that. Of course I can write cross-platform applications, but I am doing it on a Windows machine.

Indentation, white spaces

All things related to indentation are more or less annoying, especially if the indentation is done with multiple spaces, not tabs (yes, I know the whole "holy war" around it!). Python really taught me how to properly typeset code even in languages ​​that don't require it, but I still get in the way of writing correct Python because of these spaces. Why is that? The answer is simple: my screen reader tells me the number of spaces and the actual nesting rate is four times less. Each such operation (20 spaces, yeah, division by 4, this is the fifth level of nesting) brings me some overhead and forces me to waste my internal "CPU" resources, which I can free up for debugging or other fancy things. It will be a small thing you would say and you will be right,but this is an overhead on every single line of my (or another person's!) code that I have to read or debug! That's quite a lot.
Tabs are much better: 5 tabs, fifth nesting level, nice and good. Braille display will also be a problem here because, as you probably know, a braille display (despite the name) is a single line of text, usually 14 to 40 characters long. Ie Imagine a tiny monitor with one line of text that you swing (i.e. scroll) and nothing else. If 20 characters are spaces, you are left with 20 characters left for the code. A little more if you are reading in Grade 2 Braille, but I don't know if it was appropriate for coding, I mostly use speech for it except in some cases.
Even more painful are some code style standards in which you need to line up your code. For example, this was the case for tests inmoment.js . The expected values ​​and messages should match their position, so that, for example, the starting quote will be in column 55 on each row (it's nice to see, I assume). I couldn't get my pull request accepted for over a week until I finally realized that Iskren (thanks to him for his patience with me!), One of the main developers, was trying to tell me. As you might guess, this would be quite obvious to a sighted person.

End blocks

A related problem: for me personally, it is very graceful when I know that a particular block of code is ending. A correct parenthesis (like in C) or a word end

(like in Ruby) is fine, changing the indentation level (like in Python) is not: there is still some overhead of getting the knowledge that the nesting level has changed dramatically.

Ida

Sorry to admit, but there is practically no user-friendly IDE for the blind. The closest to such an IDE is Microsoft Visual Studio , especially the latest version (gods bless Jenny Lay-Flurrie !), Android Studio also seems to be moving towards accessibility starting with version 2. However, these are not as convenient, sleek and convenient as for the sighted users. So, for example, I use text editors and command line tools to write, compile, and debug my code, as do many blind people around me.

The ballad of snake_case, or Another Holy War

Another thing that is to blame for Python: camelCase is much more convenient to deal with whereas snake_case or even PascalCase.Usually , screen readers separate camelCase words as if they are separated by spaces, so I don't have any pain when reading this package. When you write code, you must include your punctuation, otherwise you will miss something really tiny and "irrelevant" like a quote, semicolon, or parentheses. Then if your punctuation is on and you readmy_very_cool_descriptive_variable_name

, you hear this: "my underline is very underlined cool underline .... underline underline underline !!!" (bad language and swears at censorship). I have even tried replacing the underscores with sounds (yes, my screen reader does this), but the sounds cannot sync well due to the higher speech rate I use. And that's quite a nightmare when it comes to methods and properties like __proto__

(aha, there are two underscores on either side, not one, not three - well I guess that's right!) __repr__

And so on and so forth. Yes, you can say I can replace the word "underline" with something really short like "un" (this is also possible), but some of the overhead is still there, like spaces and code nesting.
PascalCase is much better, but it implies a little more concentration, also as we need to remember to put the first capital letter (oh, I'm too finicky now, let it be PascalCase, but not the ones under ... oh, well, you got it already). That's why I gave up rust, by the way.

Function search

As I told you, IDEs are not the right fit for us, so a text editor is our best friend. and then you need to look for functions and methods and also for classes and code blocks. In some languages ​​(not Python this time) there is no keyword that would trigger the function (see for example C or Java code). Finding functions in these conditions becomes quite painful if, for example, you know that you have a logical error somewhere in the third or fourth function in the file, but you don't remember its name for sure or you are not looking at the user code ... well, you know there are many reasons for this. In this particular context, Python is good, C is not.

Several repeating and similar symbols

This is not a problem in itself, but a circumstance that complicates debugging, such as regular expressions or heavily nested operations such as ((((a + ((b * c) - d) ** e) / f) + g) - h

. this particular example is really synthetic, but you know what I mean: nested ternary operators (which I love, btw!), conditional blocks, etc. And again, regular expressions.

Perfect language

Closest to the ideal language to me with your eyes closed is the language D . The only downside to this is the lack of a word function

, except for anonymous functions. PHP and Javascript are also good, but unfortunately they have many other, blindly unrelated disadvantages.