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.
101–110 of 122 posts
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.
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.
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. 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. Elimi…
I don't understand what most of these points have to do with accessibility. Why would a blind person have more trouble with the fact that "x + y" might be addition or string concatenation than a sighted person? Why would compile-time type errors be more useful to a disabled person? And so on. It just feels like your opinions on a lot of language design holy wars where disabled people are just as likely to disagree wi…
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. If the solution were limited only to wheelchairs almost nobody would use it. It would just be in the way and be more of a problem than a solution.
If you are only solving for blindness you don’t really understand accessibility and are just in the way.
Earlier quoted context omitted.
I don't understand what most of these points have to do with accessibility. Why would a blind person have more trouble with the fact that "x + y" might be addition or string concatenation than a sighted person? Why would compile-time type errors be more useful to a disabled person? And so on. It just feels like your opinions on a lot of language design holy wars where disabled people are just as likely to disagree wi…
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.…
Earlier quoted context omitted.
I don't understand what most of these points have to do with accessibility. Why would a blind person have more trouble with the fact that "x + y" might be addition or string concatenation than a sighted person? Why would compile-time type errors be more useful to a disabled person? And so on. It just feels like your opinions on a lot of language design holy wars where disabled people are just as likely to disagree wi…
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.…
Perhaps instead, adapt a screenreader that understood C syntax, and instead of reading punctuation would read it in a higher level form, such as: for (int i; i instead of: "for left paren int i semicolon i lessthan 10 semicolon plusplus i right paren)"
https://www.scala-lang.org/blog/2018/06/14/accessible-scala....
Earlier quoted context omitted.
I don't understand what most of these points have to do with accessibility. Why would a blind person have more trouble with the fact that "x + y" might be addition or string concatenation than a sighted person? Why would compile-time type errors be more useful to a disabled person? And so on. It just feels like your opinions on a lot of language design holy wars where disabled people are just as likely to disagree wi…
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.…
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.
Explicit delimiters also have an advantage for keyboard navigation, enabling some degree of structural (by-block) movement. I prefer not to use a mouse/trackpad if possible—my main editor is Emacs in a terminal—and I know some people who have trouble using pointing devices or just don’t like switching between keyboard & pointer.
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.
Can you point out an example or two the bracket style that I could take a look at? Thanks.
someFunction =
do { foo
; mx do { baz
; pure (quux x)
}
; Nothing -> do { fnord
; blurch
}
}
; xyzz y
}
I find it nice enough to read, particularly because it leads to rapidly increasing indentation and consequently discourages deeply nested code, but it’s a bit of a pain to edit & diff. I would write the above like this: someFunction = do
foo
mx do
baz
pure (quux x)
Nothing -> do
fnord
blurch
xyzz y
This prefix delimiter style is actually fairly standard in Haskell not for “do” notation, but for records and lists, since Haskell doesn’t allow a final trailing comma in these structures: 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"
}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 stran…
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.
If you don’t know the symbol at all, though, that could definitely make things more challenging to learn, since then the notation is (even more) arbitrary. A lot of programming languages’ symbol choices are visually mnemonic: Perl has “$” for scalars, “@” for arrays, and “%” for hashes because dollar-sign looks like S for scalar, at-sign looks like A for array, and percent-sign looks like a pair of things (a key and a value), but there’s nothing about these symbols semantically or in their pronunciation that suggests their Perl meanings.