Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 122 posts

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

#111

Post by gitgud »

informatimago wrote: post #20

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…

Using dashes in symbol names is problematic. It becomes impossible to differentiate

    my-var & my - var
As variable declaration or assignment looks very similar to the subtract expression... But if you enforce whitespace, then it's clearer I suppose...

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

#112

Post by snazz »

gitgud wrote: post #111
informatimago wrote: post #20

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…

Using dashes in symbol names is problematic. It becomes impossible to differentiate my-var & my - var As variable declaration or assignment looks very similar to the subtract expression... But if you enforce whitespace, then it's clearer I suppose...

The subtract expression in Lisp looks like

    (- my var)
because Lisp uses prefix notation. You would never run into ambiguities since there are no infix operators in Lisp at all.

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

#113

Post by austincheney »

kbp wrote: post #107
austincheney wrote: post #103

Earlier quoted context omitted.

The nature of accessibility is in solving universal access problems. It includes blind people but isn’t limited to blind people. One of the largest areas of accessibility is solving for cognitive impairments. The classic example is wheel chair ramps. Who benefits from those? People who have bad knees, people with strollers, people with heavy roller bags. The ramp was installed for wheelchairs but everybody benefits.…

You misunderstood. I only used blindness for the specific example where you used blindness (the only specific example of affecting someone with a disability that you gave; why would that be harder for a blind person?). Most of your points didn't explain how they related to accessibility, they just said your way was easier and better without explaining how or to whom. That's what I was asking.

Many people conflate access to aesthetics. There is a difference between actual ease of access and perceived elegancy resultant from vane conditions.

Specifically regarding programming languages the primary concern is parsing, whether that parsing is from software or people reading code.

As a person who has spent 10 years writing language parsers and code beautifiers the vane notions of what a language should look like are highly subjective and not incredibly beneficial. The mechanics and syntax of a language are far more important for understanding what code says very quickly. Like with natural written language elimination of ambiguities and redundant meanings speeds learning and reading which has second and third order consequences for the simplicity of tool design.

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

#114

Post by mwcampbell »

ndarilek wrote: post #69
currymj wrote: post #64

Earlier quoted context omitted.

Are Unicode characters a problem for the tools you use? For example, some languages will let you use λ instead of lambda. Or when trying to define the logistic function, I sometimes find myself writing σ(x) = 1.0 / (1.0 * exp(-x)) Or the Julia language has ≈, which tests if two floating point numbers are approximately equal. Visually, this is a reasonable symbol, it's not like one of the weird functional programming…

My screen reader, Orca under Linux, read those as "sigma" and "almost equal to." So I suppose those work, though I'd have to hit Google to find out how to type them. :)

The NVDA screen reader for Windows also reads these symbols. So it looks like they're not a problem.

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

#115

Post by gostsamo »

evincarofautumn wrote: post #110
vu47 wrote: post #91

Earlier quoted context omitted.

I never thought about the concept of programming in symbols that you've never before seen. That's rather fascinating. The human brain is incredible.

I’m not sure, but based on what statistics I can find, it seems most blind people aren’t congenitally blind, so they probably have some familiarity with the symbols, maybe depending on how old they were when their visual impairment manifested. And of course you could always learn the shape of an unfamiliar symbol by feeling a physical representation of it—like on embossed paper, or those letter-shaped fridge magnets—…

It is not about if I've seen the symbol or not. { for example is read as "left brace". It takes the screen reader the time to pronounce two words with ambiguity left. What about ${variable}? You have 3 extra symbols totaling five words to surround a single variable. Redundant and abhorrent.

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

#116

Post by kazinator »

gitgud wrote: post #111
informatimago wrote: post #20

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…

Using dashes in symbol names is problematic. It becomes impossible to differentiate my-var & my - var As variable declaration or assignment looks very similar to the subtract expression... But if you enforce whitespace, then it's clearer I suppose...

There is a quite a lot of experience with dashes in names in FOSS because they are used in shell and Makefile programming, not only in Lisps.

Git commands have dashes: git cherry-pick.

Lots of hits with this: echo /usr/bin/-

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

#117

Post by dan-robertson »

timdavila wrote: post #84
dan-robertson wrote: post #65

One thing which I think might be useful for speaking code is to try to avoid needing a mental stack or going backwards as you go through code (at least for English speakers. Maybe other languages are different). For example consider reading aloud: x = some_function(something_else(y), z) You first need to keep in mind “x =”, then “some_function”, then think about what something_else(y) means, remember about some_funct…

Yes, for me SQL is very hard to reason about just because of the way it's "phrased" It's much easier for me to interpret JavaScript or PHP method chaining. I find myself struggling when I can't use an ORM.

I disagree with this. I think sql is actually mostly very good, with the exception that maybe the FROM clause should come before the SELECT.

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

#118

Post by picometer »

A while back I was experimenting with something akin to "syntax highlighting" with sound instead of color. The idea is to play different tones/noises depending on where your cursor is located in your code. Rough proof of concept that you can try out: http://marycourtland.github.io/AuralJS/

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.

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

#120

Post by timdavila »

dan-robertson wrote: post #117
timdavila wrote: post #84

Earlier quoted context omitted.

Yes, for me SQL is very hard to reason about just because of the way it's "phrased" It's much easier for me to interpret JavaScript or PHP method chaining. I find myself struggling when I can't use an ORM.

I disagree with this. I think sql is actually mostly very good, with the exception that maybe the FROM clause should come before the SELECT.

It's probably just the way my brain works. After a SQL statement goes to more than ten lines or so I have to study it very hard to understand what's going on.

Maybe it's the way I was taught.

Post reply on HN