by evincarofautumn on 11/9/18, 2:29 PM with 116 comments
This doesn’t need to be just about the language itself, but the whole experience of developing with it, e.g., tooling, error messages, documentation, editor integration, &c.; as simple as “Avoid making me press Shift” or as involved as specific problems with existing tools and what you wish they did better. I’d also welcome examples of tools that do things particularly well!
So far I’ve had/implemented a few general ideas:
1. Making whitespace-sensitive syntax, like in Python & Haskell, optional syntactic sugar for explicit brackets & separators. It can also be turned off entirely, if e.g. you work with a screenreader and prefer it not need to speak all the indentation.
2. Striking a balance between concision and avoiding excessive punctuation-based syntax. I’ve also tried to make sure that visually similar characters have clearly distinct functions, so it’s less likely to mix them up—or if they are typo’d, at least the compiler should reliably detect this and produce a useful diagnostic.
3. Working on integration with existing editors (through the Language Server Protocol, an Emacs mode, &c.), so ideally you can continue to use the editor you’re comfortable with that supports your setup.
4. Allowing the interactive mode (sort of a souped-up REPL) to be customised to support screenreaders, colour settings for colourblind people, adapting gracefully to large fonts, and so on.
I’m certain there are plenty of things I’m still missing, though! So I’d really appreciate any help, personal stories, or links to the work of similar initiatives (like Accessible Scala) that you can offer. Thank you!
by informatimago on 11/9/18, 3:37 PM
- 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
by Teknoman117 on 11/9/18, 3:55 PM
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.
by bdarnell on 11/9/18, 3:27 PM
https://tvraman.github.io/emacspeak/manual/Emacspeak-And-Sof...
by blakewatson on 11/9/18, 4:14 PM
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%.
by gostsamo on 11/9/18, 6:35 PM
by newen on 11/9/18, 3:20 PM
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.
by projectramo on 11/9/18, 3:35 PM
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.
by Sir_Cmpwn on 11/9/18, 8:22 PM
To this end I've been making plugins for Vim and WeeChat, and a script for sway:
https://github.com/SirCmpwn/vimspeak
https://git.sr.ht/~sircmpwn/dotfiles/tree/master/.weechat/py...
https://git.sr.ht/~sircmpwn/dotfiles/tree/master/bin/swaytal...
If you or someone you know would find these useful, please reach out so I can learn more about your needs.
by DoreenMichele on 11/9/18, 6:52 PM
https://groups.google.com/forum/#!forum/blind-dev-works
(I am seriously visually impaired, but not blind. I know a little HTML and CSS and I have a part-time position with the spiffy title of Webmaster, but I'm not really a programmer.)
by geocar on 11/9/18, 3:27 PM
I have previously attempted to program blind and reported some of my experiences[2].
by hood_syntax on 11/9/18, 3:29 PM
by TheSwordsman on 11/9/18, 11:24 PM
by AndrewSChapman on 11/9/18, 4:19 PM
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.
by gus_massa on 11/9/18, 2:54 PM
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?
by WalterBright on 11/9/18, 8:59 PM
for (int i; i < 10; ++i)
"for each int i from 0 to 10"
"for left paren int i semicolon i lessthan 10 semicolon
plusplus i right paren)"by traverseda on 11/9/18, 3:05 PM
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.
by dranov on 11/9/18, 3:32 PM
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".
by genemachinery on 11/9/18, 9:35 PM
by dan-robertson on 11/9/18, 7:07 PM
x = some_function(something_else(y), z)
Now compare:
something_else(y)
-> some_function(z)
:> x
by Shalomboy on 11/9/18, 3:59 PM
by spmealin on 11/9/18, 5:12 PM
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.
by Nomentatus on 11/9/18, 10:30 PM
by GuB-42 on 11/9/18, 9:59 PM
Considering that dyslexia is a reading disorder, I suppose that the programming language can be really important.
by AdmiralAsshat on 11/9/18, 3:31 PM
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.
by mygo on 11/9/18, 4:08 PM
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.
by cteague on 11/9/18, 10:38 PM
Obviously, inherent to programming is diving deep into chained function calls and managing all those levels in abstraction in one's mind. However, for someone with a limited working memory for whatever reason--adhd, depression, chronic pain, anxiety, headaches and more--having this minimized as much as possible would be a lifesaver.
by manch23 on 11/10/18, 12:53 AM
I feel like the English like syntax and use of keywords instead of symbols would be very beneficial for people with disabilities.
I guess python is in a similar vein, but ruby doesn’t rely on white space for its blocks, which I think is a real plus.
by ndarilek on 11/9/18, 4:52 PM
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.
by picometer on 11/11/18, 5:20 AM
This was just a fun experiment - I'm not blind or visually impaired - but I imagine that the concept could useful for programmers who depend on screen readers. It could be simplified as well; e.g., adjust the pitch or timbre of the voice depending on the nesting level of code.
by mcphage on 11/9/18, 3:10 PM
by SilasX on 11/9/18, 3:27 PM
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.
by fnordfnordfnord on 11/9/18, 8:36 PM
by KevanM on 11/9/18, 3:24 PM
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.
by eggxbox8 on 11/9/18, 4:11 PM
by jdbdline on 11/9/18, 6:30 PM
by stephenwithav on 11/9/18, 11:55 PM
I can't really think of anything that would greatly enhance my current Linux/tmux/emacs setup.
by _nalply on 11/11/18, 9:28 AM
by reacweb on 11/9/18, 3:33 PM
by miki123211 on 11/9/18, 8:37 PM
3. If you make a GUI framework, use native controls. Screen readers aren't magical pieces of software that do their things using arcane spells, to read anything, they actually need to get the information to read. To do this, they use operating system APIs. When an application uses native controls, it exposes all the needed information through those APIs and a screen reader can get it easily. If an application has it's own GUI toolkit, it's own representation of controls that doesn't correspond to the OS notions of a control and draws on the screen directly, the screen reader doesn't know anything at all. This is the case with i.e. GTK on windows. For a long time, this was also the case with Flash, Java and QT. 4. screen reader users generally prefer words over symbols (controversial, some might disagree). Symbols are nice for sighted users because they take less space on the screen and are faster to read, but for screen reader users they are not. Lua's "if a less than 1 then print quote this is a test quote end" reads much more naturally than go's "if a less than 1 left brace fmt dot print l n left paren quote this is a test quote right paren right brace". There's a reason why blind programmers like lua and ruby. 5. Very hard to do right, but one of the most annoying thing for me is to deal with various messages in the console. If it's a web table, you can do two columns, timestamp and message, and a blind user will know it's a table and be able to navigate only in the second column. If it's console output, you can separate them visually, sighted users will just glance over the timestamps but blind users actually need to hear them before hearing the message. Imagine you need to listen through "two tousant eighteen colon eleven colon zero nine seven colon fourty five colon three comma 7520, /cmd/frontend/main.go:19: server started" before each message instead of just "server started". That's the sad reality for most blind people dealing with logs and messages that contain long paths etc. I don't know if that can even be done right without hiding the info alltogether, as it's not possible for a blind person to navigate a table in the console, but this is something that should be taken into consideration.
by austincheney on 11/9/18, 6:35 PM
A more accessible and portable language is one that eliminates overloading and redundancy. Everything in the syntax and expression is deliberate and its not open to various subjective forms of reasoning.
Eliminate white space as syntax. Beauty is subjective, but it isn't necessarily accessible, and it certainly isn't automatically simple. White space as syntax is common in nearly all languages. Even in Java there is white space to separate keywords. White space elimination allows any manner of visual expression and beautification of the language. It also prevents corruption of the code over the wire due to reformatting of corrupting user-agents and OSes that have different line endings. One form of corruption is when a token is shifted, due to different reasoning of line termination, onto a previous line terminated by a line comment.
Eliminate operator overloading. In JavaScript the plus character could mean addition, or string concatenation, or type coercion, or other weird things. The plus character could be a single character operator or the dreaded ++ which could mean post-increment or pre-increment. In JavaScript the forward slash could mean division or regular expression. For a blind person reading the code as characters or tokens this kind of overloading is unnecessarily confusing bullshit.
Conversely JavaScript has two different syntax forms for assignment. The common form of assigning is using a single equals character. In object literals a colon is used for assignment. This is stupid and looks completely different from the algebra on which equivalent logic is based. Make the colon character the character of all assignment. This leaves the single equals character free for comparisons. If the language imposes a strong/static type system there will be no need for double or triple character comparison operators.
I would invoke a strong/static type system. This allows error detection very early which reduces testing time and jumping between application environments.
I would design the language in such a way that it encourages code in structures. It is easier to follow code when it reads similar to its flow control at execution time. In this regard I would write the syntax such that it encourages containment, nesting, function as organizational models that can be nested, and design everything around primitive data structures.
I am not a fan of OOP programming where the application is easier to write/expand than to debug or read. OOP constructs tend to be convention heavy, keyword heavy, and syntax heavy. Functional/structured languages allow the deliberate organization of its pieces to do much of the heavy lifting as opposed to referenced or logical organizations.
Don't worry about superficial tooling support. Solve the language design problems, the hard problems first. The helpful tooling bits will be easy if you have nailed the hard decisions and produced something with clarity, simplicity, and deliberation.
by caymanjim on 11/9/18, 5:55 PM