Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Sunday June 18 2017, @12:22AM   Printer-friendly
from the not-your-bar-tab dept.

Submitted via IRC for TheMightyBuzzard

The annual Stack Overflow developer surveys often include lots of bad news. "People still use PHP," for example, is a recurring and distressing theme. "Perl exists" is another.

But never before has the survey revealed something as devastatingly terrible as the 2017 survey. Using PHP and Perl are matters of taste. Extremely masochistic taste, certainly, but nobody is wrong for using those languages; it's just the programming equivalent of enjoying Adam Sandler movies. But the 2017 survey goes beyond taste; it goes into deep philosophical questions of right and wrong, and it turns out that being wrong pays more than being right.

Developers who use tabs to indent their code, developers who fight for truth and justice and all that is good in the world, those developers have a median salary of $43,750.

But developers who use spaces to indent their code, developers who side with evil and probably spend all day kicking kittens and punching puppies? Their median salary is $59,140.

Source: ArsTechnica


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Informative) by Arik on Sunday June 18 2017, @02:27AM (17 children)

    by Arik (4543) on Sunday June 18 2017, @02:27AM (#527283) Journal
    "If a document has a mix of tabs and spaces, for any reason. It can look fine on one system, and get completely screwed up on another system with a different tab size, which will expand the lines with tabs differently than the lines with spaces, or heaven forbid... lines with some tabs and some spaces."

    You're making a deep conceptual error here - you're thinking of a tab as being identical to the 2 or 4 spaces or whatever that a particular system chooses to use to display them on your screen. They are not. (And if your editor really represents them with nothing more than a certain number of spaces, it's broken, but more on that below.)

    "Now of course, "this should never happen", but it absolutely will, especially with multiple developers using multiple editors ... and since it is whitespace it all looks the same"

    Again, what really matters is not what it looks like (that's an ephemeral quality of the interaction between the character and the particular system you're using to view it) but what it actually is. But even further "whitespace it all looks the same" is either a factual error or an indication your system is broken. Tabs and spaces do NOT look the same, not in any decent editor.

    And they simply are are not the same thing. Spaces separate words. Tabs indent larger blocks of text. Using a number of spaces to simulate a tab is cargo-cult behavior, it's copying the visible form of something with no understanding.

    --
    If laughter is the best medicine, who are the best doctors?
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Informative=1, Total=2
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 0) by Anonymous Coward on Sunday June 18 2017, @05:02AM

    by Anonymous Coward on Sunday June 18 2017, @05:02AM (#527341)

    it's copying the visible form of something with no understanding.
    Tab is a control key. It is a left over from teletype. On the original typewriters where you would pound out a tab it would put out 4/8 spaces (or configurable using tab stops). There was no special char there just a carriage movement. It was space on the original medium. There was no difference. Then came along the teletypes and their special key codes for it. Some fool thought it was a good idea to put the control code in a text file. When you have a choice of two things people will inevitably pick both.

    I personally do not care *which* one you pick. Just be consistent. Do not mix them. If you do 4 spaces then use 4 spaces everywhere, or tabs everywhere. Just be consistent. That is all I ask. Especially if you are in python.

    My projects all use spaces as tabs have had a bad habit of braking compilers for me. 4 different ways of chasing my time in what ended up being a tab instead of a space. That is just me protecting myself against wasted time.

  • (Score: 2) by vux984 on Sunday June 18 2017, @07:36AM (15 children)

    by vux984 (5045) on Sunday June 18 2017, @07:36AM (#527393)

    Oh come of it. There is no deep conceptual error.

    Tabs and spaces do NOT look the same, not in any decent editor.

    They look the same in pretty much all decent editors. sublime, visual studio, notepad++, atom, vim...

    Again, what really matters is not what it looks like but what it actually is.

    I care how it behaves. And that's a function of the editor. A decent editor can emulate tabs using spaces. Backspace will delete spaces to the tabstop. Tab will add spaces to the tabstop. Works fine.

    Actually storing [tab] control characters in the document results in all kinds of portability issues. Why invite that needless hassle. Its not cargo cult behaviour, its rational expediency. We do it because it *actually* works not because it *looks* likes it works. Using tabs as spaces in a decent editor works better than actual tabs thanks to the elimination of portability issues.

    • (Score: 3, Informative) by Arik on Sunday June 18 2017, @07:59AM (13 children)

      by Arik (4543) on Sunday June 18 2017, @07:59AM (#527396) Journal
      "They look the same in pretty much all decent editors. sublime, visual studio, notepad++, atom, vim..."

      I can't comment on the ones I don't use, but notepad++ shows tabs, they look almost like this:

      --->That was a tab.
      --->--->That was two of the buggers.

      But they're in a different color so distinguishable from actually doing that in text. Pretty neat.

      With VIM you have choices! Many. Set list is a simple and straightforward way to choose options here, or you can save time and just install https://github.com/Yggdroot/indentLine

      But again, what's important is not what they look like, but what they are. A space separates words. A tab lines up columns. Calling them 'whitespace' doesn't make them the same thing. A series of LFs (or EOFs) is also 'whitespace' but that doesn't mean you can substitute them for space, or tabs, or vice versa.

      --
      If laughter is the best medicine, who are the best doctors?
      • (Score: 2) by vux984 on Sunday June 18 2017, @04:27PM (12 children)

        by vux984 (5045) on Sunday June 18 2017, @04:27PM (#527513)

        I can't comment on the ones I don't use, but notepad++ shows tabs, they look almost like this:

        A quick skim through google images of notepad++ screenshots suggests almost nobody has that option on. I certainly don't dispute that notepad++ and other editors can do it; I've used that capability myself; but I don't have it on most of the time, and evidently most other people don't either. So most of the time, for most people, they look the same.

        But again, what's important is not what they look like, but what they are.

        Important to who? The compiler doesn't care. You care. I don't. I care how the keys behave; and I usually use editors that are smart enough to emulate tab behavior with spaces. As often as not, after editing some code, I'll just use the editors own reformat to clean up the indentation and make it format pretty. Except for python (and brainfuck) formatting is for the programmer, and it doesn't matter in the slightest whether tabs or spaces are being used 'behind the scenes'. However spaces are a lot more portable.

        A space separates words. A tab lines up columns.

        You might care, but few interpreters or compilers care.

        Calling them 'whitespace' doesn't make them the same thing.

        For most languages, they absolutely are the same thing to the interpreter and compiler. Unless they're inside quotes, of course.

        A series of LFs (or EOFs) is also 'whitespace' but that doesn't mean you can substitute them for space, or tabs, or vice versa.

        a =
              b +
              c;

        callfunc(
            a,
            b,
            c,
            d
        );

        Both compile just fine in most languages.

        As for EOFs they aren't defined as "whitespace" in any common language. For example:

        isspace()
                checks for white-space characters. In the "C" and "POSIX" locales, these are: space, form-feed ('\f'), newline ('\n'), carriage return ('\r'), horizontal tab ('\t'), and vertical tab ('\v').

        https://linux.die.net/man/3/isspace [die.net]

        • (Score: 2) by Arik on Sunday June 18 2017, @06:17PM (11 children)

          by Arik (4543) on Sunday June 18 2017, @06:17PM (#527546) Journal
          "A quick skim through google images of notepad++ screenshots suggests almost nobody has that option on."

          If nearly everyone was jumping off a cliff would you jump too?

          "Except for python (and brainfuck) formatting is for the programmer, and it doesn't matter in the slightest whether tabs or spaces are being used 'behind the scenes'. However spaces are a lot more portable."

          And just exactly how are tabs supposedly less portable? Has there ever been a text encoding that didn't include them?

          "As for EOFs "

          My bad, I meant FFs, and yes, they are "white space." But again, "white space" is not an essential feature of the text, it's a superficial description based on how you've chosen to setup your editor. In the text, these things are all distinct, and if your editor doesn't show them distinctly, well whose fault is that exactly?

          --
          If laughter is the best medicine, who are the best doctors?
          • (Score: 2) by vux984 on Monday June 19 2017, @06:01AM (10 children)

            by vux984 (5045) on Monday June 19 2017, @06:01AM (#527759)

            If nearly everyone was jumping off a cliff would you jump too?

            If someone told me nobody ever jumped off cliffs, looking around and seeing that people were jumping off cliffs all over the place would serve as a rebuttal. You claimed tabs and spaces "looked different". While its true they CAN look different, observationally, very few people use their editors that way, decent or otherwise.

            And just exactly how are tabs supposedly less portable?

            In the same way that CR vs CR/LF issues cause portability issues; despite all text encoding including them as characters. There's no need to be obtuse. Tabs are a control character... they get 'interpreted' by the editor in a way that spaces don't. Spaces generally are treated the same as any letter or number, etc. And the portability issues arise due to the fact that there are many different ways to interpret it in common use.

            it's a superficial description based on how you've chosen to setup your editor

            While spaces are just spaces... I don't need to "setup my editor" to handle them. I don't want to need to 'setup my editor' to handle them.

            • (Score: 2) by Arik on Monday June 19 2017, @11:45AM (9 children)

              by Arik (4543) on Monday June 19 2017, @11:45AM (#527855) Journal
              "If someone told me nobody ever jumped off cliffs"

              I never claimed people don't do stupid things, that's absurd. I'm telling you how not to be stupid.

              "In the same way that CR vs CR/LF issues cause portability issues"

              No, definitely not. CR vs CR/LF is not at all like this. A LF moves the insertion point down a line, while a CR moves it to the beginning of the line. On a typewriter, the return key normally triggered both simultaneously. There were subtly different interpretations of this in early implementations, so some systems expect (and produce) both a CR and a LF at the end of a line, while others expect and produce only a LF or a CR, and that means there is a very simple and straightforward conversion needed when transferring text files from one type of system to another. This issue was solved decades ago and the conversion is normally automatic.

              There is no parallel between that and tabs. Tabs are tabs, regardless of system, there's no extra character that some systems expect and produce in proximity to a tab.

              "I don't want to need to 'setup my editor' to handle them"

              What I hear when I read this is "I don't want to learn to use my tools and I don't want to be competent at my job."

              --
              If laughter is the best medicine, who are the best doctors?
              • (Score: 2) by vux984 on Monday June 19 2017, @02:56PM (8 children)

                by vux984 (5045) on Monday June 19 2017, @02:56PM (#527934)

                I never claimed people don't do stupid things, that's absurd. I'm telling you how not to be stupid.

                It doesn't matter what I do. Tabs vs spaces issues will continue cause problems as long as I have to work with other people. The best solution, in my opinion.

                What I hear when I read this is "I don't want to learn to use my tools and I don't want to be competent at my job."

                I don't know what you think my job is. My job is not to spend time configuring an editor to resolve tabs vs spaces issues in other peoples code. This is an activity that just gets in the way of doing my job. Your attempt at framing this as some sort of competency in which you take pride is comical.

                There is no parallel between that and tabs. Tabs are tabs, regardless of system, there's no extra character that some systems expect and produce in proximity to a tab.

                The parallel is in the special handling the editors have to do deal with the inconsistent usage across platforms. And although it is mostly solved it still crops up now and again.

                This issue was solved decades ago and the conversion is normally automatic.

                Quite so. This is precisely where I propose we should go with the tabs as well. Convert to spaces, let the editor figure it out, do the conversions on legacy documents automatically and invisibly so it doesn't waste our time. And if you want to vary the indent levels at the beginning of lines to suit your aesthetic preference, your editor can render leading spaces on a line wider or narrower to your preference.

                We used to have to manually jump through hoops for CR/LF issues too. When it started happening automatically did you claim it was because people didn't want to learn their tools or be competent? Why is this any different?

                With tabs its like you've got a hammer with a design flaw where the head keeps falling off. I've suggested we correct the flaw so we don't have to waste time putting the hammer back together all the time., and then you turned around and accused me of not wanting to be competent because being able to put your defective hammer back together is somehow your job. Ok... whatever... keep your defective hammer.

                • (Score: 1) by Arik on Monday June 19 2017, @07:12PM (7 children)

                  by Arik (4543) on Monday June 19 2017, @07:12PM (#528091) Journal
                  If your tool is a text editor and you can't be bothered to take ten seconds to figure out how to make it display text accurately and you don't see how that's not wanting to learn to use your tools then there's probably no hope for you.

                  "The parallel is in the special handling the editors have to do deal with the inconsistent usage across platforms."

                  But no, that's not accurate. No one's demonstrated any inconsistent usage across platforms. Because it doesn't exist. (There's inconsistent usage between *persons* yes but not between systems - you're trying to force this to resemble the CR/LF issue even though it does not.)

                  "Quite so. This is precisely where I propose we should go with the tabs as well. Convert to spaces,"

                  Man I'm rolling. You're either dumb as a post or you're doing a great imitation.

                  I've been trying to get someone to simply explain what the problem is and no one seems to be able to do it. I guess I'll have to explain it to you instead.

                  v>Well we have a problem. I think tabs are 3 spaces, this guy I'm working with thinks they are 8 spaces, whenever I get the file back from him it looks crazy on my screen.
                  A>Ok, so you set tabs to show as 3 spaces on your machine, and he has a bigger monitor and thinks it looks better with tabs set at 8, am I understanding you right?
                  v>That's right.
                  A>I still don't see why that's a problem?
                  v>...
                  A>ok, so sometimes he puts in a tab, which lines up fine whether on your screen or his, but sometimes he puts 8 spaces, which looks like it lines up with the tabs on his screen, but does not at all line up with the tabs on yours. Am I getting this right?
                  v>uhuh
                  A>oh and look here, you've been doing the same thing. Sometimes you hit the tab but sometimes you just hit 3 spaces. Same thing on your screen, but I guess he finds it pretty annoying on his end.
                  v>...
                  A>Ok, I see the problem, and here's the solution. Quit misusing spaces! Both of you. Spaces are for separating words, not for indenting.
                  v>I don't like that solution.
                  A>Nonetheless, it's the only logical thing to do. You're only having problems where one or both of you have introduced spaces as a substitute for tabs. There's no need to substitute them, there's no economy to be gained, tabs are not expensive or in short supply. Just use them!
                  v>No, that won't do at all. I know!
                  A...
                  v>I'll convert all the tabs to spaces. That'll solve the problem.

                  At which point A gives up and leaves v to his wallow.

                  --
                  If laughter is the best medicine, who are the best doctors?
                  • (Score: 2) by vux984 on Monday June 19 2017, @09:11PM (6 children)

                    by vux984 (5045) on Monday June 19 2017, @09:11PM (#528151)

                    If your tool is a text editor and you can't be bothered to take ten seconds to figure out how to make it display text accurately

                    Most people don't want that feature on all the time. That's why no editor has it on by default. And few screenshots show it. The only time most people want to explicitly see the whitespace is when they are dealing with a problem with it... otherwise they prefer it off. You think I don't know how to make it display it, but that's not accurate; I know its there, i even use it sometimes but normally: I don't want it on. And I'm in the wide majority here. You are in the small minority if you want it on all the time. And its not because you are more enlightened or because we're all incompetent -- get over yourself.

                    (There's inconsistent usage between *persons* yes but not between systems - you're trying to force this to resemble the CR/LF issue even though it does not.)

                    The parallel holds up fine. The fact that the 'boundary' is by groups of users instead of on operating systems is irrelevant. There is a boundary, and the files get mangled crossing it.

                    I've been trying to get someone to simply explain what the problem is and no one seems to be able to do it. I guess I'll have to explain it to you instead.

                    You only addressed a small part of the problem. First, tabs are not a certain number of spaces. Tab is a control character which says go to the next tab stop. Tab stops are completely arbitrary. You could have them n spaces apart... or in completely arbitrary places. You could have one 30 columns in, the next at 35 columns, then the one after that at 50 columns, etc. That is a completely valid way of handling and defining tab stops. (and defining tab stops in terms of columns is ALSO not right... its properly in terms of a distance unit, so you can line up tabs when using proportional fonts. Almost no one does source code like that though because we generally like column alignment and mono-space fonts make that easier.

                    So, if your editor is defining tabs in terms of how many spaces wide it is "Tab = 8 spaces", then its already only half-assing proper tab implementation.

                    Further, its pretty common to want to write things like:

                    t     = "Fish";   //Type of animal
                    xlen  = 32;       //32 mm long
                    ylen  = 14;       //14 mm wide

                    Setting tabs as simply a width of spaces mangles this every time. THIS is why its better to just convert tabs to spaces and store spaces. There are BETTER ways to to handling different indentation preferences; such as displaying leading spaces on a line at a different width with an editor preference, and doing that will preserve the spacing/formatting in blocks of code like the sample above.

                    A>Ok, I see the problem, and here's the solution. Quit misusing spaces! Both of you. Spaces are for separating words, not for indenting.

                    You saw one problem; but missed the 2nd one.

                    Now, you could argue that the user could indent the line to the first character with tabs, and then do the rest of the intra-line alignment with spaces; but alignment of things like columns to make table-like structures is precisely the reason the tab key, and tab stops were invented; and its a pretty desirable feature. And its a pretty obnoxious restriction to prevent the user from aligning things within lines with tabs and insist he do that with spaces -- that's what TAB stops are FOR. That's why they exist.

                    So... converting tabs to spaces on the fly is a lot more sensible and predictable. You can define tab stops in your editor however you like, and use the tab key to advance to them; and let the editor handle everything else.

                    Now do you understand?

                    • (Score: 2) by Arik on Monday June 19 2017, @09:58PM (5 children)

                      by Arik (4543) on Monday June 19 2017, @09:58PM (#528174) Journal
                      "And I'm in the wide majority here. You are in the small minority"

                      Appeal to popularity.

                      Stooping to such pathetic excuses for logical argument is often taken as a confession that one has no good arguments to make.

                      "There is a boundary, and the files get mangled crossing it."

                      No, that's still not accurate. The files get mangled earlier on. The 'boundaries' as you call it simply make the mangling more obvious to the eye.

                      "You only addressed a small part of the problem. First, tabs are not a certain number of spaces."

                      I'm not going to quote that entire section, but I'm flattered. It looks like you actually did read and understand part of what I wrote. Now quit trying to pretend to explain to me what I just explained to you, that's silly.

                      "t     = "Fish";   //Type of animal
                      xlen  = 32;       //32 mm long
                      ylen  = 14;       //14 mm wide"

                      You see how when I quote this, the initial double quote throws the alignment of the rest of the line off?

                      This is exactly why you should avoid using spaces to fake tabs. Of course, in this case, the text entry field kind of forces us to do that, but it's still a great example to make the point. A tab instead of all those spaces would have preserved the alignment of the '=' signs which is what should happen, but instead, because we've faked it with spaces, we have to repair the fake tab every time the first part of the line has anything added or removed.

                      "So... converting tabs to spaces on the fly is a lot more sensible and predictable."

                      Yeah I'm just rolling again man. You make MY case here, right until it's time for the summation, then without any apparent reason you submit exactly the opposite conclusion.

                      "You can define tab stops in your editor however you like, and use the tab key to advance to them; and let the editor handle everything else."

                      Yes, but not if you have it convert them to spaces!

                      Now do you understand?

                      --
                      If laughter is the best medicine, who are the best doctors?
                      • (Score: 2) by vux984 on Monday June 19 2017, @11:45PM (4 children)

                        by vux984 (5045) on Monday June 19 2017, @11:45PM (#528217)

                        Yeah I'm just rolling again man. You make MY case here, right until it's time for the summation, then without any apparent reason you submit exactly the opposite conclusion.

                        Yeah, my thoughts exactly.

                        Look, unless the tab stop definitions are included with the document, tabs don't work. If it was JUST for indentation purposes then it doesn't really matter, and the editor's user preference is sufficient, but as soon as the document contains any formatting beyond indents (such as the code snippet i provided) then the only thing that works is either spaces, or having the same tab stops defined. I'd be for tabs all the way if tab stops meta data was part of the the standard plaintext document format understood by everything from DOS's edit, to the unix 'more' command, to Sublime and beyond... but its not, and it never will be.

                        "You see how when I quote this, the initial double quote throws the alignment of the rest of the line off?"

                        Yes. And if I'd used tab stops, it might have been "thrown off" even before you put the initial quote in, if your stops were set different. How is that "better" ?? It's not better. You didn't demonstrate anything; except to illustrate the problem. I already know there is a problem.

                        Converting all tabs to spaces on saving the document lets the document move around between systems without getting mangled just by opening it. That solves a problem we already have. And spaces is 'lowest common denominator' ... it'll work with notepad, it'll work with vi, it'll work with edit from DOS6. Source is historically a completely plaintext format, and that's a good thing. I think we can agree we shouldn't violate that tradition.

                        The 2nd problem, of then editing that document and preserving the *behaviour* of tab stops -- I agree that this is desirable. But I think what really needs to happen is smarter editors to reinterpret the that spacing back into tabs and even infer the tab stops from the document formatting. As a human I can look at a document formatted with spaces and infer the tab stops. That's a bit beyond editors stuck in the 90s, but its not beyond us now.

                        In other words...

                        v:"You can define tab stops in your editor however you like, and use the tab key to advance to them; and let the editor handle everything else."
                        A:"Yes, but not if you have it convert them to spaces!"

                        No. EVEN if you convert to spaces. That's my proposal here. Just because they were stored as spaces doesn't mean a decent editor can't be smart about handling the alignment behavior upon loading it; and treating sequences of spaces as tabs, and inferring tab stops from format, etc.

                        • (Score: 1) by Arik on Tuesday June 20 2017, @01:21AM (3 children)

                          by Arik (4543) on Tuesday June 20 2017, @01:21AM (#528276) Journal
                          Well first I want to say if I sometimes come across harsh I'm not trying to be. If I really thought you were a dolt I wouldn't waste this much time on you.

                          "Look, unless the tab stop definitions are included with the document, tabs don't work."

                          We'll call that your thesis.

                          "If it was JUST for indentation purposes then it doesn't really matter, and the editor's user preference is sufficient, but as soon as the document contains any formatting beyond indents (such as the code snippet i provided) then the only thing that works is either spaces, or having the same tab stops defined."

                          And that's an interesting caveat. It IS just for indentation, yes, and using it for something else would create problems of the same sort of nature as we've been describing. You might well get away with using a tab instead of a space in a particular spot in a document on one system, but not in every spot, and when you went to another system with that file there's a good chance your initially invisible error would become apparent.

                          But there is absolutely no need for us to have the same tab stops defined for properly tabbed files to work just fine back and forth between us. Quite the contrary, that's the entire point!

                          To go back to an earlier hypothetical, let's say you have a fairly cramped screen and you set your tab stops at 3 spaces each, to reduce your need to scroll right. I have a big wide monitor that can manage many more readable columns than you, and I set my tab stops at 8 spaces instead. THIS WORKS PERFECTLY FOR BOTH OF US. It only becomes a problem when one of us, either one, starts inserting our preferred number of spaces and expecting that to equal a tab! It could be either one of us but I'll say it's you just for the sake of example. So it's bad enough if you only do this to the areas you rewrite. When I open the file back up I can immediately see what you've done, because it's all scrunched up with these tiny tiny little columns, and I have to go through and fix it. Once I fix it, though, it looks right not only on my screen, but it's also going to look right on your screen when I send it back to you! You get your skinny tabs, I get my fat tabs, everything lines up as it should for both of us, everyone is (or at least should be) happy!

                          But if you go through and 'reformat' it, take out all the tabs and replace each one with three spaces each, well now you're happy but I'm very unhappy. You're seeing the same thing on your screen that you saw when it was done my way, but now I'm stuck with these ridiculously tiny indents. If I replace the tabs with 8 spaces each, you're not going to be any happier with that than I was with three. And if we compromise on 5? Great, now it looks like shit no matter which system you use to look at it.

                          ""You see how when I quote this, the initial double quote throws the alignment of the rest of the line off?"-->Yes. And if I'd used tab stops, it might have been "thrown off" even before you put the initial quote in, if your stops were set different. "

                          I tried very hard to figure out what you could possibly be talking about. The best I can come up with is how you can sometimes cause a minor sort of 'issue' if one person is using very wide tab stops and a lot of text between columns then the next person tries to render with much shorter tab stops. Of course in ideal world there are never any issues but this is really quite minor precisely because it's plain as day when you see that what's happened, and it's extremely easy to fix, and even better, when the person with narrow stops fixes it, that doesn't really break it for the other setup either. But I'll give you that, with some work, we can come up with a few specific situations where we're not completely happy with the results. It still seems very minor compared to the snarls that are caused going the other way.

                          "Converting all tabs to spaces on saving the document lets the document move around between systems without getting mangled just by opening it."

                          Yes, that is both hilarious and true. If you mangle the document when you save it, you can eliminate the need (what need again? we just established there is no need) to mangle it when you open it. Joy.

                          Either way you've got a text where the semantically meaningful tabs have been replaced with meaning-free spaces, which means information has been lost.

                          "And spaces is 'lowest common denominator' ... it'll work with notepad, it'll work with vi, it'll work with edit from DOS6."

                          It only 'works' in a very low meaning as well. In fact, it would be more accurate to say that it does NOT actually work with any of them, and that seems to be why you praise it - because broken everywhere is at least *consistent* isn't that right?

                          "No. EVEN if you convert to spaces."

                          No, no, no. This is a one-way, lossy, conversion. It's simple to reliably convert every tab into however many spaces, but you can't just reverse the transformation because spaces are also used for other things.

                          --
                          If laughter is the best medicine, who are the best doctors?
                          • (Score: 2) by vux984 on Tuesday June 20 2017, @03:21AM (2 children)

                            by vux984 (5045) on Tuesday June 20 2017, @03:21AM (#528315)

                            I wouldn't waste this much time on you.

                            It started off so pleasant... no, not 'pleastant', so ... less unpleasant. But then you said it was a 'waste of time'. Nice :)

                            I tried very hard to figure out what you could possibly be talking about. The best I can come up with is how you can sometimes cause a minor sort of 'issue' if one person is using very wide tab stops and a lot of text between columns then the next person tries to render with much shorter tab stops.

                            Here is a simple example if what I am talking about:

                            Lets say you set tab stops to 8 columns and type:

                            123456[tab][tab]line 1 -- the first tab advances to the 8th postion, the 2nd to the 16th
                            123[tab][tab]line2 -- ditto
                            1[tab][tab]line3 -- ditto
                            123456789[tab]line4 -- only one tab here, but 9 chars in front, so advances to the 16th

                            And you will get two nice neat columns; where the text "Line 1" / "Line 2" / "Line 3" / "Line 4" will all be neatly aligned on column 16.

                            Now I have tab stops set to 3 columns and open your file:

                            123456[tab][tab]line 1 -- the first tab advances to the 9th postion, the 2nd to the 12th
                            123[tab][tab]line2 -- the first tab advances to the 6th position, the 2nd to the 9th
                            1[tab][tab]line3 -- the first tab advances to the 3th position, the 2nd to the 6th
                            1234567890123[tab]line4 -- only one tab here, but 10 chars in front, so advances to 15th

                            Its a complete mess. Instead of 2 neat columns with the 2nd column starting at the 16th position, when I open it, every line of the 2nd column starts somewhere different. And I haven't started editing yet.

                            No, no, no. This is a one-way, lossy, conversion. It's simple to reliably convert every tab into however many spaces, but you can't just reverse the transformation

                            This is where we disagree. I'm not convinced it is as lossy as you think it is. I'm thinking that a bit of document analysis that I could reverse it reliably. After all, I know EXACTLY what the outcome needs to "look like" after i reverse it back to tabs; because a document saved with tabs converted to spaces has everything in the right place. Not only could i reverse the conversion, but I'd be able to tell you what the tab stops were.

                            because spaces are also used for other things.

                            Like what? Other than single spaces as token separators, all other spaces are just formatting and alignment. (insert usual provisos about excluding languages with semantic whitespace, and spaces between quotation marks.)

                            • (Score: 1) by Arik on Tuesday June 20 2017, @04:15AM (1 child)

                              by Arik (4543) on Tuesday June 20 2017, @04:15AM (#528332) Journal
                              "Its a complete mess. Instead of 2 neat columns with the 2nd column starting at the 16th position, when I open it, every line of the 2nd column starts somewhere different. And I haven't started editing yet."

                              Yeah, that's exactly what I came up with. Only it's hardly 'a complete mess' in my eyes, it's obvious at a glance what happened and how to fix it. Tab <down> tab tab <down> tab tab tab and it's done. Nine keystrokes after setting an insertion point, does that even take a full second? The nice thing is this does NOT cause anything to break when I send it back to you. The columns will now align for both of us, and the underlying semantic content did not need to be erased to achieve that outcome.

                              "This is where we disagree. I'm not convinced it is as lossy as you think it is. I'm thinking that a bit of document analysis that I could reverse it reliably. After all, I know EXACTLY what the outcome needs to "look like" after i reverse it back to tabs; because a document saved with tabs converted to spaces has everything in the right place. Not only could i reverse the conversion, but I'd be able to tell you what the tab stops were."

                              I suppose that's possible, if you know a lot about the document beforehand, for instance 'it's a program in python.' Then that might be possible to do. But you'll never know if you get it right. You'll only know if it fails in a manner spectacular enough to get noticed. Why go to extra trouble just to introduce uncertainty?

                              "Like what? Other than single spaces as token separators, all other spaces are just formatting and alignment. (insert usual provisos about excluding languages with semantic whitespace, and spaces between quotation marks.)"

                              If one keeps introducing exceptions and exclusions it's possible to defend a false thesis by simply whittling away at it until the sliver that is left is true.

                              And if you're dealing with a codebase that accepts code contributions from a random crowd of people, the product of varying amounts and quality of education and varying personal ability to think and absorb information, then what you're talking about might well wind up being the best technical solution to that problem. But it would still amount to deliberately breaking every file ahead of time, as a prophylactic - breaking them in a known and controlled fashion to stave off the possibility of un-known and less controlled breakage later on. Workarounds are ok - it's often hard to get things done without them - but there is real danger when the workaround sticks around and you look around and realize one day that none of the new people even realize it IS a workaround - this is the only way they've ever done it and they think it's supposed to be this way. I've seen that happen so many times.

                              Anyway, I don't think that 'text' is completely perfect as is - tab handling is one of the areas where it could actually be improved. But please, improve it at the right level, don't slap a bunch of spaces on top of it like a bandaid and forget about it.

                              This guy has some very interesting thoughs on the subject: http://nickgravgaard.com/elastic-tabstops/

                              --
                              If laughter is the best medicine, who are the best doctors?
                              • (Score: 2) by vux984 on Tuesday June 20 2017, @04:07PM

                                by vux984 (5045) on Tuesday June 20 2017, @04:07PM (#528542)

                                Yeah, that's exactly what I came up with. Only it's hardly 'a complete mess' in my eyes, it's obvious at a glance what happened and how to fix it. Tab tab tab tab tab tab and it's done. Nine keystrokes after setting an insertion point, does that even take a full second? The nice thing is this does NOT cause anything to break when I send it back to you. The columns will now align for both of us, and the underlying semantic content did not need to be erased to achieve that outcome.

                                It was also a 3 line sample. What about a 1000 line sample. What about when there are not just two columns but 3 or 4 or 5. I spend a heck of a lot more time than "one second" fixing stuff like that.

                                I suppose that's possible, if you know a lot about the document beforehand, for instance 'it's a program in python.' Then that might be possible to do. But you'll never know if you get it right. You'll only know if it fails in a manner spectacular enough to get noticed.

                                That's my premise yes. that it can known what the document is, and what it is supposed to look like; so getting it right seems pretty reasonable. And if it fails (how exactly, given it knows what the output needs to be in advance); then the editor would let you roll it back; or provide additional modes/controls ... which a competent user of that editor would know how to use ;) A good enough algorithm... even if it is not perfect, it could be better than the situation we have now.

                                This guy has some very interesting thoughts on the subject: " rel="url2html-7677">http://nickgravgaard.com/elastic-tabstops/

                                That's pretty much what I'm talking about in terms of smart editing; where the editor infers the tabstops from the document structure etc. The theoretical advantage I see to converting to spaces on save and then reversing it is that the document alignment formatting is portable to other editors that aren't as smart.

    • (Score: 0) by Anonymous Coward on Sunday June 18 2017, @08:37AM

      by Anonymous Coward on Sunday June 18 2017, @08:37AM (#527402)

      The GP probably uses Word as its editor. There, spaces look like \cdot, while tabs look like \rightarrow.