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: 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?
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (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.