Ask HN: I can barely read, is there a way I could still learn to program?
19 comments
This is nearly impossible to answer without a clue about the disability; it sounds like it is cognitive rather than visual. Is it a struggle with the syntax of written English, or word recognition?
If you cannot map individual written words to meanings, you will likely find it next to impossible to program using textual representations of programs.
If you don't have problem memorizing and recognizing symbols, but struggle with syntax, then your problems may be mitigated by programming languages having quite regular syntax with few ambiguities, and usually without a very large number of phrase structure forms (grammar rules).
Some languages, like in the Lisp family, have an an unambiguous syntax, in which all grouping of tokens into higher level structures is explicitly marked off with parentheses, and most special syntax uses a very regular prefix notation, often just consisting of one or two characters which alter the meaning of a token or parenthesized group which follow.
Also, most programming languages are written in a two dimensional way with indentation. (A few languages enforce it; in others it is a matter of style which makes no difference to the machine). Most of the time, programmers do not read programs the way they read English sentences; they rely on the visual clues to understand the basic structure of the code.
When we read English sentences, we basically scan the words and feed them to the "natural language processing centre" of the brain, which works out the syntax for us, as if an inner voice were speaking the words to us. If someone has an impairment there, that can create a difficult. However, the expressions in a computer program aren't necessarily processed that way by the brain.
If you cannot map individual written words to meanings, you will likely find it next to impossible to program using textual representations of programs.
If you don't have problem memorizing and recognizing symbols, but struggle with syntax, then your problems may be mitigated by programming languages having quite regular syntax with few ambiguities, and usually without a very large number of phrase structure forms (grammar rules).
Some languages, like in the Lisp family, have an an unambiguous syntax, in which all grouping of tokens into higher level structures is explicitly marked off with parentheses, and most special syntax uses a very regular prefix notation, often just consisting of one or two characters which alter the meaning of a token or parenthesized group which follow.
Also, most programming languages are written in a two dimensional way with indentation. (A few languages enforce it; in others it is a matter of style which makes no difference to the machine). Most of the time, programmers do not read programs the way they read English sentences; they rely on the visual clues to understand the basic structure of the code.
When we read English sentences, we basically scan the words and feed them to the "natural language processing centre" of the brain, which works out the syntax for us, as if an inner voice were speaking the words to us. If someone has an impairment there, that can create a difficult. However, the expressions in a computer program aren't necessarily processed that way by the brain.
Wow, this is a really touching question. Thank you for your courage. It's inspiring.
My advice is follows. I would recommend a programming language with the simplest syntax, without the unnecessary policing that most languages entail. Begin with the lambda calculus, or better yet combinatory logic. The best book to slowly work through is "To Mock a Mockingbird", by Raymond Smullyan. After that you'll have a conception of what computation is. All computation is is substituting something in place of something else, or forgetting it, in a systematic way. From that point, you can move to something like the programming language Racket, which has a very simple syntax that is close to the lambda calculus. After this, you ought to be experienced enough to follow whatever path you wish to, for example understanding Javascript and how HTML on a webpage is scripted by it in response to user actions.
My best wishes to you.
My advice is follows. I would recommend a programming language with the simplest syntax, without the unnecessary policing that most languages entail. Begin with the lambda calculus, or better yet combinatory logic. The best book to slowly work through is "To Mock a Mockingbird", by Raymond Smullyan. After that you'll have a conception of what computation is. All computation is is substituting something in place of something else, or forgetting it, in a systematic way. From that point, you can move to something like the programming language Racket, which has a very simple syntax that is close to the lambda calculus. After this, you ought to be experienced enough to follow whatever path you wish to, for example understanding Javascript and how HTML on a webpage is scripted by it in response to user actions.
My best wishes to you.
You might be just one of the customers we can cater for at Dhi ( http://www.dhi.io ). Sorry, for the self promotion - but your problem is exactly something we think, we can solve.
We are attempting to change the way people perceptive programming, basically from a set of instructions to a set of features to have. If you are interested in Front End Development ( Building UI's ) then I would say check us out. We are still not out yet - but voice based programming is in our agenda of things to add( or you could just use some other voice recognition software! ).
There was an interesting talk at PyCon 2013 about programming using only your voice: https://www.youtube.com/watch?v=8SkdfdXWYaI Might be worth looking into for your case.
It's worth mentioning that the guy did this for himself due to severe RSI in the hands, but there was another talk on using a stenographic keyboard to program and I remember this guy stood up and said he wished he'd known about it earlier as it's another approach for people who suffer from RSI since there's less typing.
It's worth mentioning that the guy did this for himself due to severe RSI in the hands, but there was another talk on using a stenographic keyboard to program and I remember this guy stood up and said he wished he'd known about it earlier as it's another approach for people who suffer from RSI since there's less typing.
Here is a relevant StackOverflow question with many answers from visually impaired and blind programmers:
http://stackoverflow.com/questions/118984/how-can-you-progra...
One thing I learned is that you'll want to avoid python because it relies on significant whitespace.
I'm wondering if golang would be a good choice since it has lots of great language tools, including gofmt, which will help you collaborate with other developers in terms of writing clear well-formatted code.
http://stackoverflow.com/questions/118984/how-can-you-progra...
One thing I learned is that you'll want to avoid python because it relies on significant whitespace.
I'm wondering if golang would be a good choice since it has lots of great language tools, including gofmt, which will help you collaborate with other developers in terms of writing clear well-formatted code.
I personally hate working with LabView but it might be perfect for you. It's a graphical programming language but one that is full featured not a child's thing like scratch.
Is this compatible with your disability?
Is this compatible with your disability?
Don't give up on your dream
Parentheses will probably be difficult for you, but you should continue with your brave efforts to learn to program.
I'm totally blind and use text to speech software to program. I do type with a keyboard instead of using dictation though. Listening to code should not be an issue but I don't know how hard it would be to use voice dictation to program.
Well, I had a woman that was legally blind who worked for me and she was awesome. She wasn't just the barely legally blind, she was full on couldn't see the monitor, required a guide dog to navigate etc. She could see slightly on the screen using some special tools, magnifiers etc. But she would literally see only a few characters at a time, and she was writing C++ which can be tough for anyone with all the little nuances and 50 ways to do the same task.
Frankly she passed a tough interview, learned a tough domain and did really damn well. Not to mention who in their right mind would ever question this persons ability to take on a challenge, damn.
So my only point is, yes you can do what you challenge yourself to do. That does not mean it will be easy, smooth or always 100% rewarding while you are going through the process. I know nothing of your condition or situation but it sounds as though some verbal tutoring might be a first step to help you see if this is what you want. No matter what, good luck and enjoy.
Frankly she passed a tough interview, learned a tough domain and did really damn well. Not to mention who in their right mind would ever question this persons ability to take on a challenge, damn.
So my only point is, yes you can do what you challenge yourself to do. That does not mean it will be easy, smooth or always 100% rewarding while you are going through the process. I know nothing of your condition or situation but it sounds as though some verbal tutoring might be a first step to help you see if this is what you want. No matter what, good luck and enjoy.
That's awesome but what I don't understand is how she would be able to produce clean and readable code? To her it would seem that tabs/spacing/line lengths wouldn't matter to her unless mentioned during code review. Interested to hear how she handled it.
We had to make some accommodations on how we reviewed and enforced the coding standards. In the end though they actually made it better for all of us (especially considering we had some offshore development going too). In specific, we implemented a code formatting tool (and kept updating the rules), we also had a number of check-in rules but did the rest through peer assistance and standard code reviews.
In fairness, she would get most things in pretty good shape formatting wise. I think it was the reverse of reading for her. She could read documents using this machine that would blow them up massively to a few characters at a time, and she'd read across each line having to keep it all in her head. So I think since she was having to assemble the letters a few at a time and read across a page, she had the same ability to apply it to writing and formatting her code. Looking back at it now, her cognitive skills and memory had to be excellent.
As a matter or practicality, we did have her team lead sit with her before she was ready for code review (at least at first), just to help make basic formatting corrections etc. This just reduced us discussing minor formatting issues that the tools missed during a code review. As time went on the amount of effort others put in to help her on formatting was pretty minor, but at the beginning it did take some extra effort.
Another thing I learned working with her, she took great care in thinking through a problem before writing a single character of code. To the point that I feel she would work through things mentally way more than her peers that would do many more compile/test/code cycles. So I think that helped her too.
She also had everything in black and white, no color formatting in her code windows etc.
It was neat to work with her, no one questioned her ability after a little while, but there were people asking us wtf we were thinking hiring her at first. To those of us that interviewed her though, she was qualified and did better in the interview than a lot of the peers, so it was worth a shot.
In fairness, she would get most things in pretty good shape formatting wise. I think it was the reverse of reading for her. She could read documents using this machine that would blow them up massively to a few characters at a time, and she'd read across each line having to keep it all in her head. So I think since she was having to assemble the letters a few at a time and read across a page, she had the same ability to apply it to writing and formatting her code. Looking back at it now, her cognitive skills and memory had to be excellent.
As a matter or practicality, we did have her team lead sit with her before she was ready for code review (at least at first), just to help make basic formatting corrections etc. This just reduced us discussing minor formatting issues that the tools missed during a code review. As time went on the amount of effort others put in to help her on formatting was pretty minor, but at the beginning it did take some extra effort.
Another thing I learned working with her, she took great care in thinking through a problem before writing a single character of code. To the point that I feel she would work through things mentally way more than her peers that would do many more compile/test/code cycles. So I think that helped her too.
She also had everything in black and white, no color formatting in her code windows etc.
It was neat to work with her, no one questioned her ability after a little while, but there were people asking us wtf we were thinking hiring her at first. To those of us that interviewed her though, she was qualified and did better in the interview than a lot of the peers, so it was worth a shot.
You sound like one of those people who format code by hand instead of an in-IDE autoformatter.
Let the IDE/editor handle most of it. But some things just end up being handled on their own despite any suggestions by the IDE.
Kinda to that point. For that specific project we were mostly all in Emacs. So we had basic code formatting in Emacs and then the formatting tool took over to help make sure it was all standardized. It cut down the amount of annoying code format chatter in code reviews so we focused on the domain/code issues. Made us all more productive.
indent(1) or equivalent would solve that problem.
https://news.ycombinator.com/item?id=8965048 this guy uses a screen reader and recently got hired by MS. I hope you can achieve your goals!
I don't understand being able to read a bit. I do understand needing to hear it.
Can you see, but poorly, or? And is the need to hear it associated with that, or some other condition?
While I wait, I suggest getting a mentor or tutor. Perhaps you can have them help with little things that can trip you up, allowing you to get the feedback loop started that you need to progress in programming.
The way I see it is the concept of a program breaks down into instructions and data sequenced and arranged in a way that will direct a computer to do something useful.
Understanding that concept and working with it some requires some mastery of a computer language, and with that comes lots of little fiddly things: syntax, operators and other constructs that have to be right in order for anything meaningful to happen.
A lot of people come to grips with programming by using some simple, interactive environment where the syntax and other detail requirements are light enough for them to make progress on the core concept.
Then, they take on mastery of more details, which opens the door to bigger programs and more complex ways to create them.
Seems to me, having somebody able to read to you, parse your instructions, format them, and help with input might really help you out!
The other part of programming that is fundamental is related to having a place in your head for various things. Once those things are familiar, you can "see" them internally, and the flow, and structure of your program will be much easier to think about.
Having a mentor / tutor or friend help with detail just might crack the initial nut for you. And if so, then you may gain some insight as to your potential and desire.
From there, progress might be good, or sustainable.
I know and have worked with both a blind programmer and one that got disabled for a long time. ..broke both hands badly and had to use a voice recognition software to complete a PHP project. (that was ugly)
Both of them got some initial help. Once they got their heads wrapped around the problem areas, they were both able to get things done and make progress.
I second the others here who encourage your efforts. If you can crack this nut, it may well be very rewarding and enabling for you.
Can you see, but poorly, or? And is the need to hear it associated with that, or some other condition?
While I wait, I suggest getting a mentor or tutor. Perhaps you can have them help with little things that can trip you up, allowing you to get the feedback loop started that you need to progress in programming.
The way I see it is the concept of a program breaks down into instructions and data sequenced and arranged in a way that will direct a computer to do something useful.
Understanding that concept and working with it some requires some mastery of a computer language, and with that comes lots of little fiddly things: syntax, operators and other constructs that have to be right in order for anything meaningful to happen.
A lot of people come to grips with programming by using some simple, interactive environment where the syntax and other detail requirements are light enough for them to make progress on the core concept.
Then, they take on mastery of more details, which opens the door to bigger programs and more complex ways to create them.
Seems to me, having somebody able to read to you, parse your instructions, format them, and help with input might really help you out!
The other part of programming that is fundamental is related to having a place in your head for various things. Once those things are familiar, you can "see" them internally, and the flow, and structure of your program will be much easier to think about.
Having a mentor / tutor or friend help with detail just might crack the initial nut for you. And if so, then you may gain some insight as to your potential and desire.
From there, progress might be good, or sustainable.
I know and have worked with both a blind programmer and one that got disabled for a long time. ..broke both hands badly and had to use a voice recognition software to complete a PHP project. (that was ugly)
Both of them got some initial help. Once they got their heads wrapped around the problem areas, they were both able to get things done and make progress.
I second the others here who encourage your efforts. If you can crack this nut, it may well be very rewarding and enabling for you.
Thank you.
~SudoBash (I'm reluctant to use my real name for the potential of limiting future employment opportunities.)