"So because apparently some people will inevitable do it wrongly, it's best to just not do it at all? I find this idea completely and utterly weird."
You are the one doing it "wrongly". You are the one that forces solutions like his to get enforced because you think what's convenient for you should be the rule.
"Some people will use this interface in the wrong way, so just throw out the whole shebang?"
The choice is to throw it out of give up on consistent formatting, so yes, throw it out. Not the solution I have chosen on my projects, though. My files contain tabs in a canonical form, 8 spaces per plus space characters to produce the right column. As god intended. To achieve that I wrote a text filter that makes sure the file is right before checkin. Fixes changelog thrashing in the process.
"Which is why the code style guidelines in my projects explain how to use tabs: Tabs for indenting, spaces for alignment."
Your coding style guidelines are written by someone stupid, quite possibly you. If a team effort cares about tabs and spaces in source files, they should have tools that enforce it to prevent thrashing the change logs of their SCCS. That can easily be done and installed in the checkin path. It's 1990 all over again...
Of course, tools like that only actually work when there's a standard tab stop and that's also a standard part of a style guideline. If it's not, the people who write it are incompetent.
Any guideline that allows variable tab stops prevents the use of a whole class of editors. That only works when no one on the team uses such an editor. It also permanently breaks alignment outside the first indent, something you fail to realize.
Explain why you need to "guess" which characters are tabs and which are spaces in the indention area of one of these problem files you speak of?
"Which is of course not always possible, because using spaces for indent *and* alignment is lossy. You are expressing two different concepts with the same character. Which is exactly my fricking point."
You are an idiot. In your bizarro world there is something magical and unique about the first non-whitespace character than makes it's "alignment" different than the alignment of everything else. Perhaps you need to think a little harder. There is no difference between the first alignment and every other alignment.
"You are (probably) not the only person having to deal with the source code."
And perhaps you haven't had to deal with source code nearly enough. There is a set of standards that fix this problem once and for all and they predate you. Some people know what that is. You aren't one of them.
"I sincerly hope you and I are never working on the same codebase together."
That's, of course, because he knows the problem better than you and doesn't appreciate you dumping your crap on his plate.
It seems DrMcCoy needs to be educated, not allowed to continue in his stupidity.
You cannot allow changes in indentation level through the tab character and maintain alignment. Ever.
A tab is a tab AND it is 8 character stops. A tab on the typewriter didn't "type" anything, it just moved the carriage just like the space. Variable tab spacing came later and it did not redefine what a tab was, it only offered flexibility on what it did on THAT machine only. It does not change a tab on the next typewriter over. There it is still 8 characters.
A tab is only useful in a heterogeneous programming environment if it has a standardized meaning. That's the point you can't seem to get.
But if tabs are for indention and spaces are for alignment, as you say, then spaces can only work for alignment for one and ONLY one value of a tab. This is why tab always equal 8; otherwise alignment can ever be achieved.
a tab expands to a tab stop for tab stops that are 8 characters. Any editor that doesn't do that is deviating from the definition of a tab. It's your editor that's bad if you don't understand that. Fine for you inside your own project but if it's causing problems on a team it's your fault for getting tabs wrong.
There is no way EVER that a variable tab width solution can result in things being lined up consistently in code. Narrower tabs do nothing except for you. In order to solve the problem for everyone, you have to standardize on the tab AND we always have. It's 8. Period. No variable tab answer can ever work.
Of course, if everyone on a team sets tabs=4 then it works for everyone on that team, but tabs aren't doing what the naive people here think they do in that case. They only work because they are invariant.
Spaces are "made" just as much for indention as anything else. Tabs aren't "made" for indention any more than spaces are.
There are editors, arguably superior ones depending on your point of view, that treat the tab key as a cursor movement mechanism, just like on a typewriter where they originated, and insert no whitespace on their own. This style of editor can be made to save files with indentions optimized with tabs or purely as spaces. but will only do so with the understanding that a tab is 8 spaces, as it always was since the beginning. Programmers that are ignorant of that concept frequently claim a tab is something else, but that only makes it true in dumb people's editors.
Yes, there are variable tab stops in many devices and have been since before many of use where born. Not all devices support that and, when they don't, their tab stops are fixed at 8. For anyone who cares about interoperability of source files, they MUST assume tabs are 8. There is no other correct answer, and anyone who violates this rule and then complains about diffs and changelogs is a fool.
Tabs and spaces are the same, the only difference is a "tab stop" is 8 and a "space stop" is 1. Spaces could have variable stops too, they just don't. Whether your editor has variable stops is irrelevant to interoperability. Learn to get along, not force your garbage on others. Talk about "bad tools"...
You're the programmer that creates these problems and expects others to conform to your uneducated viewpoint. Learn how a variety of editors work, not just your own.
and you are wrong. Tabs are defined as 8, tabs and spaces can be freely mixed. You want to change your tabstop setting then keep the side effect to yourself. It's not everyone else's burden to compensate for your misunderstanding.
whitespace characters are freely mixable, you just need to learn what you don't understand.
There you go spouting off about diffs and commits again. There is a solution for this, you are just too dumb to realize it.
The laziness on the team is with the ones who insist their view that ignores editors other than there own are the only thing that matters. Programmers are going to use their preferred tools and those tools do things in different ways. If you don't have a process that compensates for those differences then you don't know what you are doing.
A tab is not defined by how people choose to reinterpret it. A tab was originally 8 spaces. Since then, people have claimed the history to be otherwise, it just isn't true.
It doesn't really matter if your editor is the only editor that a file will ever see, but if you care about any other person's editor, you should understand what a tab really is, not just what your editor thinks it is.
Tab isn't a variable indention placeholder, it's a move to the next 8-character column.
"Microsoft started as a developer tools company, and I think they still have a soft spot for it."
WHAT?
Microsoft bought it's way into to developer tools business.
Thanks for the expert opinion on a 6 year old IDE.
Apple does their own chips that contain ARM cores, but they don't design the ARM cores. Apple is in no way in control of the ARM processors in their mobile systems, they are only in control of how they are packaged. They have no ability to introduce ARM as a competitor to x86 on the desktop and it is not simply of matter of clocking one more like a desktop.
"PowerPC originally held promise as a collaboration between Motorola, IBM, and Apple."
PowerPC was not originally a collaboration between those three. It was IBM and Motorola, with IBM providing ALL of the technology. Apple was PowerPC's first customer, they were not a contributor.
With that in mind, it's easy to understand the true meaning of "highly customized" and "for one customer". PowerPC was the Power architecture adapted to PCs, and Apple was the only PC customer. In other words, PowerPC was a failure, IBM/Moto/Freescale wanted to focus on their real market so Apple was left out in the cold. Serves them right, as the PowerPC concept was bogus from the start.
IBM's current line of servers and workstations don't run on PowerPC either. IBM never adandoned their Power line during the PowerPC era. The entire line runs on those processors.
Apple switched because Intel was vastly superior in performance. Nothing else. IBM had long since abandoned PowerPC as a desktop processor and would not commit to doing a PowerPC variant of their current Power design. Since Moto/Freescale sucked, the writing was on the wall.
PowerPC (Power was different at the time) did not provide "media creation" advantages either. There were the Altivec extensions which were not a PowerPC standard anyway, but most of the media creation "advantages" were not from hardware. Even given Altivec, the architectures were not "more-or-less the same". PowerPC languished with derivatives of the 603/604/620 architectures that were created by IBM from the start. By the time IBM made an all-out performance part with the 970/G5, all it proved was that PowerPC was not compelling on the desktop. It was enormously power-hungry as well. Some argument for the power advantages of RISC.;)
"Everyone knows that they are better, but business that stifles investment and progress aka "buy the cheapest" will always keep an older inferior system alive as long as possible."
Everything about this comment is wrong.
x86 won because it proved that RISC vs CISC doesn't matter. All that remains is a bunch of architectures with a legacy of RISC (plus one CISC) where all use similar internal approaches. This solution was arrived at through intense market pressure and tons of research investment on both sides. If it were only what was cheapest, PowerPC would have won out because that was its strategy from the start. They got Apple, everyone else cared more.
Only if that's the only "instruction set" you look at.
It has been decades since the instruction set dictated the internal architecture of the processor. The distinction is irrelevant.
Curiously, RISC is inherently less power efficient than CISC because it requires more space to encode it's operations and therefore requires more memory bandwidth. Of course, that's only if you consider the instruction set. See how stupid the argument is, and how uninformed the article is?
...so let's naively assume that doubling the parity disks for RAID 6 will halve the risk..."
Why assume that when it's grossly in error? If you're going to spend effort teaching us about RAID not being a backup solution, why not put a little effort into getting things right?
Slashdot Mirror
"So because apparently some people will inevitable do it wrongly, it's best to just not do it at all? I find this idea completely and utterly weird."
You are the one doing it "wrongly". You are the one that forces solutions like his to get enforced because you think what's convenient for you should be the rule.
"Some people will use this interface in the wrong way, so just throw out the whole shebang?"
The choice is to throw it out of give up on consistent formatting, so yes, throw it out. Not the solution I have chosen on my projects, though. My files contain tabs in a canonical form, 8 spaces per plus space characters to produce the right column. As god intended. To achieve that I wrote a text filter that makes sure the file is right before checkin. Fixes changelog thrashing in the process.
"Which is why the code style guidelines in my projects explain how to use tabs: Tabs for indenting, spaces for alignment."
Your coding style guidelines are written by someone stupid, quite possibly you. If a team effort cares about tabs and spaces in source files, they should have tools that enforce it to prevent thrashing the change logs of their SCCS. That can easily be done and installed in the checkin path. It's 1990 all over again...
Of course, tools like that only actually work when there's a standard tab stop and that's also a standard part of a style guideline. If it's not, the people who write it are incompetent.
Any guideline that allows variable tab stops prevents the use of a whole class of editors. That only works when no one on the team uses such an editor. It also permanently breaks alignment outside the first indent, something you fail to realize.
Explain why you need to "guess" which characters are tabs and which are spaces in the indention area of one of these problem files you speak of?
"Which is of course not always possible, because using spaces for indent *and* alignment is lossy. You are expressing two different concepts with the same character. Which is exactly my fricking point."
You are an idiot. In your bizarro world there is something magical and unique about the first non-whitespace character than makes it's "alignment" different than the alignment of everything else. Perhaps you need to think a little harder. There is no difference between the first alignment and every other alignment.
"You are (probably) not the only person having to deal with the source code."
And perhaps you haven't had to deal with source code nearly enough. There is a set of standards that fix this problem once and for all and they predate you. Some people know what that is. You aren't one of them.
"I sincerly hope you and I are never working on the same codebase together."
That's, of course, because he knows the problem better than you and doesn't appreciate you dumping your crap on his plate.
It seems DrMcCoy needs to be educated, not allowed to continue in his stupidity.
You cannot allow changes in indentation level through the tab character and maintain alignment. Ever.
A tab is a tab AND it is 8 character stops. A tab on the typewriter didn't "type" anything, it just moved the carriage just like the space. Variable tab spacing came later and it did not redefine what a tab was, it only offered flexibility on what it did on THAT machine only. It does not change a tab on the next typewriter over. There it is still 8 characters.
A tab is only useful in a heterogeneous programming environment if it has a standardized meaning. That's the point you can't seem to get.
But if tabs are for indention and spaces are for alignment, as you say, then spaces can only work for alignment for one and ONLY one value of a tab. This is why tab always equal 8; otherwise alignment can ever be achieved.
Think people!
a tab expands to a tab stop for tab stops that are 8 characters. Any editor that doesn't do that is deviating from the definition of a tab. It's your editor that's bad if you don't understand that. Fine for you inside your own project but if it's causing problems on a team it's your fault for getting tabs wrong.
There is no way EVER that a variable tab width solution can result in things being lined up consistently in code. Narrower tabs do nothing except for you. In order to solve the problem for everyone, you have to standardize on the tab AND we always have. It's 8. Period. No variable tab answer can ever work.
Of course, if everyone on a team sets tabs=4 then it works for everyone on that team, but tabs aren't doing what the naive people here think they do in that case. They only work because they are invariant.
Spaces are "made" just as much for indention as anything else. Tabs aren't "made" for indention any more than spaces are.
There are editors, arguably superior ones depending on your point of view, that treat the tab key as a cursor movement mechanism, just like on a typewriter where they originated, and insert no whitespace on their own. This style of editor can be made to save files with indentions optimized with tabs or purely as spaces. but will only do so with the understanding that a tab is 8 spaces, as it always was since the beginning. Programmers that are ignorant of that concept frequently claim a tab is something else, but that only makes it true in dumb people's editors.
Yes, there are variable tab stops in many devices and have been since before many of use where born. Not all devices support that and, when they don't, their tab stops are fixed at 8. For anyone who cares about interoperability of source files, they MUST assume tabs are 8. There is no other correct answer, and anyone who violates this rule and then complains about diffs and changelogs is a fool.
Tabs and spaces are the same, the only difference is a "tab stop" is 8 and a "space stop" is 1. Spaces could have variable stops too, they just don't. Whether your editor has variable stops is irrelevant to interoperability. Learn to get along, not force your garbage on others. Talk about "bad tools"...
Look who's talking.
You're the programmer that creates these problems and expects others to conform to your uneducated viewpoint. Learn how a variety of editors work, not just your own.
and you are wrong. Tabs are defined as 8, tabs and spaces can be freely mixed. You want to change your tabstop setting then keep the side effect to yourself. It's not everyone else's burden to compensate for your misunderstanding.
whitespace characters are freely mixable, you just need to learn what you don't understand.
There you go spouting off about diffs and commits again. There is a solution for this, you are just too dumb to realize it.
The laziness on the team is with the ones who insist their view that ignores editors other than there own are the only thing that matters. Programmers are going to use their preferred tools and those tools do things in different ways. If you don't have a process that compensates for those differences then you don't know what you are doing.
A tab is not defined by how people choose to reinterpret it. A tab was originally 8 spaces. Since then, people have claimed the history to be otherwise, it just isn't true.
It doesn't really matter if your editor is the only editor that a file will ever see, but if you care about any other person's editor, you should understand what a tab really is, not just what your editor thinks it is.
Tab isn't a variable indention placeholder, it's a move to the next 8-character column.
I've never read an accurate telling of the Dell/Apple story. It wasn't a Dell/Jobs story.
The "ignorant mods" aren't missing anything not having heard the absurd partisan retellings by Apple fanboys.
"Microsoft started as a developer tools company, and I think they still have a soft spot for it." WHAT? Microsoft bought it's way into to developer tools business. Thanks for the expert opinion on a 6 year old IDE.
The stock market is a zero-sum game. Riches can only be gained at "everyone else's expense".
Apple does their own chips that contain ARM cores, but they don't design the ARM cores. Apple is in no way in control of the ARM processors in their mobile systems, they are only in control of how they are packaged. They have no ability to introduce ARM as a competitor to x86 on the desktop and it is not simply of matter of clocking one more like a desktop.
It's easy to say these things when you don't know anything.
"PowerPC originally held promise as a collaboration between Motorola, IBM, and Apple."
PowerPC was not originally a collaboration between those three. It was IBM and Motorola, with IBM providing ALL of the technology. Apple was PowerPC's first customer, they were not a contributor.
With that in mind, it's easy to understand the true meaning of "highly customized" and "for one customer". PowerPC was the Power architecture adapted to PCs, and Apple was the only PC customer. In other words, PowerPC was a failure, IBM/Moto/Freescale wanted to focus on their real market so Apple was left out in the cold. Serves them right, as the PowerPC concept was bogus from the start.
IBM's current line of servers and workstations don't run on PowerPC either. IBM never adandoned their Power line during the PowerPC era. The entire line runs on those processors.
Apple switched because Intel was vastly superior in performance. Nothing else. IBM had long since abandoned PowerPC as a desktop processor and would not commit to doing a PowerPC variant of their current Power design. Since Moto/Freescale sucked, the writing was on the wall.
PowerPC (Power was different at the time) did not provide "media creation" advantages either. There were the Altivec extensions which were not a PowerPC standard anyway, but most of the media creation "advantages" were not from hardware. Even given Altivec, the architectures were not "more-or-less the same". PowerPC languished with derivatives of the 603/604/620 architectures that were created by IBM from the start. By the time IBM made an all-out performance part with the 970/G5, all it proved was that PowerPC was not compelling on the desktop. It was enormously power-hungry as well. Some argument for the power advantages of RISC. ;)
"Yeah, Intel invented microcode again, or a new marketing term for it."
That process is in no way "microcode", though someone totally ignorant on the subject might make that assumption.
Spend a little more time educating yourself and less time telling others how superior RISC is.
"Everyone knows that they are better, but business that stifles investment and progress aka "buy the cheapest" will always keep an older inferior system alive as long as possible."
Everything about this comment is wrong.
x86 won because it proved that RISC vs CISC doesn't matter. All that remains is a bunch of architectures with a legacy of RISC (plus one CISC) where all use similar internal approaches. This solution was arrived at through intense market pressure and tons of research investment on both sides. If it were only what was cheapest, PowerPC would have won out because that was its strategy from the start. They got Apple, everyone else cared more.
Because there is no RISC vs CISC. That left the equation long, long ago. No need for tribalistic nonsense.
Only if that's the only "instruction set" you look at.
It has been decades since the instruction set dictated the internal architecture of the processor. The distinction is irrelevant.
Curiously, RISC is inherently less power efficient than CISC because it requires more space to encode it's operations and therefore requires more memory bandwidth. Of course, that's only if you consider the instruction set. See how stupid the argument is, and how uninformed the article is?
Mac Minis are not fanless designs nor are they silent.
...so let's naively assume that doubling the parity disks for RAID 6 will halve the risk..."
Why assume that when it's grossly in error? If you're going to spend effort teaching us about RAID not being a backup solution, why not put a little effort into getting things right?
That's quite an attitude. What have you done for me lately?