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: 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.