eEye do sell products, some of which are pretty good.
I couldn't care less. Without details, the security announcement is worse than useless. It's only point is to make money for the people making the announcement.
Sorry Pudge, you're way out of line on this one.
Not remotely, no. This is about proper security procedure. Absolultely no details were provided. The only purpose of the annoucement was to sell a product for the people making the announcement. This is Wrong.
Oh, and Apple already released a patched version, a week or so ago.
Then why the lack of details? And why did the announcement imply there was currently no fix except for their own product? According to you, eEye lied in their announcement, and you're defending them??
And further, it's impossible for this to a "remote execute" vulnerability like the stories based on the extremely vague advisory make it out to be: you can't even talk to iTunes remotely when it's running (unless you have iTunes Sharing enabled, which is available on your local subnet).
Well, not impossible. Go to System Preferences -> Sharing -> Remote Apple Events. Turn it on. Now someone can do pretty much what they want with your system. If they have a valid username/password (or you turned on the Mac OS 9 password... which wouldn't be a security flaw, but part of the design).
I could, for example, do something like:
glue Finder '$g->ADDRESS(eppc => Finder => "your.machine.example.com"); $g->obj(item => 1)->delete'
That would be mean and cruel. And it works over the Internet. And it would also require me to have a username and password on your machine.
And, for what it's worth, eEye will release the "details", whatever they are, after Apple has patched whatever the issue is.
And if they do, I will care at that time. It's the height of irresponsibility to release details in this way. The only point is to scare people into buying their product. And therefore I consider it, until actual details emerge, a malicious hoax.
We don't know the details of the exploit, I can still say with it's extremely likely that it is not something that would be able to spontaneously occur simply by using iTunes in a normal fashion.
I can still say it's extremely likely that there is no exploit or flaw at all. Why would anyone believe it? There's no evidence of any kind that any exploit or flaw exists, at all.
This story would more accurately be: "Some unknown and unannounced flaw found in a piece of software; fix coming from software vendor"
Close, but more accurate still would be: "Some security company trying to drum up business for itself says its product will protect users from a flaw they claim exists, but offer no details or evidence for."
Right. Unions hurt the economy. They are anti-capitalist. They are a terrible idea for everyone involved except for the workers who get to be overpaid and the politicians they've bought.
If there is a serious problem with workers being taken advantage of, then it may be worth it. But that's certainly not the case here.
Sorry, I believe in capitalism too much, and I am not selfish enough, to believe in unionizing programmers. And there's no way in hell I would ever join. And that's the great thing about our industry: I'm not nearly alone. Too many of us are too independent for this to work, because there will always be plenty of us scabs around.
Sorry if this sounds hostile, but to a journalist the shield law is a significant issue.
So? Screw them.
Sorry if this sounds hostile, but to me, shield laws are complete bullshit. And I've worked for large dailies too, and have a degree in journalism.
When sources are not assured *by law* that journalists won't be allowd to keep their sources confidential, they quit talking and as a result government becomes less accountable.
That's like saying if you can't drive 100 mph, you are less likely to get to work on time, which hurts the economy. Most of the time when you drive that fast, you cause a ton of problems. By far, the biggest reason why people consume less mainstream news now is because the journalism profession regularly uses anonymous sources.
If the journalism profession actually had some restraint in its use of anonymous sources, it might get some sympathy on this point. But apart from a few newspapers sprinkled here and there, there is no restraint, and certainly there's none at all in the major news outlets, from Fox to CNN to NYT to WaPo.
But worse, your prediction of doom is clearly false. Tell me, what organization in this country has more anonymous leaks than any other? Easy: the federal government. And guess where there is no shield law protecting anonymous sources? That's right: federal law. There is no federal shield law. And yet we see anonymous sources all over the place, which you say wouldn't exist without a law to protect the journalists who report on them.
I've seen those disregarded quite a bit lately, so where's the benefit?
Can you cite a law that you are referring to that has been disregarded? I highly doubt it.
Can you even cite an example where the law is being disregarded? Again, I doubt it.
Most people seem to think Judith Miller's right to not reveal her source was disregarded. There's a little problem with that line of thinking though: no law recognizes such a right at the federal level, which is where this investigation is taking place. Her right was not disregarded because it didn't exist in the first place.
Shield laws exist only at the state level, and Lugar is trying to "fix" that.
Unforunately, it's a terrible idea, and this is a big part of why: no definition of "journalist" is suitable. And any definition you do come up with makes the journalists themselves beholden to the definers. So an Internet journalist isn't going to give Lugar a hard time, so he will be more likely to include him as a journalist in the legislation. Or maybe we will have Journalism Licenses, and then journalists (or their employers) have to kiss up to some government official who hands them out.
There's no logical reason why a journalist needs special protection. Shield laws are stupid. Journalists are not special citizens deserving of, or in need of, special rights. All citizens should get the same legal protections, and all citizens should have the same legal responsibilities.
The common reasons why the press says they need shield laws are all nonsense, every one of them. The most common these days is that anonymous sources won't talk unless they can get a guarantee of privacy; Good! In the overwhelming majority of cases, anonymous sources are improperly used, and in every single case, cannot be well-trusted anyway.
They say the public has an interest in getting this information; but no, most of the time, your publisher's bank account does, and if it is that important that the public must know information it can't trust anyway because your source won't be revealed, then it is important enough for you to risk jail time, no?
They say without special protection, there may be government backlash; but all citizens should have such protection, if it is necessary. And so on.
Oh, and I have a degree in journalism, so I am not completely talking out my ass.
Maybe I should have said "a few years to muster the courage, then a few months to fight the fight.":-)
But that is a business decision that has nothing to do with code. We knew it would be a committment of a few months' time of a few employees, including the web designer who is not a full-time member of our team.
Would it have been possible to upgrade in parts, such as creating a base stylesheet to handle stuff like fonts and colors and incrementally altering the backend to use it?
Yes, but it would have been suboptimal. Easier to do it all at once, from our perspective. However, that is how we are doing reskeys (the formkey replacement). So far only zoo.pl uses reskeys; everything else still uses formkeys. journal.pl is next.
Also, we did convert all the stories/comments/etc. long before making the switch to CSS. We started making *new* stories/commments/etc. valid HTML 4.01 in the spring, then converted all the old stuff over in August. So while the CSS part was done all at once, the entire project was done in phases.
I understand the reasons you've given for not going to XHTML and won't beat that horse, but if you were decide today that you wanted to, how hard would that be?
Very easy, in theory. Basically we'd need to do two things: modify the templates to produce XHTML instead of HTML (of course), and change a single variable in the code -- which controls whether the comments/stories/journals are HTML or XHTML -- to be true instead of false.
Then of course we would need to convert the old comments/stories/etc., which we already have the code to do, and would take a few days, and as HTML and XHTML are not compatible, we would have a "broken" site in the meantime (though most (all?) clients are smart enough to read XHTML tags as HTML just fine).
That's the main stuff, as far as the code is concerned.
There's a few other things we would have to figure out, though, regarding content types. Like HTTP headers, and whether we should start outputting index.sxhtml instead of index.shtml, etc. That could be a big job, just testing and figuring it all out, but little of it has to do with the code itself.
Not to mention fixing all of the XHTML-specific problems that have little to do with the code (embedding objects, JavaScript, ads, and so on; and making sure there are absolutely no errors in the XHTML, since as you probably know, if the XHTML is not perfectly well-formed, it breaks the entire page, and right now we still have a few HTML errors here and there, some out of necessity).
I love the new CSS layout, truly I do. But the fact that it took a few years to implement it...
No such fact exists, in fact. It took a few months, not a few years.
Had it been built on a solid MVC platform, the project should have taken a couple of days
That's nonsense. The great majority of the time spent on it was two things: making sure the code produced text (comments, stories, and so on) that was valid HTML 4.01 strict (which includes processing all old data), modifying the code to make CSS well-integrated into the system (so that it would play nice with sections and so on), and then actually designing the HTML and CSS. None of that would be eased, or even affected significantly, by whatever MVC platform you wish to conceive of.
(Slash actually does use, essentially, an MVC model, though not religiously; we have significant and pervasive separation, but not complete. But really, very few code changes were required to accomodate the view, except to supply new features to the view [such as the aforementioned automatic stylesheet handling on a per-section basis], so as to make the distinction from true MVC moot for the purposes of the discussion here.)
And even assuming it was just modifying the view (and we could have done it that way, in shorter time, but decided to do it better than that would have allowed): a few days? Obviously you've never worked on such a large system as Slashdot (which is not that large). There are scores of templates that need porting and testing. Just the view part alone is a several-weeks project, assuming you already have the thing perfectly designed, which of course, we didn't, as you make a lot of changes as you go along. You can't just wave a magic wand and turn thousands of lines of crufty HTML 2/3.2 into valid, strict HTML 4.01.
And adding Atom when RSS was already working? That should have been a lunch break project.
Yes, it was minor (though obviously not a mere hour, since code has to be written, tested, and so on). It was a few days going back and forth with one of the core Atom guys, since we had no experience with it. Then another day or two of modifying the code to be able to transparently handle multiple feed types, since 'rss' was hardcoded in a bunch of places. Then more testing, bugfixes, etc. Not to mention integrating it with FeedBurner, who currently handles our feed distribution.
But the original poster said there are no new features being added. I listed three significant ones added in just the last month. I would hope not all of them would take a long time to do, else they'd not have all been added in September...
Right, so like I said, the only people who say Slash has some of the worst perl code ever written don't know perl, or Slash. As you've not looked at the code in about five years, it's quite true that you don't know Slash.
Huh. Just in the last month alone, we've seen the addition of support for CSS and Atom, and the beginnings of a brand-new replacement for formkeys (called reskeys). And that's just September. So, um... no.
is widely known to have some of the worst perl code ever written
Only among people who don't know perl, or Slash.
is grossly underdocumented...
True enough.
But the last thing being true does not remedy the fatal flaws in the other two assertions, which prove you to be quite ignorant about the subject.
We already forced HTML 4.01 strict compliance on comments six months ago. Almost no one noticed.
We already converted 13M comments to valid HTML 4.01 strict. A couple of months ago. No one noticed.
It would be relatively trivial to force XHTML 1.0 strict compliance. I'd flip a switch to force compliance on new content, then rerun the converter for old content. The code's been tested to work for both HTML 4.01 strict and XHTML 1.0 strict (since we allow only a relatively small subset of HTML tags and attributes, this isn't that hard for comments, or even stories, which allows a lot more variety in tags, but everything still fits in the intersection of the two, so it's just a matter of changing a very few number of things, that the code already knows about).
In what way is writing xhtml harder than writing html 4.01?
If HTML is not perfect, it will still display just fine. If XHTML is not perfect, nothing will be displayed, except your XML errors.
Unless, of course, your XHTML is being rendered as HTML, not XML, in which case why are you doing XHTML at all?
Re:Not according to W3C html validity checker...
on
Slashdot HTML 4.01 and CSS
·
· Score: 3, Informative
There is no reason to go to XHTML. Bottom line: most browsers will render it as HTML and not XML, and for those that do render it as XML, we would need to have *perfectly valid* XML or else it would break, and we are not yet at that point, as we still have various invalid things in our source. So there's no reason to bother, not any time soon.
The code can easily handle a switch to XHTML 1.0 Strict, should we someday desire to do that.
This was done awhile ago, and almost no one noticed.
Basically, we were allowing various things in comments for years that were not compliant with HTML 4.01 strict. Even moreso for stories. So about six months ago we fixed the code to force compliance with HTML 4.01 strict, and about two months ago converted old content accordingly.
Well, according to you. Can you name a C coding style that according to you gives you significant gains over the standard K&R style? That's the question posed in the article.
Maybe, maybe not. But what I do know is that I could give just as strong a defense that we do not need multiple OSes or programming languages. And don't fool yourself into thinking I can't.
Aha! The same form, and now we have ASCII trumping EBCDIC, which was a good thing
Straw man. I never implied that the form was wrong because its results were poor, but because the log of the form is, as it can be used to discredit any variance at all.
Those aren't parallel. There could be operating systems and programming languages with much greater benefits than those we currently/commonly use. Linux vs. Windows. Python and Ruby vs. C. How many significantly better-than-normal ways are there of formatting programs?
Premise 1: For any given hardware, there are one or a few common coding operating systems.
Premise 2: There is not now, nor will there ever be, an operating system whose benefit is significantly greater than any of the common operating systems. Premise 3: Approximately a gaboozillion cycles are spent on dealing with OS variations. Premise 4: For any non-trivial project, a common OS is a good thing. Conclusion: Thinking of all the code in the entire world as a single "project" with a single OS, we would get more value than we do by allowing for variations in operating systems.
Premise 1: For any given OS, there are one or a few common coding languages. Premise 2: There is not now, nor will there ever be, a programming language whose benefit is significantly greater than any of the common languages. Premise 3: Approximately a gaboozillion cycles are spent on dealing with language variations. Premise 4: For any non-trivial project, a common language is a good thing. Conclusion: Thinking of all the code in the entire world as a single "project" with a single language, we would get more value than we do by allowing for variations in languages.
And so on. This is really an intensely silly idea.
Slashdot Mirror
If you're talking about iDwefence
Why would I be doing that?
eEye do sell products, some of which are pretty good.
I couldn't care less. Without details, the security announcement is worse than useless. It's only point is to make money for the people making the announcement.
Sorry Pudge, you're way out of line on this one.
Not remotely, no. This is about proper security procedure. Absolultely no details were provided. The only purpose of the annoucement was to sell a product for the people making the announcement. This is Wrong.
Oh, and Apple already released a patched version, a week or so ago.
Then why the lack of details? And why did the announcement imply there was currently no fix except for their own product? According to you, eEye lied in their announcement, and you're defending them??
Pull the other one!
So you believe something without evidence just because if they are not telling the truth, they might get in trouble?
Oooooooooo K.
Indeed. If this is what they mean -- which I doubt, but then again, I also doubt they have a real flaw here anyway -- it would not be a flaw.
Well, not impossible. Go to System Preferences -> Sharing -> Remote Apple Events. Turn it on. Now someone can do pretty much what they want with your system. If they have a valid username/password (or you turned on the Mac OS 9 password
I could, for example, do something like: That would be mean and cruel. And it works over the Internet. And it would also require me to have a username and password on your machine.
And, for what it's worth, eEye will release the "details", whatever they are, after Apple has patched whatever the issue is.
And if they do, I will care at that time. It's the height of irresponsibility to release details in this way. The only point is to scare people into buying their product. And therefore I consider it, until actual details emerge, a malicious hoax.
We don't know the details of the exploit, I can still say with it's extremely likely that it is not something that would be able to spontaneously occur simply by using iTunes in a normal fashion.
I can still say it's extremely likely that there is no exploit or flaw at all. Why would anyone believe it? There's no evidence of any kind that any exploit or flaw exists, at all.
This story would more accurately be: "Some unknown and unannounced flaw found in a piece of software; fix coming from software vendor"
Close, but more accurate still would be: "Some security company trying to drum up business for itself says its product will protect users from a flaw they claim exists, but offer no details or evidence for."
It would take five people to do it, therefore it is impossible! Um, unless you have five people. Or less, if they are stronger than average people.
So in other words, it is possible.
If they are saying that the book of Gensis is nothing more that a fictional tale about how the universe was created
They aren't.
Yes, but like most pimps who slap bitches, Galloway was totally full of shit when he did it.
Right. Unions hurt the economy. They are anti-capitalist. They are a terrible idea for everyone involved except for the workers who get to be overpaid and the politicians they've bought.
If there is a serious problem with workers being taken advantage of, then it may be worth it. But that's certainly not the case here.
Sorry, I believe in capitalism too much, and I am not selfish enough, to believe in unionizing programmers. And there's no way in hell I would ever join. And that's the great thing about our industry: I'm not nearly alone. Too many of us are too independent for this to work, because there will always be plenty of us scabs around.
Sorry if this sounds hostile, but to a journalist the shield law is a significant issue.
So? Screw them.
Sorry if this sounds hostile, but to me, shield laws are complete bullshit. And I've worked for large dailies too, and have a degree in journalism.
When sources are not assured *by law* that journalists won't be allowd to keep their sources confidential, they quit talking and as a result government becomes less accountable.
That's like saying if you can't drive 100 mph, you are less likely to get to work on time, which hurts the economy. Most of the time when you drive that fast, you cause a ton of problems. By far, the biggest reason why people consume less mainstream news now is because the journalism profession regularly uses anonymous sources.
If the journalism profession actually had some restraint in its use of anonymous sources, it might get some sympathy on this point. But apart from a few newspapers sprinkled here and there, there is no restraint, and certainly there's none at all in the major news outlets, from Fox to CNN to NYT to WaPo.
But worse, your prediction of doom is clearly false. Tell me, what organization in this country has more anonymous leaks than any other? Easy: the federal government. And guess where there is no shield law protecting anonymous sources? That's right: federal law. There is no federal shield law. And yet we see anonymous sources all over the place, which you say wouldn't exist without a law to protect the journalists who report on them.
So, you wanna take that back?
I've seen those disregarded quite a bit lately, so where's the benefit?
Can you cite a law that you are referring to that has been disregarded? I highly doubt it.
Can you even cite an example where the law is being disregarded? Again, I doubt it.
Most people seem to think Judith Miller's right to not reveal her source was disregarded. There's a little problem with that line of thinking though: no law recognizes such a right at the federal level, which is where this investigation is taking place. Her right was not disregarded because it didn't exist in the first place.
Shield laws exist only at the state level, and Lugar is trying to "fix" that.
Unforunately, it's a terrible idea, and this is a big part of why: no definition of "journalist" is suitable. And any definition you do come up with makes the journalists themselves beholden to the definers. So an Internet journalist isn't going to give Lugar a hard time, so he will be more likely to include him as a journalist in the legislation. Or maybe we will have Journalism Licenses, and then journalists (or their employers) have to kiss up to some government official who hands them out.
There's no logical reason why a journalist needs special protection. Shield laws are stupid. Journalists are not special citizens deserving of, or in need of, special rights. All citizens should get the same legal protections, and all citizens should have the same legal responsibilities.
The common reasons why the press says they need shield laws are all nonsense, every one of them. The most common these days is that anonymous sources won't talk unless they can get a guarantee of privacy; Good! In the overwhelming majority of cases, anonymous sources are improperly used, and in every single case, cannot be well-trusted anyway.
They say the public has an interest in getting this information; but no, most of the time, your publisher's bank account does, and if it is that important that the public must know information it can't trust anyway because your source won't be revealed, then it is important enough for you to risk jail time, no?
They say without special protection, there may be government backlash; but all citizens should have such protection, if it is necessary. And so on.
Oh, and I have a degree in journalism, so I am not completely talking out my ass.
Maybe I should have said "a few years to muster the courage, then a few months to fight the fight." :-)
But that is a business decision that has nothing to do with code. We knew it would be a committment of a few months' time of a few employees, including the web designer who is not a full-time member of our team.
Would it have been possible to upgrade in parts, such as creating a base stylesheet to handle stuff like fonts and colors and incrementally altering the backend to use it?
Yes, but it would have been suboptimal. Easier to do it all at once, from our perspective. However, that is how we are doing reskeys (the formkey replacement). So far only zoo.pl uses reskeys; everything else still uses formkeys. journal.pl is next.
Also, we did convert all the stories/comments/etc. long before making the switch to CSS. We started making *new* stories/commments/etc. valid HTML 4.01 in the spring, then converted all the old stuff over in August. So while the CSS part was done all at once, the entire project was done in phases.
I understand the reasons you've given for not going to XHTML and won't beat that horse, but if you were decide today that you wanted to, how hard would that be?
Very easy, in theory. Basically we'd need to do two things: modify the templates to produce XHTML instead of HTML (of course), and change a single variable in the code -- which controls whether the comments/stories/journals are HTML or XHTML -- to be true instead of false.
Then of course we would need to convert the old comments/stories/etc., which we already have the code to do, and would take a few days, and as HTML and XHTML are not compatible, we would have a "broken" site in the meantime (though most (all?) clients are smart enough to read XHTML tags as HTML just fine).
That's the main stuff, as far as the code is concerned.
There's a few other things we would have to figure out, though, regarding content types. Like HTTP headers, and whether we should start outputting index.sxhtml instead of index.shtml, etc. That could be a big job, just testing and figuring it all out, but little of it has to do with the code itself.
Not to mention fixing all of the XHTML-specific problems that have little to do with the code (embedding objects, JavaScript, ads, and so on; and making sure there are absolutely no errors in the XHTML, since as you probably know, if the XHTML is not perfectly well-formed, it breaks the entire page, and right now we still have a few HTML errors here and there, some out of necessity).
I love the new CSS layout, truly I do. But the fact that it took a few years to implement it ...
...
No such fact exists, in fact. It took a few months, not a few years.
Had it been built on a solid MVC platform, the project should have taken a couple of days
That's nonsense. The great majority of the time spent on it was two things: making sure the code produced text (comments, stories, and so on) that was valid HTML 4.01 strict (which includes processing all old data), modifying the code to make CSS well-integrated into the system (so that it would play nice with sections and so on), and then actually designing the HTML and CSS. None of that would be eased, or even affected significantly, by whatever MVC platform you wish to conceive of.
(Slash actually does use, essentially, an MVC model, though not religiously; we have significant and pervasive separation, but not complete. But really, very few code changes were required to accomodate the view, except to supply new features to the view [such as the aforementioned automatic stylesheet handling on a per-section basis], so as to make the distinction from true MVC moot for the purposes of the discussion here.)
And even assuming it was just modifying the view (and we could have done it that way, in shorter time, but decided to do it better than that would have allowed): a few days? Obviously you've never worked on such a large system as Slashdot (which is not that large). There are scores of templates that need porting and testing. Just the view part alone is a several-weeks project, assuming you already have the thing perfectly designed, which of course, we didn't, as you make a lot of changes as you go along. You can't just wave a magic wand and turn thousands of lines of crufty HTML 2/3.2 into valid, strict HTML 4.01.
And adding Atom when RSS was already working? That should have been a lunch break project.
Yes, it was minor (though obviously not a mere hour, since code has to be written, tested, and so on). It was a few days going back and forth with one of the core Atom guys, since we had no experience with it. Then another day or two of modifying the code to be able to transparently handle multiple feed types, since 'rss' was hardcoded in a bunch of places. Then more testing, bugfixes, etc. Not to mention integrating it with FeedBurner, who currently handles our feed distribution.
But the original poster said there are no new features being added. I listed three significant ones added in just the last month. I would hope not all of them would take a long time to do, else they'd not have all been added in September
Of course, that was slashcode 1.x ...
Right, so like I said, the only people who say Slash has some of the worst perl code ever written don't know perl, or Slash. As you've not looked at the code in about five years, it's quite true that you don't know Slash.
Slashcode has seen near zero feature additions
... no.
Huh. Just in the last month alone, we've seen the addition of support for CSS and Atom, and the beginnings of a brand-new replacement for formkeys (called reskeys). And that's just September. So, um
is widely known to have some of the worst perl code ever written
Only among people who don't know perl, or Slash.
is grossly underdocumented...
True enough.
But the last thing being true does not remedy the fatal flaws in the other two assertions, which prove you to be quite ignorant about the subject.
We already forced HTML 4.01 strict compliance on comments six months ago. Almost no one noticed.
We already converted 13M comments to valid HTML 4.01 strict. A couple of months ago. No one noticed.
It would be relatively trivial to force XHTML 1.0 strict compliance. I'd flip a switch to force compliance on new content, then rerun the converter for old content. The code's been tested to work for both HTML 4.01 strict and XHTML 1.0 strict (since we allow only a relatively small subset of HTML tags and attributes, this isn't that hard for comments, or even stories, which allows a lot more variety in tags, but everything still fits in the intersection of the two, so it's just a matter of changing a very few number of things, that the code already knows about).
In what way is writing xhtml harder than writing html 4.01?
If HTML is not perfect, it will still display just fine. If XHTML is not perfect, nothing will be displayed, except your XML errors.
Unless, of course, your XHTML is being rendered as HTML, not XML, in which case why are you doing XHTML at all?
There is no reason to go to XHTML. Bottom line: most browsers will render it as HTML and not XML, and for those that do render it as XML, we would need to have *perfectly valid* XML or else it would break, and we are not yet at that point, as we still have various invalid things in our source. So there's no reason to bother, not any time soon.
The code can easily handle a switch to XHTML 1.0 Strict, should we someday desire to do that.
This was done awhile ago, and almost no one noticed.
Basically, we were allowing various things in comments for years that were not compliant with HTML 4.01 strict. Even moreso for stories. So about six months ago we fixed the code to force compliance with HTML 4.01 strict, and about two months ago converted old content accordingly.
Are you trying to say there are no quantifiable differences in benefits?
No. I am saying I can quantify the benefits of a language style as easily as you can quantify the benefits of a language or OS.
I can't believe you think that all OS's and all languages are the same in performance. That's just dumb.
Well, it's a good thing I never stated or implied that, or else I'd feel bad right now!
Well, according to you. Can you name a C coding style that according to you gives you significant gains over the standard K&R style? That's the question posed in the article.
Maybe, maybe not. But what I do know is that I could give just as strong a defense that we do not need multiple OSes or programming languages. And don't fool yourself into thinking I can't.
Aha! The same form, and now we have ASCII trumping EBCDIC, which was a good thing
Straw man. I never implied that the form was wrong because its results were poor, but because the log of the form is, as it can be used to discredit any variance at all.
Those aren't parallel. There could be operating systems and programming languages with much greater benefits than those we currently/commonly use. Linux vs. Windows. Python and Ruby vs. C. How many significantly better-than-normal ways are there of formatting programs?
According to whom?
And there's your answer.
Q.E.D.
Yes, I didn't mean to imply they hadn't, just that this was another one.