Ask HN: How should a programming language accommodate disabled programmers?

> Making whitespace-sensitive syntax, like in Python & Haskell, optional syntactic sugar for explicit brackets & separators.

Interesting question. A few years ago, I worked with a blind mathematician. I was an undergraduate T.A. and he was the main T.A. of the course. He used the screen reader a lot. In particular, he has the list of exercise in LaTeX. We read aloud the grades of the students and he wrote them in the Excel form.

I don't remember him using a programming language (excluding LaTeX). The indentation looks like a difficult problem, even if the language has explicit brackets. Does the screen reader say "Tab Tab print ten semicolon"? Does it ignore the indentation? Spaces vs tabs? ...

Do you have some group of blind programmers that you can ask about their current setup?

  def method_here(value): # Indentation level 0
    x = 10 # Level 1
    y = 5  # Level 1
    if x == value # Level 1
      print 'x!' # Level 2
    elif y == value # Level 1
      print 'y!' # Level 2

Have you looked into projectional-editing? The basic idea is that your code is stored not as text, but as data. The data is then projected into a textual format for editing.

That seems like the best way to support disabled programmers, as it gives them the flexibility to make whatever syntax works for them, as long as your core AST is simple enough.

I'll be honest, I don't have any answers for you—but this is a really interesting question, and I'm looking forward to reading what other HN readers suggest.

Blind people already do programming. I know a blind guy who can code really fast, much faster than my colleagues, no idea how though.

Shouldn't you be researching how they code now and then work from there? I actually feel like current way of coding using text works very well for blind people.

I do rough accessibility testing with JAWS on my company website, before we get people in to give it a thorough going over.

I would suggest you try it yourself, and download JAWS and write out some simple Hello World and figure out the challenges you face and then get in touch with disabled programmers and advocates.

T.V. Raman (author of Emacspeak) has said that "S-Expressions are a major win" for visually-impaired users because they give you a good way to navigate the code structurally ("go to beginning of expression" is more accessible than "go up one line").

https://tvraman.github.io/emacspeak/manual/Emacspeak-And-Sof...

Moore indicated one of the motivating factors in choosing colour was to accommodate his failing eyesight[1]

I have previously attempted to program blind and reported some of my experiences[2].

[1]: https://en.wikipedia.org/wiki/ColorForth

[2]: https://news.ycombinator.com/item?id=9284567

>Making whitespace-sensitive syntax, like in Python & Haskell, optional syntactic sugar for explicit brackets & separators.

That shouldn't matter with an IDE or plugin. If static analysis can identify the blocks -- and it has to! -- the screen reader can just read it as if it had your preferred block notation rather than noting the whitespace.

Just want to note that in Haskell, whitespace syntax _is_ syntactic sugar for brackets etc. I don't recall that being the case for python. Interesting tidbit, some of the big names in the Haskell community have very idiosyncratic coding styles that use the bracket look.

    someFunction =
      do { foo
         ; mx <- bar
         ; y <- case mx of { Just x -> do { baz
                                          ; pure (quux x)
                                          }
                           ; Nothing -> do { fnord
                                           ; blurch
                                           }
                           }
         ; xyzz y
         }

    someFunction = do
      foo
      mx <- bar
      y <- case mx of
        Just x -> do
          baz
          pure (quux x)
        Nothing -> do
          fnord
          blurch
      xyzz y

    list :: [Text]
    list =
      [ "this"
      , "that"
      , "the other thing"
      ]

    data Numbers = Numbers
      { numI :: Int
      , numF :: Double
      , numS :: Text
      }

    record = Numbers
      { numI = 1
      , numF = 1.0
      , numS = "one"
      }

Slightly off-topic: how do blind programmers read code? Does the screen reader recite it aloud and just say "int main left-paren void right-paren open-brace int i equals zero...", or does it use some other kind of auditory vocabulary to make it more meaningful to the listener?

I've been thinking about this alot lately because I've been wondering how I could get better at programming while driving on my daily commute.

> I’d really appreciate [...] links to the work of similar initiatives

Take a look at Quorum, a "programming language which is designed to be accessible to individuals with disabilities and is widely used in schools for the blind".

[0] - https://quorumlanguage.com/

[1] - https://www.youtube.com/watch?v=X29BuzGHlBs

Maybe we should train to code without screen: just a keyboard and a headset.

It is interesting that you're getting a lot of suggestions from people that don't claim to have disabilities. Perhaps few of them read hacker news?

It seems that their needs would vary. One thing you could do is try to an interface to test it yourself.

