Riddle: What's the lowest number you can be guranteed of an int holding? char? What's the guranteed range of a char?
If you answered negative 2 billion something, you're wrong.
If you answered -32768, you're wrong. While I am unaware of any implementation that doesn't allow you to have an int of -32768, it's not guranteed. The range of an int is only guranteed to be at least -32767 to 32767.
Range of a signed char is -127 to 127.
And the guranteed range of a char is 0 to 127.
Yet these ranges are usually changed.
What's the size of an int? Might be 2 bytes. Might be 4 bytes. If you have a 64 bit machine, it could probably legally be 8 bytes. Is this a problem?
In fact, what's the size of a normal pointer? You don't know!
Of all the things you could complain about member pointers, it being an unpredictable size is NOT one of them.
It wasn't a matter of choosing the keywoard that was a problem; I'm sure that he would have thought that either pure or abstract would have been splendid.
It's just that if he chose a keyword, it would either have to be one that was already in use (in which case you get just as akward a syntax) or something that, probably, someone was using as an identifier somewhere.
You add a keyword to a language and bam, suddenly you break code. Not breaking code unless absolutely necessary was a primary goal of Stroustrup when he was writing C++, so he went with an obscure syntax that didn't break code rather than a nicer syntax that did.
There's another part of D&E where he says pretty much that about keywords in general.
(If you want another example of when this happened, I think the crazy syntax for differentiating between the prefix and postfix increment and decrement operators came about very similarily.)
No, in sum, the argument went "I didn't want to piss off anyone in my user base that was using pure or abstract as an identifier somewhere, so I chose a syntax that, while a bit obscure, didn't break existing code."
If you'd investigate and read D&E instead of making sarcastic remarks, you'd learn that not breaking existing code -- C code, even, let alone existing C++ code -- was one of the primary goals.
i have NEVER needed or honestly wanted to use the keyword 'friend'
I have. In fact, just a couple weeks ago I expressed my angst at a coworker that Java didn't have friend. Know why? JUnit tests.
There are essentially three ways to structure JUnit tests: 1. Entirely separate from the code that's being tested. This is how we have our project set up. Part of our directory structure is:
/src
|---/src/java
| |---/src/java/com...
| (.java files go here)
|---/src/test/...
(JUnit tests go here)
2. JUnit tests in the same package as what they are testing
3. JUnit tests in the same class they are testing
I would very strongly argue that those options are listed it order of decreasing desirability from a design perspective. Unit tests shouldn't ship with the final project and are logically different, so they should be separated.
However, moving down the list brings benefits: you can test more. With option 1, you can only test public methods. With option 2, you can test public and protected methods. With option 3, you can test all methods.
If Java had friend methods, it would be possible to say that everything in the JUnit tests is a friend. Now voila, they can access (and thus test) private members while you still keep them separate.
Granted, it's not a perfect solution, as you still need the friend statements, but it's still better than anything else I see.
BTW, if anyone knows a better way to do this, let me know. We're all pretty new (all interns working very much on our own amongst people who tell us we're the resident Java experts) at this.
I thought we were staying with C++ because of all the code that's already written in it......then this story changes nothing. That's the nature of an addition to the language, they'll be very careful to not break any code. They might depricate a few features (I haven't yet read the article in question, but I've seen a few others in the past, and one feature that some are pushing to depricate are (type) expression and type(expression) style casts), etc., but if any of the changes break existing code, the broken code will be very rare and either poorly written or easy to fix.
Maintaining backwards compatability has been a hallmark of the development of C++ from the beginning, and is the reason for some of the more opaque syntax forms. (For instance, rather than add a new keyword (not even that major a change to existing code) for pure virtual functions, Strostrup came up with the foo() = 0; syntax.)
I'll be the first person blubbering about how using a Swing program is only slightly less painful than drinking a pan-galactic gargle blaster, how metal looks like someone took a dump on the screen, etc., but Eclipse is very nice to use.
If Sun were to drop Swing and pick up SWT I think they would see results very quickly.
I'm going to have to seriously consider Java and SWT as an option for any programs I do that I want to be cross platform, and to say that I find programming in Java less than pleasurable is about accurate.
The problem with C++ is that is was built with focus purely on technology and seemingly without any effort to human factors at all
Actually, if you look into it I think you'll find that a lot of design decisions were made with the design of compilers in mind. Maybe not simple stuff like the >> as a token problem, but a lot more.
I mean come on, "::" to separate class from method name
What's wrong with that? It's probably because I used it first, but I prefer:: to Java's.
Besides, if you're trying to defend Java, would you like a list of about a dozen syntactic disadvantages of Java over C++?...separate interface and implementation files...
First, I must say I still prefer the C++ approach to the Java/C# one file approach. Want to look up a function? It's easy... you don't have to wade through implementation crap you don't care about. Sure, if the programmer was nice in Java you'll have an interface you're looking at, but programmers are not always nice. (I realize this is significantly less of a problem with an IDE that will present you with a list of the members.)
Second, want a single implementation and interface file in C++? Great. Write one. C++ lets you.
Third, it's the easiest way to allow people to distribute binaries without source while still maintaining C++'s increased compile-time type safety over Java.
with operator overloading it is impossible to know what a C++ code is doing (ie, cin >> s, shift right or method call?).
No it isn't, not any more impossible than it is with Java. Is cin or s an object? Then you have a call to an overloaded operator. (Okay, C++ allowing automatic conversions muddles things somewhat, but I'd still kill someone to get operator overloading in Java. It cleans up a LOT more than it muddles.)
"Yes, you might make sme goofs on whichever keyboard you're not using full time."
I'm not even sure it's that dire a circumstance. When I'm on qwerty, I don't think I make any more typos than I did before I started using Dvorak.
For me, the only effects I've noticed is typing the first few words in the wrong layout immediately after switching and having to delete them.
(Windows's treatment of layouts exacerbates this problem because it keeps the active layout on a per-application instead of a system-wide basis, so you'll be typing along happily, change windows, and BAM, you're in the opposite layout. There have been many times when I've been appreciative of the way it does things, but overall I think it causes more headaches than it solves.)
The benefit of Dvorak, of course, is that on most computers you can sit down and within a minute or so change the keyboard layout and have a Dvorak keyboard. I've yet to see a software switch that will morph your keyboard like that.
Any parent whose kid is THAT eager to read a book--any book--should be encouraged, even if it's staying up late on a summer night.
Fully agreed!
What's staying up late gonna do to them? Make them tired? Oh no, so they'll just sleep in later. It's summer; it's not like they have to be at work or school.
The only problem I could see is if both parents worked and the kid had to be at day care or something.
Or they could, of course, adapt to the situation and offer services that the big chains don't (such as stocking books from smaller publishers that the big chains won't stock by default).
Won't work; people are too eager to save a couple bucks. Even I, who values local stores, would special order a book from B&N before getting it from a small bookseller if it'd save me more than a couple bucks.
Look at all the people who shop at Wal-Mart. I have yet to find one thing they offer besides cheap prices. I was in there looking for 100 speed film (one of three or so times I've been in a Wal-Mart this year, because I couldn't get anywhere else) and after asking two employees working at the photo counter if they sold "100 film" (I didn't see any on the shelf) I was told that no, they didn't sell 100 film, but had 110 right over there on the shelf. I promptly grabbed a box of 200 and skedattled my way out of there.
Most of the companies making money off of GPL "software" though aren't making it off of the software, they're making it off of enterprise support contracts. If you want to provide support, go ahead and do so, but if you want to sell software, it's very difficult to do if you're selling it open source.
(Ironically, it's less difficult if it's GPL, because then you can dual license.)
I'm not sure this is as clear cut as you think though. I can make an argument that the GPL is bad for consumers:
1. First, I assume that the number of companies who are writing GPL code but wouldn't be if all OSS was under a BSD license is small. I don't know if this is a valid assumpition or not, but it seems to me that a company would be either willing to release their work as open source or they wouldn't, and the boundary, where being able to use existing GPL code would make the difference, would be small. (I'm sure there are exceptions, I mean you hear about the occasional case where a company opens software because they have to, but I still would wager it's uncommon.)
2. So if this assumption is true, if everything were BSD, there wouldn't be substantially less OSS software.
3. However, commercial software (read: non-free software by companies that wouldn't touch the GPL with a ten-foot pole) being able to use open source would increase the quality of the commercial software.
So the overall quality available to the consumer goes up. Voila!
(For the record, I agree with this argument as far as it goes, but I don't think the jump from the argument to the conclusion (i.e. from the numbered steps to the following statement) is sound. There's too much other stuff in there. Developers who don't like to see their code taken without compensation wouldn't work on OSS in this BSD-alternate universe, which I think *would* substantially cut down on the quantity and quality of OSS software.)
Who says I didn't comprehend? The reply I made wasn't so much directed at my parent as it was directed generally, since it's a widespread mistake.
Anyway, I have a couple other posts (that being the most relevant) explaining why such a distinction DOES get in the way of the content. So if you want a reply to the content of my parent, check that out.
I only did a Google seach before (when I typed it), and it didn't give the link to definitions up in the upper right. Furthermore, there were under 20K hits, and almost all on the first page were links to comp sci things, e.g. unambiguity in XML syntax. From this I inferred (note: not "implied") that it was not a generally acceptable word.
Upon further investigation, it does not appear in the American Heritage Dictionary or Merriam-Webster's Abridged or Collegiate dictionaries. (I can't check M-W's unabridged.) It does appear in Webster's unabridged. Finally, the word has an entry in the OED, though it consists of no definition and only a single quote from 160 years ago, so I'm not sure what to make of it.
So if it is a mistake, I submit that it was an honest and very well founded one.
Damn it, and I'm usually good about that word pair too. Someone at IBM swapped those words (I forget which way) in the documentation for z/VM, and got a good chuckle out of it after it got done bugging me.
I still have to look up lie v. lay though, despite trying to learn it I don't know how many times...
His proper use of semicolons as delimiters in a list after a colon was most impressive.
I've never head the rule before, and the one language guide I have doesn't list that under proper uses of semicolons and has an example of a list with commas after a colon. The only time I know of where it is proper to use a semicolon in a list is if the list elements themselves have punctuation. For example, "You have your choice of the following: cheap, fast, and unreliable; cheap, slow, and reliable; or expensive, fast, and reliable."
Do you have a reference that says the use of semicolons in a list without such internal punctuation is acceptable?
This is because, technically, you are not supposed to split your infinitives.
There is no clear consensus on this.
Diana Hacker's A Writer's Reference tilts pretty strongly toward not splitting, but isn't absolute in the case that it's less akward to split the infinitive. It gives the example of "We decided to actually enforce the law" versus "We decided actually to enforce the law" as an example of where you would want to. (Note that both have a shade different meaning from "We actually decided...")
The American Heritage Book of English Usage says that they have been frowned on but been in common use (even among acedemics) for centuries and really shouldn't be.
The Wikipedia article indicates that most grammarians of this century accept them, and says that "all reference texts of grammar deem simple split infinitives unobjectionable."
This debate reminds me of people who condem the use of the word "snuck."
You're living in an apartment, and they only allow small pets. As a result, you decide to be a bit odd and get a pet tarantula. It's a big bugger, and you take it out now and then, but occasionally forget to lock the door after putting it back in its cage. One day, after forgetting to do this, you are writing in your diary about it, and you write "one of these days I'm going to lose that tarantula and it's going to bite someone."
And, a month later, your prediction comes true. You forget to lock the cage, and it escapes and bites someone. They sue you (hey, it's the US), and during discovery they see your diary. They're looking through it and see that entry. Only it turns out that you didn't say "lose" like you meant, you said "loose". This simple mistake -- whether it be a simple typo, slip of the mind, or actual ignorance on the correct word -- completely changes the meaning of the sentence. Suddenly, your neighbor decides that he isn't going to sue you for negligence for not locking the cage, and you're faced with an intentional battery tort.
This is still somewhat strained, but spelling is often very important.
I've posted a couple other posts about this, but the underlying assumption you're making is this: " I don't see the added value in conveying meaning for most academic rules". And I agree with you so far as that assumption leads us, that rules are arbitrary.
But, I don't agree with the assumption. The problem is that people ignoring the rules make language more ambiguous and thus introduce errors into your message. I'm not going to go into this again here because I've written twoexamples of where widespread misuse of words has reduced the options for what words we can use when we need to be precise. Word choice is not exactly a grammar issue, but it's only at a very slightly higher level.
But there can be ambiguities at the grammatical level too that are brought about by confusion about what is right. The only example I can think of off the top of my head is too strained, so I will forgo it and if I think of a better one come back and reply again.
Slashdot Mirror
Riddle: What's the size of a method pointer?
Riddle: What's the lowest number you can be guranteed of an int holding? char? What's the guranteed range of a char?
If you answered negative 2 billion something, you're wrong.
If you answered -32768, you're wrong. While I am unaware of any implementation that doesn't allow you to have an int of -32768, it's not guranteed. The range of an int is only guranteed to be at least -32767 to 32767.
Range of a signed char is -127 to 127.
And the guranteed range of a char is 0 to 127.
Yet these ranges are usually changed.
What's the size of an int? Might be 2 bytes. Might be 4 bytes. If you have a 64 bit machine, it could probably legally be 8 bytes. Is this a problem?
In fact, what's the size of a normal pointer? You don't know!
Of all the things you could complain about member pointers, it being an unpredictable size is NOT one of them.
It wasn't a matter of choosing the keywoard that was a problem; I'm sure that he would have thought that either pure or abstract would have been splendid.
It's just that if he chose a keyword, it would either have to be one that was already in use (in which case you get just as akward a syntax) or something that, probably, someone was using as an identifier somewhere.
You add a keyword to a language and bam, suddenly you break code. Not breaking code unless absolutely necessary was a primary goal of Stroustrup when he was writing C++, so he went with an obscure syntax that didn't break code rather than a nicer syntax that did.
There's another part of D&E where he says pretty much that about keywords in general.
(If you want another example of when this happened, I think the crazy syntax for differentiating between the prefix and postfix increment and decrement operators came about very similarily.)
No, in sum, the argument went "I didn't want to piss off anyone in my user base that was using pure or abstract as an identifier somewhere, so I chose a syntax that, while a bit obscure, didn't break existing code."
If you'd investigate and read D&E instead of making sarcastic remarks, you'd learn that not breaking existing code -- C code, even, let alone existing C++ code -- was one of the primary goals.
I have. In fact, just a couple weeks ago I expressed my angst at a coworker that Java didn't have friend. Know why? JUnit tests.
There are essentially three ways to structure JUnit tests:
1. Entirely separate from the code that's being tested. This is how we have our project set up. Part of our directory structure is:2. JUnit tests in the same package as what they are testing
3. JUnit tests in the same class they are testing
I would very strongly argue that those options are listed it order of decreasing desirability from a design perspective. Unit tests shouldn't ship with the final project and are logically different, so they should be separated.
However, moving down the list brings benefits: you can test more. With option 1, you can only test public methods. With option 2, you can test public and protected methods. With option 3, you can test all methods.
If Java had friend methods, it would be possible to say that everything in the JUnit tests is a friend. Now voila, they can access (and thus test) private members while you still keep them separate.
Granted, it's not a perfect solution, as you still need the friend statements, but it's still better than anything else I see.
BTW, if anyone knows a better way to do this, let me know. We're all pretty new (all interns working very much on our own amongst people who tell us we're the resident Java experts) at this.
I thought we were staying with C++ because of all the code that's already written in it... ...then this story changes nothing. That's the nature of an addition to the language, they'll be very careful to not break any code. They might depricate a few features (I haven't yet read the article in question, but I've seen a few others in the past, and one feature that some are pushing to depricate are (type) expression and type(expression) style casts), etc., but if any of the changes break existing code, the broken code will be very rare and either poorly written or easy to fix.
Maintaining backwards compatability has been a hallmark of the development of C++ from the beginning, and is the reason for some of the more opaque syntax forms. (For instance, rather than add a new keyword (not even that major a change to existing code) for pure virtual functions, Strostrup came up with the foo() = 0; syntax.)
I'll second (third? forth?) this opinion.
I'll be the first person blubbering about how using a Swing program is only slightly less painful than drinking a pan-galactic gargle blaster, how metal looks like someone took a dump on the screen, etc., but Eclipse is very nice to use.
If Sun were to drop Swing and pick up SWT I think they would see results very quickly.
I'm going to have to seriously consider Java and SWT as an option for any programs I do that I want to be cross platform, and to say that I find programming in Java less than pleasurable is about accurate.
You're saying "Why copy a bad API" and suggesting one that is quite similar to MFC?!
If wxWidgets is like gas, then it's a high-sulfur diesel.
The problem with C++ is that is was built with focus purely on technology and seemingly without any effort to human factors at all
:: to Java's .
...separate interface and implementation files...
Actually, if you look into it I think you'll find that a lot of design decisions were made with the design of compilers in mind. Maybe not simple stuff like the >> as a token problem, but a lot more.
I mean come on, "::" to separate class from method name
What's wrong with that? It's probably because I used it first, but I prefer
Besides, if you're trying to defend Java, would you like a list of about a dozen syntactic disadvantages of Java over C++?
First, I must say I still prefer the C++ approach to the Java/C# one file approach. Want to look up a function? It's easy... you don't have to wade through implementation crap you don't care about. Sure, if the programmer was nice in Java you'll have an interface you're looking at, but programmers are not always nice. (I realize this is significantly less of a problem with an IDE that will present you with a list of the members.)
Second, want a single implementation and interface file in C++? Great. Write one. C++ lets you.
Third, it's the easiest way to allow people to distribute binaries without source while still maintaining C++'s increased compile-time type safety over Java.
with operator overloading it is impossible to know what a C++ code is doing (ie, cin >> s, shift right or method call?).
No it isn't, not any more impossible than it is with Java. Is cin or s an object? Then you have a call to an overloaded operator. (Okay, C++ allowing automatic conversions muddles things somewhat, but I'd still kill someone to get operator overloading in Java. It cleans up a LOT more than it muddles.)
"Yes, you might make sme goofs on whichever keyboard you're not using full time."
I'm not even sure it's that dire a circumstance. When I'm on qwerty, I don't think I make any more typos than I did before I started using Dvorak.
For me, the only effects I've noticed is typing the first few words in the wrong layout immediately after switching and having to delete them.
(Windows's treatment of layouts exacerbates this problem because it keeps the active layout on a per-application instead of a system-wide basis, so you'll be typing along happily, change windows, and BAM, you're in the opposite layout. There have been many times when I've been appreciative of the way it does things, but overall I think it causes more headaches than it solves.)
The benefit of Dvorak, of course, is that on most computers you can sit down and within a minute or so change the keyboard layout and have a Dvorak keyboard. I've yet to see a software switch that will morph your keyboard like that.
Any parent whose kid is THAT eager to read a book--any book--should be encouraged, even if it's staying up late on a summer night.
Fully agreed!
What's staying up late gonna do to them? Make them tired? Oh no, so they'll just sleep in later. It's summer; it's not like they have to be at work or school.
The only problem I could see is if both parents worked and the kid had to be at day care or something.
Or they could, of course, adapt to the situation and offer services that the big chains don't (such as stocking books from smaller publishers that the big chains won't stock by default).
Won't work; people are too eager to save a couple bucks. Even I, who values local stores, would special order a book from B&N before getting it from a small bookseller if it'd save me more than a couple bucks.
Look at all the people who shop at Wal-Mart. I have yet to find one thing they offer besides cheap prices. I was in there looking for 100 speed film (one of three or so times I've been in a Wal-Mart this year, because I couldn't get anywhere else) and after asking two employees working at the photo counter if they sold "100 film" (I didn't see any on the shelf) I was told that no, they didn't sell 100 film, but had 110 right over there on the shelf. I promptly grabbed a box of 200 and skedattled my way out of there.
You can blame the customer but it's like saying the Nigerian scammers aren't at fault their victums are to blame.
Um, no, it's completely not like that.
With the Nigerian scams, the scammer is saying "if you give me your bank account number, you'll get $$$."
With autorenewal subscriptions, the vendor is saying "if you want to cancel you have to tell us, otherwise we're going to bill you."
The first is a lie; the second isn't.
Just because it may be hidden doesn't mean it's not there. Deception is a different ballgame than fraud.
Most of the companies making money off of GPL "software" though aren't making it off of the software, they're making it off of enterprise support contracts. If you want to provide support, go ahead and do so, but if you want to sell software, it's very difficult to do if you're selling it open source.
(Ironically, it's less difficult if it's GPL, because then you can dual license.)
I'm not sure this is as clear cut as you think though. I can make an argument that the GPL is bad for consumers:
1. First, I assume that the number of companies who are writing GPL code but wouldn't be if all OSS was under a BSD license is small. I don't know if this is a valid assumpition or not, but it seems to me that a company would be either willing to release their work as open source or they wouldn't, and the boundary, where being able to use existing GPL code would make the difference, would be small. (I'm sure there are exceptions, I mean you hear about the occasional case where a company opens software because they have to, but I still would wager it's uncommon.)
2. So if this assumption is true, if everything were BSD, there wouldn't be substantially less OSS software.
3. However, commercial software (read: non-free software by companies that wouldn't touch the GPL with a ten-foot pole) being able to use open source would increase the quality of the commercial software.
So the overall quality available to the consumer goes up. Voila!
(For the record, I agree with this argument as far as it goes, but I don't think the jump from the argument to the conclusion (i.e. from the numbered steps to the following statement) is sound. There's too much other stuff in there. Developers who don't like to see their code taken without compensation wouldn't work on OSS in this BSD-alternate universe, which I think *would* substantially cut down on the quantity and quality of OSS software.)
Who says I didn't comprehend? The reply I made wasn't so much directed at my parent as it was directed generally, since it's a widespread mistake.
Anyway, I have a couple other posts (that being the most relevant) explaining why such a distinction DOES get in the way of the content. So if you want a reply to the content of my parent, check that out.
Unambiguity is a word
Depends what dictionary you look in.
I only did a Google seach before (when I typed it), and it didn't give the link to definitions up in the upper right. Furthermore, there were under 20K hits, and almost all on the first page were links to comp sci things, e.g. unambiguity in XML syntax. From this I inferred (note: not "implied") that it was not a generally acceptable word.
Upon further investigation, it does not appear in the American Heritage Dictionary or Merriam-Webster's Abridged or Collegiate dictionaries. (I can't check M-W's unabridged.) It does appear in Webster's unabridged. Finally, the word has an entry in the OED, though it consists of no definition and only a single quote from 160 years ago, so I'm not sure what to make of it.
So if it is a mistake, I submit that it was an honest and very well founded one.
Damn it, and I'm usually good about that word pair too. Someone at IBM swapped those words (I forget which way) in the documentation for z/VM, and got a good chuckle out of it after it got done bugging me.
I still have to look up lie v. lay though, despite trying to learn it I don't know how many times...
His proper use of semicolons as delimiters in a list after a colon was most impressive.
I've never head the rule before, and the one language guide I have doesn't list that under proper uses of semicolons and has an example of a list with commas after a colon. The only time I know of where it is proper to use a semicolon in a list is if the list elements themselves have punctuation. For example, "You have your choice of the following: cheap, fast, and unreliable; cheap, slow, and reliable; or expensive, fast, and reliable."
Do you have a reference that says the use of semicolons in a list without such internal punctuation is acceptable?
Context gives you hints -- that's why the common case isn't a problem -- but there are situations in which it's ambiguous.
This is because, technically, you are not supposed to split your infinitives.
There is no clear consensus on this.
Diana Hacker's A Writer's Reference tilts pretty strongly toward not splitting, but isn't absolute in the case that it's less akward to split the infinitive. It gives the example of "We decided to actually enforce the law" versus "We decided actually to enforce the law" as an example of where you would want to. (Note that both have a shade different meaning from "We actually decided...")
The American Heritage Book of English Usage says that they have been frowned on but been in common use (even among acedemics) for centuries and really shouldn't be.
The Wikipedia article indicates that most grammarians of this century accept them, and says that "all reference texts of grammar deem simple split infinitives unobjectionable."
This debate reminds me of people who condem the use of the word "snuck."
That won't help you when you're reading and the author used them.
I got an example, suggested by another posts.
You're living in an apartment, and they only allow small pets. As a result, you decide to be a bit odd and get a pet tarantula. It's a big bugger, and you take it out now and then, but occasionally forget to lock the door after putting it back in its cage. One day, after forgetting to do this, you are writing in your diary about it, and you write "one of these days I'm going to lose that tarantula and it's going to bite someone."
And, a month later, your prediction comes true. You forget to lock the cage, and it escapes and bites someone. They sue you (hey, it's the US), and during discovery they see your diary. They're looking through it and see that entry. Only it turns out that you didn't say "lose" like you meant, you said "loose". This simple mistake -- whether it be a simple typo, slip of the mind, or actual ignorance on the correct word -- completely changes the meaning of the sentence. Suddenly, your neighbor decides that he isn't going to sue you for negligence for not locking the cage, and you're faced with an intentional battery tort.
This is still somewhat strained, but spelling is often very important.
I've posted a couple other posts about this, but the underlying assumption you're making is this: " I don't see the added value in conveying meaning for most academic rules". And I agree with you so far as that assumption leads us, that rules are arbitrary.
But, I don't agree with the assumption. The problem is that people ignoring the rules make language more ambiguous and thus introduce errors into your message. I'm not going to go into this again here because I've written two examples of where widespread misuse of words has reduced the options for what words we can use when we need to be precise. Word choice is not exactly a grammar issue, but it's only at a very slightly higher level.
But there can be ambiguities at the grammatical level too that are brought about by confusion about what is right. The only example I can think of off the top of my head is too strained, so I will forgo it and if I think of a better one come back and reply again.
So dead pixels are like zits?