[zxoq]

None of the answers were about the questions I had about how to program when you're blind. While the tools they use are interesting. I'm more concerned with how you would browse the code.

Say you wanted to find a method, how do you scroll in a large file to locate it? I guess deft use of find & go to definition helps out here.

How do you locate a line of code in a large function? Do you have to listen for the screen reader to read the contents of an entire screen's worth of code? Or do you rely on previous knowledge of the code and remember where it was?

How do you deal with debugging / fixing errors. I imagine the screen reader trying to parse the output of a template error being a nightmare.

[saqibs]

This is certainly one of the harder aspects of programming blind - particularly tackling a large, unfamiliar, codebase. In the case of a new project, I build up a mental map of how the program works - and memorise the conceptual organisation. With an existing codebase go-to-definition is invaluable, and stepping through in a debugger is just as useful for a blind person as for anyone - you get to see the lines in the order of execution.

This does influence my personal coding style - I always have the entry point at the top, which makes use of meaningful named methods - so it looks like the table of contents of a book. Next come the second level methods - and so forth, until the small auxiliary methods are way at the bottom. This lets me read it top-to-bottom, like a story. Much of this is just good coding practice - but, for example, I find it really frustrating to read code where functions must be defined before they are used - this results in details first, outline last - which makes it hard to build up that mental model (remember, I'm listening to the code line by line - no spinning the mousewheel).

Finally, I'm going to use this comment to express my dislike for underlines (yes, I'm looking at you, Ruby). Every underline adds three syllables to my audio stream - whereas screen readers read cammalCaseCode as separate words.

Feel to ping me @SaqibS on Twitter.

[mmagin]

It seems unfortunate that you can't configure screen readers to say "_" as "under" or some such thing. Also, I think it would be very useful if punctuation was pronounced in a different voice or tone.

[socksy]

That sounds like an issue with the screen reader, surely? CamelCase is arguably somewhat less readable for the seeing than underscore_separated_words, as the underscore can be read practically as a space. Presumably, you'd need a syllable to distinguish between CamelCased and underscore_text, but I don't see why you can't have Python or Ruby style underscores as a convention?

[pavel_lishin]

You would have hated some of the projects I've worked on - spaghetti code, full of variables like hold_value or temp_num and function names like doThing and doThingNow. As a fully sighted person, I mostly had no idea of the overarching organization of the problem. If I were blind and faced with the same project, I'd probably quit and take on something easier, like juggling chainsaws or trying out for major league baseball.

[almost]

Search is a very fast method of navigation when your editors search doesn't suck. Watch an experienced emacs or vim user sometime. I can't say much about other systems but I did once spend a day working with only emacsspeak, the audio interface to emacs. With emacsspeak you use the normal emacs movement commands to move by char, word, sentence paragraph etc and it will read out the unit you've moved in, it kind of let's you scan through a document. Also, experienced users have the speech turned up really fast, if you google it you can probably find a recording...

[zxoq]

I do use vim on a daily basis for all my remote editing needs. Just did not think of how useful all short-hands are for blind people. Thanks for mentioning it.

[jdf]

I had a TA at school who was blind and was excellent at helping CS students debug and fix their class projects. He helped me a number of times and was generally able to find bugs very quickly.

While I don't know the name of the program of he used, my vague recollection is that it read aloud the contents of whatever line he had the cursor on, a good deal faster than a human would speak it (I actually found the text to be read too quickly for me to follow by listening - I needed to read it myself).

I actually found this article about him on the Internet:

http://www.dimenet.com/disnews/archive.php?mode=P&id=276

[derefr]

You can ask anyone who has been programming for 40 years or so this same question. Before we had visual editors [but after we stopped using punch-cards], we had line editors, which worked under fundamentally the same constraints as programming blind has: only a little bit of content at a time, streamed, selected before "display", and requiring a "replay" after any edits to see if the edits were correct. A description of a working day for a grizzled ed(1) veteran would probably have a lot in common with an optimal blind-programming experience.

[richardw]

I suspect coding blind with an audio interface is closer to a word-editor than a line-editor. Imagine your monitor showed only one word on it, or one punctuation mark, and you had to remember everything else!

(Edit: I see below there are Braille editors, which I imagine mirror line editors! Expensive though.)

[lucian1900]

I suspect Braille displays help with those sort of problems.

[cannona]

They certainly do, if you can afford one. They start at $3,500 for a small one (20 characters wide) and swiftly increase in price from there.

[Someone]

Prices have come down considerably. $1300 or so buys a 20 cell display. Also, in many countries, they are subsidized.

And no, they do not really compare to a 20-character LCD display. Reason is that blind user have to rescan the line with their hands whenever something changes, and that takes longer than visually scanning it. Effectively, blind users only 'see' two or three characters simultaneously.