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.)
61–70 of 122 posts
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.)
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…
Bracket loop bracket print bracket eval bracket read bracket bracket bracket bracket?
The key thing I think is balancing and shifting parens.
(loop (print (eval)) (read))
Is quite hard to sound different from (loop (print (eval (read))))
And more crucially what about the difference between these two: (let ((x (f))) (g x) (g x))
(let ((x (f)) (g x)) (g x))
(I think writing these on a single line makes them written more like they might be spoken)On the other hand I think being able to modify the syntax structurally is a big advantage.
Going back to the topic of the OP I think a useful thing is putting functions after their arguments, and optimising to have single arguments or most non-main arguments being typically small. For example something more like
read
| eval
| print
| loop
And maybe some way to do arguments like read stdin
| eval some-environment
| print :pretty
| loopOne of the software engineers where I work is completely blind. I've never had a chance to interact with him as he's in a remote office unfortunately. He mainly writes in Python, bash, and C. 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…
I would find it very interesting to read your coworker's account of what programming is like. Or anyone's account who has to approach programming differently compared to the average person. I'd love it if more people blogged in general.
Hey, kudos to you for thinking about this! Background: I'm totally blind, have programmed for nearly 3 decades, kind of do the in and out of half a dozen languages thing these days. Today's favorites are Rust anywhere I can get away with it, Python because it runs in places where I need it (Home Assistant, Mycroft, etc.) and JavaScript because if I hold my nose and don't think too much about the atrocities I'm commit…
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 spaceship operators. But I have no idea what a screen reader would read.Sometimes this sort of thing lets code correspond almost exactly to the notation in papers. It is a minor aesthetic improvement, but if it breaks screen readers and other tools I'd rather just write out "sigma" or "lambda".
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_function, think about z, then remember it all goes into x.Now compare:
something_else(y)
-> some_function(z)
:> x
Read forwards as “do something_else(y), now take it and do some_function to it, modified as z; now put it into x.”Maybe we should train to code without screen: just a keyboard and a headset.
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.
Earlier quoted context omitted.
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.
This. Very few language designers understand the usefulness of being able to parse the code while it is incomplete/being typed out. You end up with “hacks” to color your code vs a real parser to compile the code.
Hey, kudos to you for thinking about this! Background: I'm totally blind, have programmed for nearly 3 decades, kind of do the in and out of half a dozen languages thing these days. Today's favorites are Rust anywhere I can get away with it, Python because it runs in places where I need it (Home Assistant, Mycroft, etc.) and JavaScript because if I hold my nose and don't think too much about the atrocities I'm commit…
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…
I founded and co-own the google group Blind Dev Works. I have posted this Ask to it. It has at least a couple of blind developers on it and a stated purpose of improving programming tools for blind developers. You are welcome to join it. 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…