I tried to write and edit a document once using just voice commands. (Let's say someone has carpal tunnel and needs to use voice commands). It was eye opening. I realized how much more frustrating it is to go back and try to delete or fix something than anything else. And if the software didn't recognize an unusual word, it was really hard.

Dragon dictate -- the software I used -- had already learned a lot of this over the years, and there were many commands for changing that, or deleting up to a point. The hard part was moving the cursor to exactly one spot and then talking in a new word.

Anyway, if you tried something like that you would learn a lot.

Imagine if you are blind folded, and have to hear the program and then have to keep it all in memory. Well, that is a lot to keep in your working memory. I would want some kind of canonical "view" to always get to in order to find my way around.

I am glad you are working on this.

Lisp:

- Avoids the use of gratuituous special characters: (a b c)

- use-dashes-in-symbol-names-instead-of-underline-so-its-easier-to-type (you can still use underlines or most any special character, but we like to keep it simple and easy).

- has a simple prefix syntax, that makes it easier to read and understand complex expressions: (loop (print (read (eval))) So no risk of confusing special characters or syntax: the meaning is clearly labelled by the first symbol of each expression!

- is not whitespace-sensitive, how can you see the size of whitespaces when you're blind?

- includes a reader and a pretty printer, so the code can be processed and formated automatically easily for either sighted or blind programmers.

- time-sharing was invented for the lisp REPL by the authors of lisp!

- as a good integration with emacs, which itself has a good integration with various tools such as screen readers, vocal commands, etc, and it's fully customizable.

http://cliki.net/ http://common-lisp.net/ https://en.wikipedia.org/wiki/Common_Lisp

  (loop (print (eval)) (read))

  (loop (print (eval (read))))

  (let ((x (f))) (g x) (g x))
  (let ((x (f)) (g x)) (g x))

  read
  | eval
  | print
  | loop

  read stdin 
  | eval some-environment 
  | print :pretty
  | loop

    read eval print loop

    stdin read
    some_environment eval
    pretty print
    loop

    [1, 2, 3] [4, 5, 6] \(+) zip_with
    do (each_index) -> i, x {
      if (x = 7) {
        "Lucky seven!" say
      } else {
        ["Value at index ", i show, " is ", x show]
          concat say
      }
    }

  (with-open-file (*standard-output* foo)
    (print x))
  (print y)

  (with-open-file (*standard-output* foo)
    (print x)
    (print y))

    my-var & my - var

    (- my var)

One of the software engineers where I work is completely blind. I've never had a chance to interact with him as he's in a remote office unfortunately. He mainly writes in Python, bash, and C.

From what I understand, every project he works on has strict formatting requirements (can't commit until the linter passes, etc.) and his screen reader is programming language aware.

Although, to be honest, I feel that the thing he relies on most is his rather amazing ability to remember most of the exact contents of whatever file he's working on.

Just wanted to chime in to say thank you for your consideration of visually-impaired programmers with suggestion 1.

Sure this problem can be addressed at the language layer, but as you've alluded to, I think it would be more applicable to address this issue at the text-editor / IDE layer or even the build tools.

There's tons of IDEs that make developers better at coding, with things like automatic syntax checking, refactoring, inline debugging, autocomplete, etc. Would it make more sense to develop a developing environment that makes disabled developers better at coding, with whatever features would make their experience better?

It would probably be easier to get a disabled developer to use your editor than to get a disabled developer to use your language. From what I can gather, it's hard enough to get employment as it is for them (maybe they can only work remote, or maybe they can be physically in the office but they're blind). I'm not sure if they have the luxury of being able to choose what language they get to use. But I'm sure their employers would allow them to use the IDE & tooling that works for them so long as they output code that fits the company stack.

Bootstrap is doing some work in this space: https://www.bootstrapworld.org/blog/accessibility/User-Inter...

My struggle is typing. I use an onscreen keyboard (https://www.blakewatson.com/journal/writing-and-coding-with-...), which I have heavily customized for web development.

I would appreciate terseness. For example, I love how in JS, I can do this:

``` var cat = whichCat(); var catPosts = posts.filter(post => post.cat === cat); ```

Whereas in PHP, I have to do this:

``` $cat = whichCat(); $catPosts = array_filter($posts, function($post) use ($cat) { return $post->cat === $cat; }); ```

So much extra typing.

DISCLAIMER: didn’t test this code so chance of typo is 99%.

I've seen some programmers code using voice. This is really handy for people without functiong hands or fingers. They tend to use voice recognition software like Dragon and various plugins.

I'd say from a programming language point of view, having keywords that are short (single word would be ideal) and phonetically distinct is really important.

One python programmer I watched on Youtube made his own vocabulary of strange sounds that he trained his software to recognise and translate to real keywords.

Hey, kudos to you for thinking about this! Background: I'm totally blind, have programmed for nearly 3 decades, kind of do the in and out of half a dozen languages thing these days. Today's favorites are Rust anywhere I can get away with it, Python because it runs in places where I need it (Home Assistant, Mycroft, etc.) and JavaScript because if I hold my nose and don't think too much about the atrocities I'm committing, I can run the same or similar code in various form factors. I'll try to give a few pointers. Note that these are specific to blindness, and specific to me. I don't claim to speak for the disabled population as a whole, as we're kind of a grab bag.

1. Indentation: Pretty much a solved problem at this point. If I were reading Python code line-by-line, my editor might speak something like (not sure if my newlines will make it, but imagine them where they should be): def hello(world): 4 spaces print("Hello, world.") 4 spaces 1 tab 4 spaces print("What was I thinking when I indented this line?")

So I wouldn't worry too much about that. I've never had issues with an indentation-based language, and anyone blind who does likely just needs to change their tooling a bit. This is usually just a checkbox in the screen reader settings, so doesn't even usually require an editor/IDE change.

2. Avoid crazy symbols. Scala gave me some grief with this, with every library author having method names like %^&@^$# because I assume that set of symbols looks like performHttpRequest(...) in some visual way. I exaggerate a bit. Only a bit. Note that operator overloading is fine, at least from an accessibility perspective. It's when people decide that a series of connected punctuation symbols evokes the idea of making an HTTP request or opening an Option that I start to get annoyed.

3. Create good command line tooling. Rust has this nailed. I like how Rust's own installer just uses rustup under the hood, or at least I think it does, and every blog post advertising a new component also includes the rustup incantations to grab it. I assume the editor interfaces are as nice or nearly so. I guess the takeaway is, package your language installation tooling in a library so you can invoke it from the CLI, editor plugins, etc.

4. Put error messages at the bottom of stacktraces rather than the top. Python does this right, and everyone else gets it wrong[1]. Say you're running a compiler from your command line. You get an error, and your cursor lands on the input area, ready for a new command. As a screen reader user, you discover that error by entering your window's review mode and moving up. With JavaScript, Rust, and just about everything else, I have to arrow through the callstack in reverse as I move up the screen to the line containing the error. Python puts this error last, near the input cursor, so all you're doing is arrowing up a couple lines. It's a few seconds per error, but can add up immensely over the course of a day. NPM, infuriatingly, shows the error, followed by disclaimer text that the error isn't in NPM, then barfs up an NPM error just to confuse things. So any JS package I use that uses NPM for its scripting requires arrowing back through 2 stacktraces to find the original error. It's enough to drive me to drink.

I can probably come up with more, but I haven't finished my coffee yet. Perhaps that's a good thing...

1. Right and wrong are of course subjective. This is just one blind dude's opinion, take it for what it's worth.

  σ(x) = 1.0 / (1.0 * exp(-x))

Blind programmer checking-in, here are a few thoughts sparked by the comments that I’ve read…

Disclaimer: these are my thoughts, and should not be generalized to all blind programmers.

First, let’s start with the supporting technologies, mainly screen readers. The most popular screen reader is Jaws for Windows (expensive product), followed by Non Visual Desktop Access (opensource product), distantly followed by VoiceOver (your only choice for Apple products). My main day-to-day driver is NVDA, but I also use Jaws for my job. I do not use a braille display. The IDEs that I use are Visual Studio (C# development) and Visual Studio Code (Python and Javascript development).

Indentation-sensitive languages such as Python really aren’t that difficult to use, once you figure out how to get your screen reader to announce indentation levels. Typically, the screen reader only announces indentation changes when there is a difference from the line that you are coming from. A sample Python function would read as follows as I press the down-arrow to read line-by-line (note that I’m purposely not putting in line breaks, since an audio-based screen reader is inherently serial):

“def foo left paren right paren colon, four spaces number say hello world, print left paren quote hello world quote right paren, zero spaces blank”

Interestingly, I find lisp one of the most difficult languages, since there are so many parentheses, and it’s difficult to keep track of what nesting you are in.

Screen readers are not programming language aware. It’s all text to them.

Using pitch to communicate information is more distracting than anything. Imagine that you were having a conversation with someone, and every few words, their voice completely changed. It makes understanding the meaning of what they are saying more difficult, since your brain is too busy going “hey, something changed!”

Some additional reading that I recommend is “An Exploratory Study of Blind Software Developers”, which can be found at https://ciigar.csc.ncsu.edu/files/bib//Mealin2012-BlindDevel.... That identifies some programming challenges that participants face, as well as some of the areas that blind programmers self-report as excelling in. Full disclosure, I was the primary researcher on that study.

Finally, a mini soapbox rant: something that I see quite often is people doing blindness “simulations” for a short period of time. They then write up their experience, which isn’t a bad thing, but then present their work as “I found this hard, so all blind people must find this hard.” Identifying when a task has a large learning curve is important, but also do keep in mind that people who are blind have significant experience in identifying ways to overcome potential accessibility problems.

Avoid Perl 6 and its horrifying Unicode keywords and operators.

i recently broke my two fingers on my right hand and could only code with the left hand (i am right handed) would have loved intellegint auto complete. And speach to text interface. That would be cool

Another blind developer here with his two pens. I like python because it has no braces. Sometimes the screen reader does not read them or if it does, it takes time to process the info and you still could be confused about the level of nesting. That's why in university I reformated all of my lisp code to follow the indentation rules of python as it helped me keep track. Generally, if the language has no too much strange symbols with important meaning, they are all just text to be read. So, the language is not an issue for me, but the tools to read/write/compile/debug. In that line of thought, if it works on the command line, it is good. Make it readable, make it verbose and avoid fancy syntax so that there is no ambiguity when reading.