1. 134

  2. 35

    I’m visually impaired (legally blind according to the U.S. definition), but don’t really care about tabs versus spaces. I use a single wide-screen (16:9) monitor, roughly 18 inches diagonal, and read the screen up close with largish fonts. (I do use a screen reader for web browsing, email, and some other things, but not coding.) With my preferred terminal font, I can fit about 110 columns and 30 lines on the screen. So I don’t really have any special requirements as far as indentation goes. I just go with the convention for the language, project, or team.

    I’ve worked with some totally blind programmers over the years. Some use tabs, some use spaces, and some don’t indent at all or are inconsistent about it. (The latter category didn’t work in a corporate environment with sighted teammates IIRC.) It may be worth noting that the NVDA open-source screen reader project, which is developed largely by blind people, uses tabs for indentation, even though that’s not conventional for its primary language (Python). But some blind programmers do program comfortably in Python using standard 4-space indentation.

    In my personal opinion, speaking only for myself, I don’t think it’s worth getting worked up about tabs versus spaces for the sake of accessibility. I think the visually impaired developers referenced in the original post should figure out how to adapt their environments for their needs, without requiring their sighted teammates to change their coding style. I certainly don’t expect my sighted coworkers (and I do have many of them now) to go that far to accommodate me.

    1. 6

      Thank you, this is a very helpful counterpoint to the article.

      Perhaps the better takeaway is to be consistent. In this particular case, perhaps it is better understood that the company/team had already established a standard of tabs for reasons and for anyone to come in and change to spaces would require additional accommodations.

      I confess my temptation was to bust out sed/awk and start a massive spaces -> tabs conversion.

      One minor point though -

      I certainly don’t expect my sighted coworkers (and I do have many of them now) to go that far to accommodate me.

      I don’t think it is unreasonable to make accommodations for teammates even hard ones. If you knew that a teammate worked better using tabs because of let’s just say the spacing issue (or just pretend there are really good reasons), you would accommodate them - because they are on your team. That is part of working on a team, we all make concessions for each other’s needs.

      1. 2

        An hypothesis is that in the context of original post, the visually impaired workers are used to work with tabs and as such, switching to spaces is really hard and a problem, but person visually impared with not such environment such as you not have this problem.

        As such the original poster should stick with his company coding style and it is not a good argument for general debate tabs vs space.

        It is one more argument about don’t switch of the coding style you are expected to use.

        1. 2

          I feel like if all code is consistent one way or another it is easier to adapt custom tools to work with it regardless of space or tab.

        2. 18

          Maybe we’re approaching this wrong. I’m not sure tabs (which are meant for tabular data) are the right tool, because, as others have pointed out, if you do something like


          You kinda want those arguments to line up. We kinda abuse the space as a formatting character here, which is also kind of a hack that works because we use mono-spaced fonts. Some assumptions start to break down when you start to use ‘wide character’ (as in, chinese or emojis) in code, which take up two ‘spaces’. Ideally, we want to separate the indentation concerns from the representation of the code.

          What I’m suggesting would be something where there is no indentation in the code at all, and rather the editor you use parses the code (which it does anyways, kinda, for syntax highlighting) and it indents it based on grammar rules (which you can customise). That way, you can do away with code formatting tools, because the code is only formatted as it is rendered. That way, a visually-impaired person can set their indent side to anything they like. It would end all debates on how to format code.

          Having this kind of a syntax parser in editors also means that editors could prevent you from writing syntactically incorrect code. Remember the Apple goto fail bug (article here)? That would have been prevented if the editor wouldn’t have let them indent a goto statement that is not part of an if statement.

          1. 32

            You could put the first parameter on its own line and use indentation for alignment.

            1. 11

              Now put the final ); on its own line and you have a format that’s both balanced and easily machine-generated. :)

              1. 7


              2. 7

                What you are looking for is called “structured editing”, where the source code isn’t really text, but the AST. The main problem with that is interaction with external tools such as version control: tools that don’t know what they are dealing with will just use the binary representation of the AST (which might be some form of text like you just described, but will still lack indentation).

                An alternative would be to canonicalise the source code: use structured editing, let users have their own preferred settings for alignment, indentation width, character width… and save the canonical form to disk. That way, when opening the source code with a regular text editor, or viewing a git diff of it, we should not be too confused about what this code is all about.

                But now some people will want to edit the source code directly, so it may not be canon any more. (Maintaining canon may be especially difficult if the canonical line width is limited.) You’d need an auto-formatter, either as a stand alone program, or integrated with the compiler.

                1. 2

                  I think the OP has an interesting point. It reminds me of one of Brett Victor’s talks, The Future of Programming, were he plays the role of a 70’s engineer and remarks “it would be a shame if in 40 years time we are still coding procedures in sequential text files”).

                  So maybe we should be using some kind of database or programmer-independent format for code, and do the layout separately (a la Smalltalk) and tailored to taste. Anyway, the computer does not care about formats.

                  1. 2

                    Lisp IDEs allow doing structural editing directly on s-expressions. You can even create visual editors on top of that. Fructure is a great example. None of this affects source control because you’re working directly on the source.

                  2. 4

                    It would also be nice if the entire toolchain were aware of the language, so for instance changes that are transient wouldn’t trigger diffs with source control.

                  3. 16

                    I’ve been doing tabs for indent and spaces for alignment for a similar reason: some people like a tabwidth of 2, some of 4, some of 8. Also, using tabs makes parsing slightly easier, and provides visual guides when you represent tabs with glyphs in your editor. But nothing beats this accessibility argument, it makes the choice much more obvious.

                    1. 6

                      The problem with tabs is that lots of people use tabs in such a way, that it looks sane only when you’re using their tabwidth, and looks confusing if you’re using a different tabwidth. So not only this defeats the purpose of tabs, but you also need to know their tabwidth in order to even read the source code, let alone modifying it.

                      1. 1

                        Can you elaborate on this? It should only be an issue if different lines in the same file use spaces on one line, tabs on another.

                        1. 4

                          Here is an example of what I have in mind:


                      2. 2

                        Seems reasonable. I still have one problem, though: in the editors I have used to date (emacs, QtCreator, VisualStudio, XCode), I haven’t found an easy way to actually do that.

                        Emacs has the best UI when you agree with the mode’s settings: hitting [tab] will instantly indent and align the current line of code. If you are using tabs however, emacs will use as much tabs as possible, then fill the remainder with spaces. Which is hell with variable width tabs.

                        The other editors, by default would just add one tab character (or 4-8 spaces) when I hit [tab]. No more easy alignment, that’s a drag.

                        It’s been a while since I used a modern IDE, though, and I never tried to have Emacs do the right thing (I only used it on spaces projects) Can we now easily set up our editors to help us indent with tabs and align with spaces correctly?

                        1. 2

                          I just had a quick look in the QtCreator settings (Tools menu > Options > C++ > Edit… > General), and it looks like if you select these options, you will get tabs for indent and spaces for alignment within the indentation level:

                          • Tab policy: “Tabs Only”
                          • Align continuation lines: “With Spaces”

                          I haven’t tested it thoroughly, but it appears to do the right thing in the example code next to the settings.

                      3. 10

                        I’d never thought about the tabs vs. spaces debate in that sense, but after reading the main post, I really am reconsidering how I go about things. I don’t personally work with anyone with a visual impairment or disability, but I think in an effort to make my code more accessible, I’m considering switching my vim settings to stop turning tabs into two space bar pushes.

                        1. 14

                          There are two reasons that I don’t like tabs:

                          1. “Tabs for indent, spaces for alignment” requires a lot of discipline. Even if you’re disciplined, it’s easy to screw up and the mistake isn’t noticeable until you change your tab width display preference. In my experience working on teams, I have found that it’s hard enough to get people to use tabs or spaces without screwing that up. To ask them to use a specific mixture of tabs and spaces is an unwinnable battle.
                          2. It’s hard to enforce meaningful rules about line length when you use tabs for indentation. When you use spaces, you can have a simple rule “lines shall not exceed 100 characters except in the case of user visible strings on their own line”. When you use tabs for indentation, you have to change your rule to “lines shall not exceed 100 characters wide based on a tab rendering width of 8 spaces except in the case of user visible strings on their own line”. Many people will choose a tab rendering width narrower than 8 spaces and as a result it will be very easy for them to author lines which are under 100 characters in their environment, but span past 100 when tabs are expanded to 8 space width.
                          1. 4

                            Maybe the first point can be mitigated by having a highlighting rule that paints ^\s*( \t|\t ).* bright red. Or by prettier! Code auto formatters are lovely. ❤

                            1. 1

                              Sometimes, though, you can use only tabs for alignment, to get it to align just right; that won’t help you there.

                            2. 3
                              1. Use visible whitespace in your editor and it is easier to be disciplined about. Combined with a .editorconfig file and IDE tools to detect mistakes, and it is not as hard as all that.
                              2. I’ve never found line length restrictions to be valuable, so this is not a consideration for me. In a world with word-wrap, where many people working in tech have 27” monitors, and in which a horizontal scrollbar exists, it just seems unimportant. Code in practice in my experience tends to fall within reasonable limitations naturally, anyway. The only times I’ve rejected a code review because a line of code was too long was because the engineer was trying to do too many things on one line anyway (ie, ternary operator magic, or math that could be abstracted into local vars for readability). Character restrictions for line length seem overly pedantic to me unless you have a specific technical reason to have them (ie, this has to display on an old TTY or has to be printed out at a specific font size or something). Why would you need them in the general case?
                              1. 5

                                Word wrap is garbage, especially for diffs / 3 way merges. On my 27” 2560x1440 display at a normal font size, 80 chars wide fits 3 side by side panes of code. Or the diff view in my IDE (2 panes), with space for the sidebar and gutters. Or just cross-referencing 2 files.

                                Working on code with a hard 80 chars rule has been magnificent.

                                1. 4

                                  Why would you need them in the general case?

                                  I like to split my window to 2 or 3 columns, so even though I have a wide screen monitor, I value 80-column source code restrictions. This allows me to simply have 2 or 3 files open at the same time which I can browse independently.

                                  Example: https://i.imgur.com/Xvj9R.png (not my screenshot, but it looks pretty similar in my setup)

                                2. 3

                                  While I understand the reasoning here. These are preferences and IMO accessibility > preferences.

                                  1. 13

                                    IMO accessibility > preferences.

                                    Well. This is being presented as some sort of binary absolute – that is, “spaces = 0% accessible, tabs = 100% accessible” – with no mention of compromises or tradeoffs or deeper investigation. But actual accessibility never works that way. There’s always a spectrum of options, each coming with its own set of tradeoffs, and navigating them well requires context and understanding and weighing those tradeoffs against each other.

                                    So color me skeptical of the rush by many people to declare victory in the tabs-versus-spaces holy war on the grounds that “it’s proven more accessible to use tabs, so tabs win”. Those people didn’t realize until very recently that there even could be accessibility implications to the choice. I wonder what thing they don’t realize today they’ll get to find out about tomorrow.

                                    1. 1

                                      Fair point, I have been an avid spaces advocate mostly for the sake of consistency. I have never really cared much about alignment and prefer to align things at the beginnings of lines. But what this pointed out to me was that while my arguments for spaces have mostly been preferences about code structure, the other side has a real legitimate need that surpasses my preference. Perhaps there is another accessibility case that supports spaces, I just haven’t heard it in the 20 years I have been having these discussions. But to be fair, I hadn’t heard this one until today, while I have worked with deaf programmers, I have yet to work with anyone visually impaired.

                                      1. 2

                                        The first issue that comes to mind for me, with this specific situation, is that it’s almost certain to come down to tooling. Accessibility tools tend to kind of suck, but that creates a situation where you need to be very careful to maximize someone’s ability to use accessibility tools while not building permanent assumptions in about the abilities and shortcomings of the specific tools available right now. If we all rush out and convert to tabs-only today without any further thought about it, we run the risk of locking in the shortcomings of today’s tools in ways that may not be good tomorrow.

                                        Which is why I’d really prefer to hear educated opinions from people with expertise in accessibility tooling and practices before coming to any decisions based on this.

                                3. 7

                                  Okay, this is great food for thought, and I’m grateful to have read this post.

                                  That said, I’ll continue: I don’t have a problem with using tabs in theory. My problem is, in practice, tabs and spaces getting mixed together in a given file. The indentation gets all messed up (jagged and inconsistent). I apologize if this is a truism that I needn’t explain.

                                  If I were in a team or department that enforced and immaculately adhered to an only-tabs policy, I could live with that, and conform. But if I regularly (say, every 3 weeks, or more often) have to deal with mixed spacing, that would be a bit irritating, and I’d push for the department to establish and stick to a policy one way or the other.

                                  1. 3

                                    Use commit hooks to lint on commit, and push hooks to reject pushes with bad spacing.

                                    1. 1

                                      You’re right. The last time I had to think about this kind of thing, the teams I was on were using CVS or Subversion, so we didn’t have such modern amenities.

                                  2. 5
                                    sed -i s/\(    \)/ /g


                                    sed -i s/\(    \)/        /g

                                    for a quick and dirty hack.

                                    A script in your favorite language for dealing with the fact this is context sensitive. Then a inverse script to get it back to what is standard in the company.

                                    Not sure what the problem is. Programming is the manipulation of text. If we have gotten so bad at it that we need to force humans to put white space characters in the right places then we have bigger problems than accessibility.

                                    For anyone capable this should be a fun hour of work or less. A lot less time than it took to write that post.

                                    1. 5

                                      I couldn’t have said it better. Further, the visually impaired programmers referenced in the original post should be the ones doing this adaptation, not their sighted coworkers. I say this as a visually impaired programmer myself; see my other post on this thread.

                                    2. 5

                                      Ah, that good’ol Tab vs Space thread. Happy to see you’re in good shape after that much time.

                                      1. 7

                                        Calling it “the real reason” is a bit of stretch (it’s more like “what I realized by accident after N years in the industry”), but the reason does actually sound quite compelling – to the point that I makes so much sense that struggled to remember why I preferred spaces all this time.

                                        I think the reason is alignment – I do things like



                                        sprintf("%s %s %s\n",

                                        regularly, and spaces guarantee that these will actually show up consistently. You could have the cake and eat it by using tabs for indentation and spaces for alignment – which makes sense when you think about it, but somehow “feels dirty” to mix the two.

                                        1. 8

                                          tabs for indentation and spaces for alignment

                                          This sounds reasonable to me.

                                          but somehow “feels dirty” to mix the two

                                          I think I can learn not to fee dirty if I remember that I wont actually be mixing the two. The tabs are strictly in prefix.

                                          1. 7

                                            The tough part is that if you are writing Python, mixed tabs and spaces are illegal, and the standard style guide for the language specifies spaces only. Outside of Python, it feels like tabs for indentation and spaces for alignment requires editor support: at a minimum, visible whitespace, but preferably also for automating the number of tabs and number when reindenting.

                                            I have always been a partisan of spaces-only, but this is the first argument for tabs that I find really strong. I do feel like I need to work towards adopting tabs.

                                            1. 12

                                              The tough part is that if you are writing Python, mixed tabs and spaces are illegal

                                              “Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.” That is, you can use spaces for alignment if you consistently use tabs for scoping.

                                              e.g. This works

                                              $ cat -t x.py
                                              def a(x):
                                              ^I      "2"
                                              ^I      "3")

                                              And python does not complain.

                                              $ python -t x.py
                                              1 23
                                              1. 3

                                                Thanks, yes, you’re right. This leaves just the task of always maintaining perfect consistency in using tabs for scoping and spaces for alignment. Plus being willing to ignore the standard style guide (PEP 8) and avoid using code formatting tools like black.

                                          2. 4

                                            somehow “feels dirty” to mix the two.

                                            Why? Tabs are for indentation (semantic) whereas spaces are for alignment (visual). They’re different things.

                                            1. 1

                                              It’s “dirty” when different lines use different characters for indentation and alignment. e.g. line 1 uses 2 spaces for a single level of indentation, and line 2 uses 1 tab for a single level of indentation. (I’m not disagreeing with or discounting your point about having a rule to consistently abide by.)

                                              1. 2

                                                That is a different situation than what was described and called “dirty”.

                                            2. 4

                                              The main downside to using tabs + spaces is editor support. Back when I used it, I think kate was one of the few editors that didn’t mess up my code. I eventually moved to spaces only out of frustration with different editors.

                                              The other downside is all the derision you get for using tabs.

                                              1. 2

                                                You can’t use spaces for alignment for the same reason that tabs are apparently more accessible: different people will use tabs to mean different things. If you use space for alignment you are just moving the problem around, insisting that a tab is equal to N spaces – to keep your precious alignment correct.

                                                1. 12

                                                  If you use tabs only for indentation, then your spaces will always line up. E.g. if you are 2 levels of indentation deep, and want to line up with the 3rd character, you have 2 tabs and 2 spaces. Regardless of tab length, 2 tabs and 2 spaces will end up at the same column as 2 tabs and 2 characters.

                                                  Rule of thumb is if you are visually lining up to a previous line, use spaces. If you are adding a level of indentation, use a tab.

                                                  1. 4

                                                    That makes sense, I’m wrong :)

                                                    I suppose a follow-up question is, does spaces for alignment satisfy the usability concern which tabs help with?

                                                    1. 2

                                                      That’s a good question. I would imagine the answer isn’t so much that spaces for alignment helps, it’s the tabs for indentation that help. Spaces for alignment satisfies the “consistent alignment” part of the problem.

                                                2. 1

                                                  If you drop the first method call/arg to a new line, indented one level more you get a similar effect with tabs only. And you save some horizontal space when the var/symbol on the first line is longer than one tab-width.

                                                  JetBrains tools call this style “chop down” I believe.

                                                3. 4

                                                  What I’m left wondering after this post is why it is that editors only support this with tabs. I get that with tabs its easier to implement but in a file that is consistenly indented with 4 spaces it shouldn’t be hard to render that with any amount of spaces you want per indent either right?

                                                  1. 4

                                                    Alternatively, just use a language with a native code formatter. Examples: zig fmt, go fmt, etc. Then you can use whatever your muscle memory dictates while typing in code, and still have a consistent format applied on saving.

                                                    1. 3

                                                      Then you can use whatever your muscle memory dictates while typing in code

                                                      Are you suggesting people sit there hitting space 4 times to align their code?

                                                      1. 2

                                                        People do. (I do, when I’m using a language like renpy where it doesn’t support tabs for indentation at all.)

                                                        If you’re not, then what exactly is the point of using spaces to indent? If you’re just autoexpanding tabs, then your tab expansion is controlled by your tabstop setting, and so you don’t experience any difference when editing code (except that you may need to press backspace four to eight times instead of one when de-indenting & you will find that your source files will be a few hundred bytes longer).

                                                        1. 1

                                                          I think most programmers who prefer spaces (including myself) autoexpand tabs, at least in my environment.

                                                          Main reasons I have for using spaces:

                                                          • Consistency between different environments
                                                          • Consistent visual width for characters
                                                          • Possibility to set guides/constraints for line length
                                                          1. 1

                                                            Consistency between different environments

                                                            As the author of a piece of text, I don’t think I have any right to impose my indentation-width preferences on other readers or editors. If code I have written becomes less readable when the tabstop is set differently, then I have failed to write clean code, and no changes to spacing will fix that underlying problem.

                                                            Consistent visual width for characters

                                                            We already have all sorts of characters that have widths other than 1 (even in monospace fonts, where characters have widths that are integer multiples of the glyph width). Even within ASCII, CR ought to be zero glyphs wide, while LF is sqrt(-1) wide, and backspace is -1 glyphs wide.

                                                            Possibility to set guides/constraints for line length

                                                            Line length constraints are typically with respect to number of characters. In other words, it’s line length rather than line width.

                                                            1. 1

                                                              We already have all sorts of characters that have widths other than 1 (even in monospace fonts, where characters have widths that are integer multiples of the glyph width). Even within ASCII, CR ought to be zero glyphs wide, while LF is sqrt(-1) wide, and backspace is -1 glyphs wide.

                                                              So yes ofcourse LF and CR are exceptions to this rule, however when I think of code I think in lines and columns and not one long string of characters, so to me the characters that represent these columns are the ones that matter when thinking about character width. Regarding backspace and non-ascii characters my strong belief is that those do not belong in source code altogether.

                                                              Line length constraints are typically with respect to number of characters. In other words, it’s line length rather than line width.

                                                              Not entirely true, indeed linters/formatters tend to look at line length, however every text editor I have used tends to visualize these kinds of constraints with a line at a certain line width. Not having to worry about this distinction however is exactly my point about why I think spaces work better for this purpose than tabs. Also although most constraints are indeed implemented to look at line length, I think the motivation behind why that constraint was put in place is usually because of line width which further emphasizes why it is nice to not have a distinction between these two.

                                                    2. 10

                                                      My reactions are:

                                                      • Are the spaces people just now figuring this out? If that is the case, get out of your bubble and into the real world where you can encounter, for example, blind people, whom perceive the digital world through a Braille-display of usually only 1x40 character displays or 2x80 character displays if they are lucky. Taking up 3 tab symbols is way better than taking up 12 or 24 symbols on their displays. Tabs are simply a blessing for accessibility in most cases.
                                                      • Ever looked at a hex/deximal-dump of your source files? I definitely prefer code written with tabs in that case. You just look for the 09 bytes and count them to figure out your level of indentation. Counting to 3 0x09 or 09 bytes is better than counting 12 0x20 or 32 bytes.
                                                      • When writing code, I usually use tabs in an editor which I can configure to output whatever is desired, but I’m hitting that tab-button instead of the space bar. Even in languages where the number of prefix-spaces can be any random number, I still hit tab most of the time and trust my editor to convert tabs to spaces where needed.
                                                      • In the end I really just don’t care and I think this is kind of a non-discussion, because we have plenty of tools that can fix this for us. So if the language you are using is not depended on whitespace (python and Haskell are, but Java, C/C++ etc are not), then just use tabs and let the individual coder do whatever he or she prefers.

                                                      However in defence of spaces:

                                                      • Everything always looks the same way and as intended without any effort on just about every machine.

                                                      I just don’t see why this should still be a problem or even a discussion in 2019.

                                                      1. 16

                                                        If that is the case, get out of your bubble and into the real world where you can encounter

                                                        That’s going too far. I’ve met tons of programmers in lots of spaces. This site was the first site I learned stuff about blind or visually impaired programmers. This is the first time I’ve heard about this issue. My favorite use of the a11y tag so far. A charitable position is to just assume others might have not run into the same people or read the same articles as you.

                                                        1. 5

                                                          Fair enough….

                                                          However, I ran into visually impaired CS students immediately in my freshman year of university. And there was at least one visually impaired student in each year. In fact: There were cohorts in which we had more visually impaired programmers CS students than we had female CS students. So I’ve been thoroughly aware of these issues, right from the start of my career.

                                                          1. 4

                                                            While I had met a few Deaf students during my studies at my university, I never met any blind person. My university also had an active Deaf culture, and I am familiar with their accessibility requirements. Perhaps people with different accessibility requirements choose the university more well known to have catered to people with similar requirements.

                                                            1. 3

                                                              That’s really interesting. I’d have not expected that.

                                                              1. 5

                                                                Maybe that is because my university had the facilities to accommodate visually impaired students at the science department. It’s something only the bigger ones can afford. And then they have to be willing to go the extra mile as well.

                                                                Anyway: All I can say is that there seem to be more visually impaired programmers then one would expect if one were just to take a random sample of people from the general population.

                                                                1. 9

                                                                  This, this, this. People often think disabled people don’t exist or are very uncommon in a space or discipline, not because it’s inherently so, but rather because the spaces those people have been in aren’t accommodating to disabled people, and so those disabled people went elsewhere! (Grumble grumble something about my school saying we didn’t need elevators because no disabled students attended anyway.)

                                                                  1. 2

                                                                    Sometimes the issue is just plain and simple economics.

                                                                    The costs of retrofitting an old building, if possible at all, with elevators are often prohibitively high. Even more so if the building is constructed from concrete. That probably plays a role as well when a statement like that is issued, but is left out by the speaker. This is because the speaker often assumes that the listener has the same background information as the speaker has, which is often not the case. This idea probably has a name already, but I am not aware of it. This is why empathy and the ability to read between the lines correctly, without making unnecessary assumptions are vital skills.

                                                                    1. 3

                                                                      Believe me, as the former treasurer of the student disability advocacy organization at Beloit College, I’m well aware of these economic factors. I was merely using that as another example of the effect you mentioned.

                                                          2. 11

                                                            blind people, whom perceive the digital world through a Braille-display

                                                            Side tangent: I’ve never known a blind person in tech with a Braille display. Everyone I know uses Jaws, ZoomText or some other screen reader and headphones. One of my friends said he never liked Braille displays; how they were super expensive and didn’t work well with a lot of the software he used.

                                                            The only place I’ve actually seen one of these was in the movie Sneakers.

                                                            1. 1

                                                              I have a (fully) blind relative which uses one for all interaction with a computer in combination with headphones and screen readers. It is apparently nearly impossible to type a regular letter or e-mail without a Braille display. The smartphones are the exclusive domain of just screen readers and voice typing though.

                                                              1. 1

                                                                Wait a minute, can’t blind people just touch type on a regular keyboard? I mean, I’m not blind, but that’s what I do. I arguably correct my errors faster, because I can see them on screen, but they could be nearly as fast by hearing their typos. Couldn’t they?

                                                                1. 2

                                                                  That doesn’t work in a lot of cases, like coding or excel spreadsheets for example. Then there is also the fact that a moderately skilled reader, can read about 2 to 3 times as fast as they can process the text by hearing. Truly skilled readers can read about 5 times as fast. Screenreaders are capped at what our human auditory systems can process and visually impaired people can stretch the capabilities of their hearing to about 1,5 to 2 times the regular speed by setting the screen reader to a faster setting, but that still means they are capped at what the average person can achieve.

                                                                  If you provide them with a fast Braille display, that bottleneck disappears and then they can become as fast as regular people, provided that they did put up the required practice.

                                                                  1. 1

                                                                    There’s the thing I don’t understand: how does a Braille display helps you type? You don’t need insane reading speed to process the 120+ words per minute you’re typing. Which would be a very high typing speed, but nevertheless slower than normal speech speed. And screen readers generally are even faster. The only way audio feedback could be too slow to keep up with your typing would be if you’re steno typing.

                                                                    If you’re using a Braille display, you need to move your hands to the keyboard to type, and move them again to read what you just typed. And you can’t do them at the same time. If you’re using an audio feedback, you could hear what you’re typing, without any switching.

                                                                    But I’m speculating here. How does your relative actually write text?

                                                                    1. 4

                                                                      First you’ll need to know that these devices usually provide multiple functions and that some of these Braille displays double as a Braille typewriter while others purely function as displays for computers, which are to be used in combination with a regular keyboard. Take a look at those links, you can get a general idea of what the workflow looks like by just looking at the pictures.

                                                                      If you have a display that also lets you type in Braille, you can simply type out your characters that way and the corresponding characters will appear on the display and in the text file of the document. In this case the thumbs serve as the fingers that can be used for “reading”, just like you would use them to press the space bar, but some people also move their index fingers back an forth.

                                                                      The display-only versions are basically used in a similar fashion and take the place of an RSI palm-rest below the keyboard.

                                                                      The small buttons below the Braille cells are shortcuts which can position your text cursor immediately at that place of the specific character of the cell above so you can edit it. The other buttons are directional d-pads which are used to move the cursor around much like the regular arrow keys on a regular keyboard do, while the other buttons can be used to move through the lines of text on screen in four dimensions like next line, previous line, move contents of display 1 character left/right or move contents of display 40 characters left or right etc.

                                                                      Visually impaired people can obviously touch-type, but that does not mean that they magically make less mistakes than we do. Then there is also the fact that screen-readers often mess up on pronunciation, or are downright incapable of dealing with a lot of edge cases.

                                                                      And there is also the “reading” aspect that these devices enable. A lot of content is available in some form of digital text, but not in audio-book format (although this has gotten a lot better in de last 20 years). With a display like this, you can give a visually impaired person access to the entire internet and just about every webpage (as long as it’s low on JavaScript), text-file, epub or pdf out there.

                                                                      The only real downside to these displays is that that are very expensive (about $3000 - $5000 depending on the version you are using) and that they are simply inaccessible to everyone without proper healthcare insurance.

                                                                      1. 2

                                                                        Okay, looks like the dual keyboard/Braille display is actually a chording keyboard. That kinda changes everything. Thanks for the lesson.

                                                                        1. 1

                                                                          Okay, looks like the dual keyboard/Braille display is actually a chording keyboard. That kinda changes everything.

                                                                          That’s just one of the possible setup you can combine though.

                                                                          Thanks for the lesson.

                                                                          You’re welcome.

                                                              2. 1

                                                                From what I understand, Braille displays are much more common in Europa than the United States.

                                                                1. 2

                                                                  Ah yes, all those braille displays on europa.

                                                                  1. 1

                                                                    I know your reply has a sarcastic undertone, but ironically, you may be right on this one due to the difference in healthcare insurance between Europe and the United States. See my remark above. Funny enough it are American companies that usually produce these displays.

                                                                    1. 4

                                                                      I suspect his reply was a sarcastic way of pointing out that in English, Europa is a moon of Jupiter (and is, as far as we know, not colonized).

                                                              3. 4

                                                                Are the spaces people just now figuring this out?

                                                                Some of us, yes. But that’s privilege for you: you don’t know you’re blinkered until you do.

                                                                1. 4

                                                                  Don’t take this personally. A few hours ago the post was accompanied by a request from the poster which said something along the lines of: “I found this on hacker news, I want to know what reactions this community will provide.”

                                                                  I wrote my reply with that in mind.

                                                                  1. 4

                                                                    Oh, I didn’t, but thanks for clarifying! :)

                                                                    1. 4

                                                                      The text was edited by the moderators; It was not my intention to mislead.

                                                                      1. 2

                                                                        I suspected that much. No offence taken…

                                                                  2. 1

                                                                    Just out of curiousity, in what situations would it be advantageous to look at a hex dump of your source files instead of your source files in textual representation?

                                                                    1. 1

                                                                      I encountered this situation once when I was providing support for a server with a bunch of php scripts on it, where one of the files would not execute properly. It turned out that the file contained an UTF-8 byte order mark that was causing the problem. I discovered this by pushing the file through xxd and I noticed that the sections with spaces were less easy to interpret than the sections with tabs.

                                                                      But I’ll admit, that this is not a situation you will run into often and that I just threw it in because it randomly popped up in my mind.

                                                                  3. 3

                                                                    I have a possible alternative to using tabs: 80 columns: that way you can zoom like crazy and still have a whole line on your screen. My personal projects are 80 columns, because whenever my screen is wide enough, I tend to split it.

                                                                    Might not help with every disability, though.

                                                                    1. 6

                                                                      So, this is a Lobsters discussion about a Reddit discussion. How similar to Hacker News. Look at all of these responses, because everyone gets to share their opinion. Why, this is the most popular article for a ways.

                                                                      Anyway, this isn’t the ’‘real’’ reason to use tabs, but I can understand why someone on Reddit would phrase it that way, since they want points. That’s evident by simply looking back to the teletypes and other machinery they originated from. This is fact.

                                                                      I use languages such as Lisp, which don’t use tabs, because alignment doesn’t adhere to a grid. If you’re using a language that can use tabs, you may want to, however, sure. A language such as Ada tends to use three column indentation and so spaces, but you could use tabs for it.

                                                                      I’ve never heard of this accessibility angle before now, so I’m inclined to disregard it. It’s a minor issue and these people should already have workarounds, because not everyone will accommodate them.

                                                                      1. 2

                                                                        I appreciate the a11y issue, but

                                                                        • i recently worked at a company that used tabs
                                                                        • i created a new repository, and thought i was being hip and modern, so i started to evangelize spaces for the ‘consistency across environments’

                                                                        Isn’t that the real problem? There’s nothing telling me the other users hadn’t simply adapted their set-up to the company’s style. Wouldn’t it be the same story if their editors were set up to render 4- or 8-space indentation as a different number of spaces, and then this person came in and messed that up by inserting tabs everywhere?

                                                                        I don’t actually have a preference [pause for effect]. I don’t think I’ve messed with the default indentation settings in my editors, other than to set visual width = 4 chars. So the files I open could use either tabs or spaces [edit: ambiguity], but in practice I’ve rarely noticed. Text editors understand what indentation is, what the language is, how the file is indented, and what your display preferences are, so why can’t they just deal with it?

                                                                        1. 2

                                                                          Huh. You’ve persuaded me with that blog post. It’s tabs for me from now on.

                                                                          1. 1

                                                                            Accessibility is an interesting and powerful argument for tabs that I have never heard before. I like it!

                                                                            There is still another argument that is not widely discussed, regarding specifically Python. The claim is that tabs allow for better orthogonality of your code and the tools that deal with it. If–for whatever reason–you want to process Python code with standard text processing tools, it becomes much easier if the semantic blocks are determined by a single character, and not by a variable and unknown number of them. If I was bfdl of python it would be determined that, from now on, only tabs are accepted as the valid indentation character for the language, and spaces are forbidden.

                                                                            For other languages like C where spacing has no semantic value I actually tend to prefer 8 spaces.

                                                                            1. 1

                                                                              There are seriously no editor extensions to handle whitespace for this important use case?

                                                                              1. 1
                                                                                1. The problem with tabs is that nearly everyone I know uses them incorrectly. Tabs should be used as indentation only, not always when you want to insert a wide space; this means tabs should be allowed to be used only until first non-white character, never later.

                                                                                2. Sometimes there is a need to first indent the line with tabs, and follow up the indentation with spaces, so that next line matches the indentation of the line above.

                                                                                Those two rules alone make it so hard for people to use tabs, so that I prefer spaces, and I always will advocate spaces over tabs. Using tabs seems to be simply too complicated for lots of people. And everyone is affected by a bad tab-indent.

                                                                                Visually impaired programmers can have additional plug-ins for editors which heuristically detect what indentation style is used, and re-indent the file in the visual part of the editor, without changing the actual indentation style of the file.

                                                                                Needs of visually impaired programmers should be addressed, but I think using tabs for indentation is not the answer, because using tabs alone doesn’t solve any problem, user still needs tooling. And since user needs tooling anyway, we can adapt this tooling further to deal with space indentation.