27 Dec, 2008, Lobotomy wrote in the 21st comment:
Votes: 0
But Darien, the internet is serious business! :tongue:
27 Dec, 2008, Omega wrote in the 22nd comment:
Awwwwwwwwwwwwwwwwwwwwwwww…. You got me!
Crazy times! :P
And yeah, it is crazy, like pineapple!
Crazy times! :P
And yeah, it is crazy, like pineapple!
27 Dec, 2008, quixadhal wrote in the 23rd comment:
Lobotomy said:
Arguing against non-standard methods only holds weight when there is an actual negative effect of breaking said standard (the ire of pedants doesn't count). If a particular bit of code is broken in terms of the standard, but all clients provide support that renders the result of the code equal to its standardized counterpart, then that code in fact ceases to be broken. The only way to argue to the contrary is to provide instances or cases of where the non-standard code causes problems. Name a client that doesn't support it. Describe some case or othersuch where output will get screwy in one that does. Just give me something to go on other than mere fussing over what is standard de jure versus what is standard de facto.
Actually, since I've evangelized this bug before, let me get out my soapbox… :)
Here's a very simple example of why using the WRONG line endings screws things up. YEARS ago, I used to play muds all the time at University. In those days, colour was not common, and in fact most of us sat at old vt220 terminals to play. However, I'd moved "up" to higher level classes and thus had access to the Sun workstations, which were of course, colour. Having a fancy new ANSI emulating xterm to use, I wanted to make some triggers in tinyfugue so that "bad things" would get coloured in red, and "good things" would get coloured in green.
For the LIFE of me, I couldn't figure out why the pattern "^You feel sick from .*? poison" wasn't matching. I tried all kinds of combinations, and finally found a way to make it work by removing that leading anchor. If you understand regular expressions, you know that pattern is anchored to the beginning of the line. This makes the patter an order of magnitude more efficient, and back when we had limited CPU power (actual CPU quotas that cost money!), it made a difference that was easily noticable over a few hours of play.
Why didn't it work? Much later, when I started programming MUD's, I figured it out. Every DIKU derivative has inherited the original backwards "\n\r" nonsense that many people stubbornly refuse to accept is wrong. It takes 5 minutes to do a global search and replace across your entire codebase, usually with a tiny handful of manual fixes for places that have multiples in a row, and you're in compliance with the TELNET standard that you're claiming to emulate. FIVE MINUTES!!!!!
Why does it break my regex? Because, a line is defined (by the TELNET standard) as being a sequence of characters, terminated by the sequence CRLF, which is "\r\n" in the C language. If you feed it "\n\r", it fudges the result and assumes the line ends at the LF character. THAT means the NEXT line begins with CR… .so my pattern wouldn't match because the line didn't start with "You", it started with "\rYou".
It would be one thing if it would take a massive effort to bring your code into compliance and do it right… but it's just a simple search and replace. You could use sed, perl, your favorite editor… it took you more time to argue FOR using the wrong pseudo-standard, and it took me more time to argue in favour of fixing it.
I really don't understand why people fight so hard to stick with something that's broken. If it really doesn't matter, what does it hurt you to do it right instead?
27 Dec, 2008, Guest wrote in the 24th comment:
Lobotomy said:
If a particular bit of code is broken in terms of the standard, but all clients provide support that renders the result of the code equal to its standardized counterpart, then that code in fact ceases to be broken.
A certain company formerly run by a man named Bill has operated this way for 25 years, with no regard for standards the company itself helped to create. This has resulted in a number of web developers who spit, gag, and choke at the mere mention of the words "Internet Explorer". Why? Because said company violated the standards. People did indeed eventually consider the brokenness of everything normal, and Bill did very nearly pull off 100% dominance. Until a rogue bunch of pedants rallied together, regrouped their assets, and went on to challenge Bill at his own game. The resulting clash has not been pretty. Many times the great giant in Redmond railed and complained and said "NO! WE ARE THE STANDARD!". Eventually though, because the rogue band of pedants kept being pedantic, the Phoenix did indeed rise from the ashes as Firefox and did steal back 22% of the market that was once very nearly lost. They have done so while advocating nothing more than open source and standards compliance. The beast of Redmond has since been forced to accept that the standards they once threw to the ash pile are here to stay, and IE8 will be far more compliant with them than ever before. Not bad for
Quote
if you ask me :)mere fussing over what is standard de jure versus what is standard de facto
Quote
It takes 5 minutes to do a global search and replace across your entire codebase, usually with a tiny handful of manual fixes for places that have multiples in a row, and you're in compliance with the TELNET standard that you're claiming to emulate. FIVE MINUTES!!!!!
I am Mr. Speedy coder then. That took me all of 68 seconds just now to do on Smaug of old just for kicks…. :P
27 Dec, 2008, Omega wrote in the 25th comment:
Samson, I knew you were quick, but damn ;)
27 Dec, 2008, Lobotomy wrote in the 26th comment:
quixadhal said:
Actually, since I've evangelized this bug before, let me get out my soapbox… :)
Here's a very simple example of why using the WRONG line endings screws things up. YEARS ago, I used to play muds all the time at University. In those days, colour was not common, and in fact most of us sat at old vt220 terminals to play. However, I'd moved "up" to higher level classes and thus had access to the Sun workstations, which were of course, colour. Having a fancy new ANSI emulating xterm to use, I wanted to make some triggers in tinyfugue so that "bad things" would get coloured in red, and "good things" would get coloured in green.
For the LIFE of me, I couldn't figure out why the pattern "^You feel sick from .*? poison" wasn't matching. I tried all kinds of combinations, and finally found a way to make it work by removing that leading anchor. If you understand regular expressions, you know that pattern is anchored to the beginning of the line. This makes the patter an order of magnitude more efficient, and back when we had limited CPU power (actual CPU quotas that cost money!), it made a difference that was easily noticable over a few hours of play.
Why didn't it work? Much later, when I started programming MUD's, I figured it out. Every DIKU derivative has inherited the original backwards "\n\r" nonsense that many people stubbornly refuse to accept is wrong. It takes 5 minutes to do a global search and replace across your entire codebase, usually with a tiny handful of manual fixes for places that have multiples in a row, and you're in compliance with the TELNET standard that you're claiming to emulate. FIVE MINUTES!!!!!
Why does it break my regex? Because, a line is defined (by the TELNET standard) as being a sequence of characters, terminated by the sequence CRLF, which is "\r\n" in the C language. If you feed it "\n\r", it fudges the result and assumes the line ends at the LF character. THAT means the NEXT line begins with CR… .so my pattern wouldn't match because the line didn't start with "You", it started with "\rYou".
It would be one thing if it would take a massive effort to bring your code into compliance and do it right… but it's just a simple search and replace. You could use sed, perl, your favorite editor… it took you more time to argue FOR using the wrong pseudo-standard, and it took me more time to argue in favour of fixing it.
I really don't understand why people fight so hard to stick with something that's broken. If it really doesn't matter, what does it hurt you to do it right instead?
Here's a very simple example of why using the WRONG line endings screws things up. YEARS ago, I used to play muds all the time at University. In those days, colour was not common, and in fact most of us sat at old vt220 terminals to play. However, I'd moved "up" to higher level classes and thus had access to the Sun workstations, which were of course, colour. Having a fancy new ANSI emulating xterm to use, I wanted to make some triggers in tinyfugue so that "bad things" would get coloured in red, and "good things" would get coloured in green.
For the LIFE of me, I couldn't figure out why the pattern "^You feel sick from .*? poison" wasn't matching. I tried all kinds of combinations, and finally found a way to make it work by removing that leading anchor. If you understand regular expressions, you know that pattern is anchored to the beginning of the line. This makes the patter an order of magnitude more efficient, and back when we had limited CPU power (actual CPU quotas that cost money!), it made a difference that was easily noticable over a few hours of play.
Why didn't it work? Much later, when I started programming MUD's, I figured it out. Every DIKU derivative has inherited the original backwards "\n\r" nonsense that many people stubbornly refuse to accept is wrong. It takes 5 minutes to do a global search and replace across your entire codebase, usually with a tiny handful of manual fixes for places that have multiples in a row, and you're in compliance with the TELNET standard that you're claiming to emulate. FIVE MINUTES!!!!!
Why does it break my regex? Because, a line is defined (by the TELNET standard) as being a sequence of characters, terminated by the sequence CRLF, which is "\r\n" in the C language. If you feed it "\n\r", it fudges the result and assumes the line ends at the LF character. THAT means the NEXT line begins with CR… .so my pattern wouldn't match because the line didn't start with "You", it started with "\rYou".
It would be one thing if it would take a massive effort to bring your code into compliance and do it right… but it's just a simple search and replace. You could use sed, perl, your favorite editor… it took you more time to argue FOR using the wrong pseudo-standard, and it took me more time to argue in favour of fixing it.
I really don't understand why people fight so hard to stick with something that's broken. If it really doesn't matter, what does it hurt you to do it right instead?
You misunderstand me. I'm not at all concerned with how simple it is to replace the code in question with the standards-compliant version, nor am I arguing against it. I simply want to hear of actual, practical reasons why it should be done. There is nothing wrong with the point of view that if the two happen to be interchangable that there is no real reason to favor one over the other. What you mention in regards to regex (I'm well aware of regular expressions; give me some credit already, sheesh) is interesting, though. However, I don't like the "this happened years ago" angle. Does the problem you mention still occur today? If so, I'm more interested in hearing about that.
Samson said:
A certain company formerly run by a man named Bill has operated this way for 25 years, with no regard for standards the company itself helped to create. This has resulted in a number of web developers who spit, gag, and choke at the mere mention of the words "Internet Explorer". Why? Because said company violated the standards. People did indeed eventually consider the brokenness of everything normal, and Bill did very nearly pull off 100% dominance. Until a rogue bunch of pedants rallied together, regrouped their assets, and went on to challenge Bill at his own game. The resulting clash has not been pretty. Many times the great giant in Redmond railed and complained and said "NO! WE ARE THE STANDARD!". Eventually though, because the rogue band of pedants kept being pedantic, the Phoenix did indeed rise from the ashes as Firefox and did steal back 22% of the market that was once very nearly lost. They have done so while advocating nothing more than open source and standards compliance. The beast of Redmond has since been forced to accept that the standards they once threw to the ash pile are here to stay, and IE8 will be far more compliant with them than ever before. Not bad for
if you ask me :)
Quote
mere fussing over what is standard de jure versus what is standard de facto
if you ask me :)
I think you've confused Mudbytes with your blog, Samson. :rolleyes:
27 Dec, 2008, Guest wrote in the 27th comment:
Heh. Actually, no, I think what I did was point out that you're arguing against the standards for no valid reason whatsoever. And at the same time pointing out that folks like myself, David, and quixadhal are the nearly wiped out rogue pedants who will one day rise to steal back 22% of the market. Or something.
The simple fact remains, the standard is what it is, and just because Diku did it wrong and influenced everyone after them into doing the same does not make the behavior now right and unworthy of being changed. That's Microsoftian thinking.
A similar situation currently exists with the published standards for MXP and the actual implementation behavior of Zmud. Compared to other clients supporting MXP according to the standards. This has resulted in a number of MXP implementations at the server level which send invalid data causing non-Zmud clients to display things incorrectly.
There was also an example somewhere on smaugmuds.org, can't find the link right now, of the results of the \n\r thing not working properly. It had something to do with the mudprog editor in Smaug and how somehow the user's client was dropping down a line but not returning back to the left. Reversing it in the missed code to \r\n provided the correct behavior and his display while editing mudprogs formatted itself properly. That wasn't "years ago" either. But neither was it "today" as in right now or last week. Which I hardly think changes anything. Wrong is wrong.
The simple fact remains, the standard is what it is, and just because Diku did it wrong and influenced everyone after them into doing the same does not make the behavior now right and unworthy of being changed. That's Microsoftian thinking.
A similar situation currently exists with the published standards for MXP and the actual implementation behavior of Zmud. Compared to other clients supporting MXP according to the standards. This has resulted in a number of MXP implementations at the server level which send invalid data causing non-Zmud clients to display things incorrectly.
There was also an example somewhere on smaugmuds.org, can't find the link right now, of the results of the \n\r thing not working properly. It had something to do with the mudprog editor in Smaug and how somehow the user's client was dropping down a line but not returning back to the left. Reversing it in the missed code to \r\n provided the correct behavior and his display while editing mudprogs formatted itself properly. That wasn't "years ago" either. But neither was it "today" as in right now or last week. Which I hardly think changes anything. Wrong is wrong.
27 Dec, 2008, quixadhal wrote in the 28th comment:
Lobotomy said:
You misunderstand me. I'm not at all concerned with how simple it is to replace the code in question with the standards-compliant version, nor am I arguing against it. I simply want to hear of actual, practical reasons why it should be done.
Go read my posting again, I gave you a concrete example of exactly such a reason. What more do you want? I would say breaking the ability of anyone to do an anchored pattern match on any MUD output is a valid example of [quote-Lobotomy]The only way to argue to the contrary is to provide instances or cases of where the non-standard code causes problems.
If that doesn't qualify, I guess you'll have to detail exactly what you mean by "problems". And yes, I'm sure it does… go write a 5 line perl script to try and match regex output and let me know. I don't know if tinyfugue still has that problem, because (a), I don't PLAY muds enough to do such things and (b), the author might have been forced to add extra code to work around the problem you're trying to help propogate.
27 Dec, 2008, Kline wrote in the 29th comment:
I went and made this change to AckFUSS after post 3 in this thread, before the drama llama fight. Add me to that 22% I guess :P
27 Dec, 2008, David Haley wrote in the 30th comment:
Samson did not confuse MB with his blog in the slightest. He described what eventually happens when people adopt an attitude similar to yours and say "to hell with standards if there are workarounds".
And yes, obviously, these problems still happen today. Go write an HTTP server and look at the crap you have to deal with because people don't generate correct line end sequences. Line end sequences are very important markers and getting them wrong can seriously break how you handle an HTTP request. As a result, you have to play guessing games and detect if the client is using Mac, Unix, Windows, or stupid-reverse-Windows line endings. Then you just hope it stays consistent from then on. Is the code complicated? No, frankly, it's a relatively simple finite state machine that can be captured in some 20 lines of code or less. But it's just another thing you have to deal with.
Telnet has the same issue on the server end to some extent, although fortunately there are fewer stupid telnet clients than there are stupid HTTP clients. Now you have the issue of the server itself sending out broken sequences. If the server starts behaving stupidly, you run into problems like Quix's, where people are trying to match on proper line endings and fail because the server is not sending correct line end sequences.
OK, sure, woohoo, we can all add in our stupid little workarounds to this stupid little problem. We adopt a complacent attitude like "oh, there are workarounds, so I can happily write crappy server code". Next thing we know, every client has to include these workarounds, because more and more servers adopt the same attitude and use non-compliant code.
One of the biggest problems that the MXP standard has is that "some" clients have workarounds for bugs in the server, and so then the server people write crappy code and everything seems to work. But then the same servers talk to correct clients, like MUSHclient, and things break – and people blame MUSHclient even though it is doing the right thing. Of course, introducing these workarounds is actually dangerous and can break other things. Guessing is bad. That's why we have standards.
You might not be aware of the Javascript fiasco between IE and other browsers, but even a cursory reading of the situation should clarify your opinion that introducing workarounds somehow magically fixes broken, crappy code.
You quip that I am not as pragmatic as you once thought. Well, think perhaps that I am in fact far more pragmatic than you are in this instance: I am interested in the whole picture working without having to deal with crap in practice. It is so incredibly easy to fix this problem, and the result would be a saner world for everybody, that it makes no sense whatsoever in practice to willfully deny the standard and cheerfully force ourselves – and everybody else who wants to communicate with us – to deal with the same workarounds.
Practices do not exist just to satisfy pedants or for some merely abstract, principled reason. Standards exist for extremely practical reasons, in the end of the day. I shouldn't have to even say this, but it seems obvious that in a world with lots of people (programs) communicating, you need to agree on your standard for communication. If everybody speaks properly, everything gets a whole lot easier. In pragmatic terms, this means less code to write, less code to maintain, less stupid gotchas to keep in mind.
Tyche cited the "golden rule" of internet programming: be lax in what you accept, be strict in what you send out. Nobody has an excuse to generate non-compliant output. Anybody who does so is guilty of laziness or ignorance (the latter being more forgivable in this case). I don't even know what to say about people who aren't lazy, and who refuse to fix it for some kind of principled reason.
This is probably the last I'm going to say of this. It is stupid to be debating whether or not to break such a trivially easy standard to follow. There is no defensible reason to use LFCR instead of CRLF other than laziness or ignorance. There is no matter of preference.
I apologize again for my tone; as you can tell I really am not happy about people breaking standards just for the heck of it. I am trying to put things as directly as I possibly can.
And yes, obviously, these problems still happen today. Go write an HTTP server and look at the crap you have to deal with because people don't generate correct line end sequences. Line end sequences are very important markers and getting them wrong can seriously break how you handle an HTTP request. As a result, you have to play guessing games and detect if the client is using Mac, Unix, Windows, or stupid-reverse-Windows line endings. Then you just hope it stays consistent from then on. Is the code complicated? No, frankly, it's a relatively simple finite state machine that can be captured in some 20 lines of code or less. But it's just another thing you have to deal with.
Telnet has the same issue on the server end to some extent, although fortunately there are fewer stupid telnet clients than there are stupid HTTP clients. Now you have the issue of the server itself sending out broken sequences. If the server starts behaving stupidly, you run into problems like Quix's, where people are trying to match on proper line endings and fail because the server is not sending correct line end sequences.
OK, sure, woohoo, we can all add in our stupid little workarounds to this stupid little problem. We adopt a complacent attitude like "oh, there are workarounds, so I can happily write crappy server code". Next thing we know, every client has to include these workarounds, because more and more servers adopt the same attitude and use non-compliant code.
One of the biggest problems that the MXP standard has is that "some" clients have workarounds for bugs in the server, and so then the server people write crappy code and everything seems to work. But then the same servers talk to correct clients, like MUSHclient, and things break – and people blame MUSHclient even though it is doing the right thing. Of course, introducing these workarounds is actually dangerous and can break other things. Guessing is bad. That's why we have standards.
You might not be aware of the Javascript fiasco between IE and other browsers, but even a cursory reading of the situation should clarify your opinion that introducing workarounds somehow magically fixes broken, crappy code.
You quip that I am not as pragmatic as you once thought. Well, think perhaps that I am in fact far more pragmatic than you are in this instance: I am interested in the whole picture working without having to deal with crap in practice. It is so incredibly easy to fix this problem, and the result would be a saner world for everybody, that it makes no sense whatsoever in practice to willfully deny the standard and cheerfully force ourselves – and everybody else who wants to communicate with us – to deal with the same workarounds.
Practices do not exist just to satisfy pedants or for some merely abstract, principled reason. Standards exist for extremely practical reasons, in the end of the day. I shouldn't have to even say this, but it seems obvious that in a world with lots of people (programs) communicating, you need to agree on your standard for communication. If everybody speaks properly, everything gets a whole lot easier. In pragmatic terms, this means less code to write, less code to maintain, less stupid gotchas to keep in mind.
Tyche cited the "golden rule" of internet programming: be lax in what you accept, be strict in what you send out. Nobody has an excuse to generate non-compliant output. Anybody who does so is guilty of laziness or ignorance (the latter being more forgivable in this case). I don't even know what to say about people who aren't lazy, and who refuse to fix it for some kind of principled reason.
This is probably the last I'm going to say of this. It is stupid to be debating whether or not to break such a trivially easy standard to follow. There is no defensible reason to use LFCR instead of CRLF other than laziness or ignorance. There is no matter of preference.
I apologize again for my tone; as you can tell I really am not happy about people breaking standards just for the heck of it. I am trying to put things as directly as I possibly can.
27 Dec, 2008, Cratylus wrote in the 31st comment:
DavidHaley said:
It is stupid to be debating whether or not to break such a trivially easy standard to follow. There is no defensible reason to use LFCR instead of CRLF other than laziness or ignorance. There is no matter of preference.
Fascist.
-Crat
27 Dec, 2008, Hades_Kane wrote in the 32nd comment:
I'm convinced.
Converting all of my \n\r to \r\n now…
Converting all of my \n\r to \r\n now…
27 Dec, 2008, Hades_Kane wrote in the 33rd comment:
And… I'm done.
With all of the stacked \n\r\n\r we had in the game, I didn't trust a global replace, so I did a lot of it by hand.
With all of the stacked \n\r\n\r we had in the game, I didn't trust a global replace, so I did a lot of it by hand.
27 Dec, 2008, Lobotomy wrote in the 34th comment:
DavidHaley said:
Samson did not confuse MB with his blog in the slightest.
Obviously. I'm just poking fun at the wholly unnecessary preaching and "MICROSOFT BAD, OPPOSITION GOOD" crap. If I wanted to listen to ranting like that I would just go find a blog to read, like Samson's, hence the joke.
Samson said:
There was also an example somewhere on smaugmuds.org, can't find the link right now, of the results of the \n\r thing not working properly. It had something to do with the mudprog editor in Smaug and how somehow the user's client was dropping down a line but not returning back to the left. Reversing it in the missed code to \r\n provided the correct behavior and his display while editing mudprogs formatted itself properly.
DavidHaley said:
And yes, obviously, these problems still happen today. Go write an HTTP server and look at the crap you have to deal with because people don't generate correct line end sequences. Line end sequences are very important markers and getting them wrong can seriously break how you handle an HTTP request. As a result, you have to play guessing games and detect if the client is using Mac, Unix, Windows, or stupid-reverse-Windows line endings.
Telnet has the same issue on the server end to some extent, although fortunately there are fewer stupid telnet clients than there are stupid HTTP clients. Now you have the issue of the server itself sending out broken sequences. If the server starts behaving stupidly, you run into problems like Quix's, where people are trying to match on proper line endings and fail because the server is not sending correct line end sequences.
Telnet has the same issue on the server end to some extent, although fortunately there are fewer stupid telnet clients than there are stupid HTTP clients. Now you have the issue of the server itself sending out broken sequences. If the server starts behaving stupidly, you run into problems like Quix's, where people are trying to match on proper line endings and fail because the server is not sending correct line end sequences.
What was so hard about bringing that up from the beginning? I just wanted some examples of actual cases where the reverse sequence is still broken. That's all. Good grief, guys. :rolleyes:
27 Dec, 2008, Guest wrote in the 35th comment:
Call be crazy, but seriously, we should have to defend supporting the proper behavior??
27 Dec, 2008, Lobotomy wrote in the 36th comment:
Samson said:
Call be crazy, but seriously, we should have to defend supporting the proper behavior??
In instances where all implementations define support for the improper behavior in addition to the proper behavior, a condition rendering both methods pragmatically equal, yes it does in fact need to be defended as following the standard then becomes a moot point. Illustrating relevant instances where support is lacking for the improper code provides a logical argument for the use of the standard method as it then provides a margin of higher compatibility.
28 Dec, 2008, David Haley wrote in the 37th comment:
Actually, no, not all implementations support both behaviors. Even for those that do, it is usually added after encountering buggy behavior. And as said many times, it is very annoying to have to play these guessing games, and it makes for that much more clutter in the code. If you don't believe me, go write code to correctly support all forms of buggy line ending sequences. Then you can decide how "pragmatically equal" it is to have to support crappy implementations. (You speak as if "pragmatics" doesn't concern the practical implications of having to implement code around this non-conforming behavior…)
28 Dec, 2008, Lobotomy wrote in the 38th comment:
DavidHaley said:
Actually, no, not all implementations support both behaviors.
Yes, DavidHaley, and I just got done agreeing to that point after having finally succeeded in dragging examples of just that very thing out of you - which is what I've been after here from the very start! :mad:
28 Dec, 2008, David Haley wrote in the 39th comment:
Then why are you still talking about "instances where all implementations define support for the improper behavior in addition to the proper behavior"? :wink:
EDIT: ah, I see what you were saying. I still disagree with your willingness to cheerfully break standards when everybody has workarounds for bad code, but we've been over that already.
EDIT: ah, I see what you were saying. I still disagree with your willingness to cheerfully break standards when everybody has workarounds for bad code, but we've been over that already.
28 Dec, 2008, Lobotomy wrote in the 40th comment:
DavidHaley said:
Then why are you still talking about "instances where all implementations define support for the improper behavior in addition to the proper behavior"? :wink:
I was answering Samson's question.
Random Picks
