Ask HN: How should a programming language accommodate disabled programmers?
Accessibility is closely tied to portability.  As a minimalist its not about what you can add but rather what you can take away and ensuring everybody understands reading the code with minimal effort everywhere.<p>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.<p>Eliminate white space as syntax.  Beauty is subjective, but it isn&#x27;t necessarily accessible, and it certainly isn&#x27;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.<p>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 <i>++</i> 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.<p>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&#x2F;static type system there will be no need for double or triple character comparison operators.<p>I would invoke a strong&#x2F;static type system.  This allows error detection very early which reduces testing time and jumping between application environments.<p>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.<p>I am not a fan of OOP programming where the application is easier to write&#x2F;expand than to debug or read.  OOP constructs tend to be convention heavy, keyword heavy, and syntax heavy.  Functional&#x2F;structured languages allow the deliberate organization of its pieces to do much of the heavy lifting as opposed to referenced or logical organizations.<p>Don&#x27;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.