Ask HN: How should a programming language accommodate disabled programmers?
51–60 of 122 posts
Re: Ask HN: How should a programming language accommodate disabled programmers?
#52> 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
Re: Ask HN: How should a programming language accommodate disabled programmers?
#53It 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 reali…
"Go back 3 words and delete this word". "Replace the current word with 'foo'". "Select the current paragraph and move it down 1 paragraph".
Changing modes would likely be an issue. A safe word might not be the best solution. I guess a hardware button would be the best option.
Re: Ask HN: How should a programming language accommodate disabled programmers?
#54Re: Ask HN: How should a programming language accommodate disabled programmers?
#55Re: Ask HN: How should a programming language accommodate disabled programmers?
#56A 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.
Re: Ask HN: How should a programming language accommodate disabled programmers?
#57Earlier quoted context omitted.
> is not whitespace-sensitive, how can you see the size of whitespaces when you're blind? Can't indentation be handled by the IDE as having a meaning like "root class declaration", "function declaration", "nested block 1", "nested block 2"? Indentation has meaning and meaning can be converted. Even Xcode seems to be context aware as I can choose where certain code block shortcuts can or can't be executed. "This is a…
If you are willing to restrict a programmer to only look at accessible renderings of the AST, then there is probably nothing to consider, but a programmer's job is also handling what happens when a program does not parse.
You end up with “hacks” to color your code vs a real parser to compile the code.
Re: Ask HN: How should a programming language accommodate disabled programmers?
#58Avoid Perl 6 and its horrifying Unicode keywords and operators.
Re: Ask HN: How should a programming language accommodate disabled programmers?
#59Lisp: - 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…
Re: Ask HN: How should a programming language accommodate disabled programmers?
#60Lisp: - 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…
I love Lisp but every experienced lisper will tell you they don't see the parentheses, they look directly at the AST. Seeing the AST is, for me, highly visual (proper indentation is a must) and I wonder how a blind programmer could see that.