That's a perfectly reasonable mapping of the abstract concept "-1" to the physical world; but -1 is still an abstract concept, not a physical number of oranges.
Furthermore, I'll note that thanks to my mad kung-fu skills, I would actually block your bitchslap, take you down and walk off with 2 of your oranges just to teach you a lesson. Combine those with the 4 oranges I had, and the 1 you *imagine* you would take from me, and I am left with 6-1i oranges.
"Mathematics describes 'truth' in a way that transcends physical existence. 1+2=3 (for B>=4) even without any humans to assert it, even without a universe in which to assert it."
Hence the 'to whatever extent'; whether the concept of addition is meaningful independent of conciousness is debateable (by those philosophers who care; IMO, debating it is pointless wanking).
I can't hand you -1 oranges either. Some argument might be made for "natural" numbers being fundamental in some sense, but I'm not sure I'd buy it. For further discussion, see Russel;l & Whitehead.
"I suspect it wouldn't in statistics , but in geometry I'm surprised. If you're writing efficient code shiting (depending how good or bad the compiler is) can be a lot faster than mult or division by 2."
Any compiler worth using does optimizations like that for you. But probably not that one specifically, because every processor from the last 20 years or so (that you'd be doing geometry on; maybe not microcontrollers) will do that one in hard- or firm- ware. That's exactly the sort of "optomization" that at best just makes your code unreadable, and quite possibly prevents the compiler from making even better optomizations.
I've never seen a "*" or a "<<" and been confused about what it meant. Not once, ever. Not one of the many C++ programmers I've known in person has ever expressed such confusion. Sorry if it's a big problem for you, but I honestly have a hard time relating.
You say you learned C++ only as a career necesity, but if you hate it so much, maybe C++ programmer isn't a good career choice?
Or paid-for papers. For most newspapers, the subscription price is not a significant revenue source; it probably doesn't even cover the cost of printing your paper. The point of charging you for the paper is chiefly to convince advertisers you're going to look at it, and not just throw it away (or to convince them you even exist in the first place).
That's really funny. My work is chiefly computational geometry and/or statistics, but bit-shifting doesn't come up much in either. It comes up in ocasional forays into custom compression schemes. Sorry, no, I really can't see bit shifting on the same line as stream output in any serious code; it's going to be a couple function calls and abstraction barriers away. Maybe in some quick and dirty test code, but in any case, how hard is it?
cout << (a << 4);
Sorry, but the multiple meanings of "<<" is just not a cause of any confusion for any serious C++ programmer; it's a funny quirk that newbies coming from C notice. Does it bother you that "*" sometimes means "multiply" and sometimes means "dereference"? Do you have an example of any code ever where the overloading of "<<" is confusing to you? Because I've got a heck of a lot where it makes stream output much more readable.
As I've said elsewhere, if you're not writing code most of your working hours, C++ is not designed with you in mind, and is probaly not suited to your needs.
"issues with its syntax which frankly make complex C++ unreadable to any sane person" Well, in that case there's a heck of a lot of insane people out there producing a heck of a lot of nicely functioning code.
Original poster: "I'm betting that you won't see $0.01 of your Social Security"
Me:
that's BS, you haven't looked at the numbers.
You: "...I would get about $30-$40 a month..."
$30 dollars a month is more than 1 penny total, so I'm not sure why you think you disagree with me. Estimates of how much any particular person will get from SS depend on a great many factors, most of which I don't know about you, and several of which nobody can possibly know because they depend on future events. So I won't argue about how much you should expect to see. I will note that I do not recomend depending on SS exclusively for support when you are old. SS is not intended to let you relax; it is intended to prevent your starving to death on the street looking so grody that the rest of us take pity on you and pay to feed you anyway. Since we're going to pay to prevent your starving to death pitifully anyway, we might as well do it in a somewhat efficient manner.
I'm saying that, in my experience, the "right" way and the "fastest" way are almost always the same. I see people regularly do no planning, and dive straight into something to just "hack it together" because they only have a couple days to get it done! And these people invariably run into problems that cause the project to take a week and not work at the end. Problems that could have been avoided if they spent 5 minutes planning how to do it the right way before they jumped in.
I'd hate that! That "2" means something different than "2f". I enjoy various software that offers options for what it thinks I might mean if it does it unobtrusively, but I absolutely despise editors that won't let me type what I wish to type no matter what it is. Now in this case, the differentce between that "2" and "2f" and any half decent compiler will be throwing out the whole "2.0 + 2" for a "4f" right off the top. But that's just all the more reason to assume if I wrote "4" in such an idiosyncratic way, I must have wanted it to look that way specifically.
Wow, you really have no idea how the rest of the world lives do you?
You have healthcare, regardless of how you pay for it? You have police who do anything other than extortion? You have an employer? Who gives you vacation days? Hell, you probably have food and clean water most days.
"unless you're like 50-60, I'm betting that you won't see $0.01 of your Social Security."
Then you've bought someones BS propaganda without ever looking at the numbers.
If someone can do your job just as well for less money because they live in a country where they don't pay for all those things you don't think you're getting, why shouldn't they get to?
What's a non-sorting map? I once wrote a VectorMap template that let me insert things with automatic sorting like a map, but then iterate across them with the efficiency of a vector, but I don't see what a map is without sorting. Just curious; I don't disagree with your general point; it would be nice to have something more complete than STL.
Boost is a candidate, but whether you can find what you need in there and understand it faster than you can write it yourself...
"Following your logic would argue that multiply doesn't mean anything on pointers, so it is okay to make it an overloaded operator to increase the reference count and make a backup of the underlying object in a log file (multiply like rabbits). I think that would be a totally broken use of the multiplication operator myself."
No, folowing my logic would argue that multiply doesn't mean anything on pointers, so it is okay to use the same operator (asterix) in a unary mode to mean "dereference". Thanks, that's a great example of how using the same operator to mean entirely different things can be perfectly reasonable is the right circumstances.
Well, quite a few of us see the benefit (and frankly don't think it's all that complex). If you don't, don't use it; nobody is holding a gun to your head. Nobody is holding a gun to the head of the many, many programmers who do choose C++. C++ is a wildly popular language; if you can't figure out the reason why, that doesn't mean there isn't one.
"this is experience programming in ~million-line C++ projects for the last 25 years talking"
You wrote a million line C++ project two years before Stroustrup claims to have invented the language, eh? You should sue that guy for taking all the credit; but I guess if you admitted inventing C++, it would be harder to criticize. Best lay low, and level vauge critiques of programmers that could apply equally well to any language.
"In decently written code, you don't overload arithmetic operators for I/O"
In a persuasive argument, you don't just blindly re-assert the point someone has just refuted.
Oh, certainly there's times I don't understand the problem well enough. But I don't regret that; I try to learn what's wrong with the first version and hence it's frequently the second version that lives on.
What I regret is when I know there's something wrong with my approach, but do it that way anyway because I "don't have time" to do it right. Then all I learn is what *else* is wrong with the aproach I already knew was basically wrong to begin with. Then I'm generally over time, have something that doesn't work very well, but that I've invested a bunch of time in so it's emotionally difficult to just chuck it; and I've learned nothing I didn't already know about the right way to do it.
"Now I'm sure people will deluge me with examples of cryptic, intentionally obtuse code that dumps the results of shift expressions directly to streams, and thus abuses this construct to create confusion. That's not the point. In decently written code, it's not a problem."
Thanks for fulfilling my prophecy. But I still maintain that in remotely serious code, there's never any reason to do this. Oh, I see, you mean:
cout << a << b;
That certainly happens in real code all the time, and they are both output, every time. It's completely obvious, unless you think operator precedence has mysteriously evaporated and that the programmer decided to use an intentionally confusing formulation. You just don't wind up doing stream output in the same sort of context you do bitwise shifting. If the line starts with cout, and the code isn't part of an obfuscation contest, there aren't any bitwise shifts going on.
"the rest of the abortion that is C++"
C++ is not, and does not try to be, well suited to everyones needs. It may not be well suited to your needs. As one of the most widely and succesfully used programming languages there are, it seems likely it is well suited to somones needs. If you think it is simply an unmitigated pile of garbage, it seems likely you are missing something. Particularly when your criticisms revolve around things that actual users of C++ never have a problem with, even a little bit.
"When your language is one that is meant to sit directly on top of machine code (like C), the size of a numeric type is important"
Yes. It is often very important that it be a size that is native to the machine in question. In well written code, this is often much more important than exactly what that size is. A concept C handles nicely.
K&R did not commit Javascript, and aren't responsible for the problems in your examples.
K&R invented C. In it, and the myriad that follow it's lead, variables will sometimes get converted to closely related types for the purposes of expressions that need them. I for one want to be able to write
float x = 2.0 + 2;
without the compiler throwing up it's hands in a panic not knowing what to do.
But numbers will not be converted to strings, and of course conversions will have no lasting effect on the variable in question. That would obviously be completely insane, and the utter moron who thought it was a good idea should rightly be forced to write javascript all day, and electro-shocked for every bug.
Finally, if the number of bits in your floats matters, you can specify it precisely. If, with any regularity, you'd rather have a specific number of bits in your floats rather than whatever the processor handles natively (and thus rapidly), you shouldn't be using floats. Floats don't represent things exactly, no matter how many bits they have. (Well, contrary to your example, they tend to represent powers of two exactly, but that's just trivia.)
Which is basically what I was trying to say with my second paragraph. Everyone can handle zip-compressed XML right now, so a custom scheme would have to offer a big advantage over that to get anywhere, and it won't. As for CPU-friendliness; it's a non-issue. The average PC out there has a CPU that can decompress a zip file faster it can be read off that same PCs disk, let alone downloaded over a net connection; and that gap is widening. In the coding I do with very large amounts of data, we regularly compress stuff before writing to disk, not to save space, but to save time by using CPU power to reduce disk load.
I'm not missing the point. When most people didn't have browsers, I didn't write my documentation in HTML, and it would have been silly to ask me to, becasue people couldn't read it.
Today, it is silly to ask me to encode my data in a custom format that hasn't been widely adopted if I want others to be able to manipulate it. Maybe one such custom-xml-compression schemes will get widely adopted; and then I'll start using it. But today I'm going to go with zip-compressed XML, because people can read it. It's the usual chicken-and-egg adoption-rate problem to be sure. But ASCII, html, XML, and Zip compression made the jump. If this custom scheme has something compelling to offer, it will too. I do find that hard to imagine, since I don't see what it offers over zip-compressed XML, which is already there.
Which is why I said C++ may be the language you want; certainly there are other candidates. I'm saying I would not reccommend anyone use C++ on an irregular basis. If you're a biologist who does some coding on the side, don't use C++; and don't be surprised if it seems unsuited to your needs.
By analogy, I'm a coder who occasionally does some welding in the garage on weekends. Professional welders would scoff at my hobbyist-level equiptment, and be insanely frustrated by its limited capabilities. But were I to use their equiptment, I would quickly reduce my project to a bubbling pile of slag, and probably set something on fire.
I know sys-admin types, who use a lot of Perl for the myriad little bits of programming they have to do. For real software development, Perl is not an option.
If your business is going to fail unless you regularly get things done in radically inapropriate time frames, then your business is going to fail. Lousy development practices will not change that.
I hear programmers, even bright ones, complain about having to sacrifice correctness for timliness frequently. After I tell them what I think is the fastest way to do something, they say, "I don't have time for that, I only have a week!" Three weeks later, they complain that it was really hard to do their hack because the base code didn't fit with it. The base code that, mind you, already existed, and whose properties were the basis for my recomendation.
A year later, after they're gone, I rip out their buggy thing that never worked right and replace it, improving the base code in the process. It takes me a week.
As far as the house painting analogy:
You will be scraping paint off the furniture you didn't cover, and repainting the stuff you used the wrong color on while I'm done, and working on the next job.
As a former co-worker once put it "C++ is a professionals language"; while this sounds at first like snobish looking down ones nose at other languages, it's not. If you're going to be spending much of your productive work hours over some significant chunk of your career writing code, C++ may be the language you want to do it in. If not, it's probably not.
Slashdot Mirror
That's a perfectly reasonable mapping of the abstract concept "-1" to the physical world; but -1 is still an abstract concept, not a physical number of oranges.
Furthermore, I'll note that thanks to my mad kung-fu skills, I would actually block your bitchslap, take you down and walk off with 2 of your oranges just to teach you a lesson. Combine those with the 4 oranges I had, and the 1 you *imagine* you would take from me, and I am left with 6-1i oranges.
"Mathematics describes 'truth' in a way that transcends physical existence. 1+2=3 (for B>=4) even without any humans to assert it, even without a universe in which to assert it."
Hence the 'to whatever extent'; whether the concept of addition is meaningful independent of conciousness is debateable (by those philosophers who care; IMO, debating it is pointless wanking).
I can't hand you -1 oranges either. Some argument might be made for "natural" numbers being fundamental in some sense, but I'm not sure I'd buy it. For further discussion, see Russel;l & Whitehead.
"I suspect it wouldn't in statistics , but in geometry I'm surprised. If you're writing efficient code shiting (depending how good or bad the compiler is) can be a lot faster than mult or division by 2."
Any compiler worth using does optimizations like that for you. But probably not that one specifically, because every processor from the last 20 years or so (that you'd be doing geometry on; maybe not microcontrollers) will do that one in hard- or firm- ware. That's exactly the sort of "optomization" that at best just makes your code unreadable, and quite possibly prevents the compiler from making even better optomizations.
I've never seen a "*" or a "<<" and been confused about what it meant. Not once, ever. Not one of the many C++ programmers I've known in person has ever expressed such confusion. Sorry if it's a big problem for you, but I honestly have a hard time relating.
You say you learned C++ only as a career necesity, but if you hate it so much, maybe C++ programmer isn't a good career choice?
To whatever extent complex numbers are "not fundamental" neither are reals, nor integers. They are all inventions.
Or paid-for papers. For most newspapers, the subscription price is not a significant revenue source; it probably doesn't even cover the cost of printing your paper. The point of charging you for the paper is chiefly to convince advertisers you're going to look at it, and not just throw it away (or to convince them you even exist in the first place).
"Don't do much maths programming do you"
That's really funny. My work is chiefly computational geometry and/or statistics, but bit-shifting doesn't come up much in either. It comes up in ocasional forays into custom compression schemes. Sorry, no, I really can't see bit shifting on the same line as stream output in any serious code; it's going to be a couple function calls and abstraction barriers away. Maybe in some quick and dirty test code, but in any case, how hard is it?
cout << (a << 4);
Sorry, but the multiple meanings of "<<" is just not a cause of any confusion for any serious C++ programmer; it's a funny quirk that newbies coming from C notice. Does it bother you that "*" sometimes means "multiply" and sometimes means "dereference"? Do you have an example of any code ever where the overloading of "<<" is confusing to you? Because I've got a heck of a lot where it makes stream output much more readable.
As I've said elsewhere, if you're not writing code most of your working hours, C++ is not designed with you in mind, and is probaly not suited to your needs.
"issues with its syntax which frankly make complex C++ unreadable to any sane person"
Well, in that case there's a heck of a lot of insane people out there producing a heck of a lot of nicely functioning code.
Original poster:
"I'm betting that you won't see $0.01 of your Social Security"
Me:
that's BS, you haven't looked at the numbers.
You:
"...I would get about $30-$40 a month..."
$30 dollars a month is more than 1 penny total, so I'm not sure why you think you disagree with me. Estimates of how much any particular person will get from SS depend on a great many factors, most of which I don't know about you, and several of which nobody can possibly know because they depend on future events. So I won't argue about how much you should expect to see. I will note that I do not recomend depending on SS exclusively for support when you are old. SS is not intended to let you relax; it is intended to prevent your starving to death on the street looking so grody that the rest of us take pity on you and pay to feed you anyway. Since we're going to pay to prevent your starving to death pitifully anyway, we might as well do it in a somewhat efficient manner.
I'm saying that, in my experience, the "right" way and the "fastest" way are almost always the same. I see people regularly do no planning, and dive straight into something to just "hack it together" because they only have a couple days to get it done! And these people invariably run into problems that cause the project to take a week and not work at the end. Problems that could have been avoided if they spent 5 minutes planning how to do it the right way before they jumped in.
I'd hate that! That "2" means something different than "2f". I enjoy various software that offers options for what it thinks I might mean if it does it unobtrusively, but I absolutely despise editors that won't let me type what I wish to type no matter what it is. Now in this case, the differentce between that "2" and "2f" and any half decent compiler will be throwing out the whole "2.0 + 2" for a "4f" right off the top. But that's just all the more reason to assume if I wrote "4" in such an idiosyncratic way, I must have wanted it to look that way specifically.
Wow, you really have no idea how the rest of the world lives do you?
You have healthcare, regardless of how you pay for it? You have police who do anything other than extortion? You have an employer? Who gives you vacation days? Hell, you probably have food and clean water most days.
"unless you're like 50-60, I'm betting that you won't see $0.01 of your Social Security."
Then you've bought someones BS propaganda without ever looking at the numbers.
If someone can do your job just as well for less money because they live in a country where they don't pay for all those things you don't think you're getting, why shouldn't they get to?
What's a non-sorting map? I once wrote a VectorMap template that let me insert things with automatic sorting like a map, but then iterate across them with the efficiency of a vector, but I don't see what a map is without sorting. Just curious; I don't disagree with your general point; it would be nice to have something more complete than STL.
Boost is a candidate, but whether you can find what you need in there and understand it faster than you can write it yourself...
"Following your logic would argue that multiply doesn't mean anything on pointers, so it is okay to make it an overloaded operator to increase the reference count and make a backup of the underlying object in a log file (multiply like rabbits). I think that would be a totally broken use of the multiplication operator myself."
No, folowing my logic would argue that multiply doesn't mean anything on pointers, so it is okay to use the same operator (asterix) in a unary mode to mean "dereference". Thanks, that's a great example of how using the same operator to mean entirely different things can be perfectly reasonable is the right circumstances.
Which is an unrelated sentiment that we could also discuss, if you bothered to explain what you meant by it.
Well, quite a few of us see the benefit (and frankly don't think it's all that complex). If you don't, don't use it; nobody is holding a gun to your head. Nobody is holding a gun to the head of the many, many programmers who do choose C++. C++ is a wildly popular language; if you can't figure out the reason why, that doesn't mean there isn't one.
"this is experience programming in ~million-line C++ projects for the last 25 years talking"
You wrote a million line C++ project two years before Stroustrup claims to have invented the language, eh? You should sue that guy for taking all the credit; but I guess if you admitted inventing C++, it would be harder to criticize. Best lay low, and level vauge critiques of programmers that could apply equally well to any language.
"In decently written code, you don't overload arithmetic operators for I/O" In a persuasive argument, you don't just blindly re-assert the point someone has just refuted.
Oh, certainly there's times I don't understand the problem well enough. But I don't regret that; I try to learn what's wrong with the first version and hence it's frequently the second version that lives on.
What I regret is when I know there's something wrong with my approach, but do it that way anyway because I "don't have time" to do it right. Then all I learn is what *else* is wrong with the aproach I already knew was basically wrong to begin with. Then I'm generally over time, have something that doesn't work very well, but that I've invested a bunch of time in so it's emotionally difficult to just chuck it; and I've learned nothing I didn't already know about the right way to do it.
From my original post:
;
"Now I'm sure people will deluge me with examples of cryptic, intentionally obtuse code that dumps the results of shift expressions directly to streams, and thus abuses this construct to create confusion. That's not the point. In decently written code, it's not a problem."
Thanks for fulfilling my prophecy. But I still maintain that in remotely serious code, there's never any reason to do this. Oh, I see, you mean:
cout << a << b
That certainly happens in real code all the time, and they are both output, every time. It's completely obvious, unless you think operator precedence has mysteriously evaporated and that the programmer decided to use an intentionally confusing formulation. You just don't wind up doing stream output in the same sort of context you do bitwise shifting. If the line starts with cout, and the code isn't part of an obfuscation contest, there aren't any bitwise shifts going on.
"the rest of the abortion that is C++"
C++ is not, and does not try to be, well suited to everyones needs. It may not be well suited to your needs. As one of the most widely and succesfully used programming languages there are, it seems likely it is well suited to somones needs. If you think it is simply an unmitigated pile of garbage, it seems likely you are missing something. Particularly when your criticisms revolve around things that actual users of C++ never have a problem with, even a little bit.
"When your language is one that is meant to sit directly on top of machine code (like C), the size of a numeric type is important"
Yes. It is often very important that it be a size that is native to the machine in question. In well written code, this is often much more important than exactly what that size is. A concept C handles nicely.
K&R did not commit Javascript, and aren't responsible for the problems in your examples.
K&R invented C. In it, and the myriad that follow it's lead, variables will sometimes get converted to closely related types for the purposes of expressions that need them. I for one want to be able to write
float x = 2.0 + 2;
without the compiler throwing up it's hands in a panic not knowing what to do.
But numbers will not be converted to strings, and of course conversions will have no lasting effect on the variable in question. That would obviously be completely insane, and the utter moron who thought it was a good idea should rightly be forced to write javascript all day, and electro-shocked for every bug.
Finally, if the number of bits in your floats matters, you can specify it precisely. If, with any regularity, you'd rather have a specific number of bits in your floats rather than whatever the processor handles natively (and thus rapidly), you shouldn't be using floats. Floats don't represent things exactly, no matter how many bits they have. (Well, contrary to your example, they tend to represent powers of two exactly, but that's just trivia.)
Which is basically what I was trying to say with my second paragraph. Everyone can handle zip-compressed XML right now, so a custom scheme would have to offer a big advantage over that to get anywhere, and it won't. As for CPU-friendliness; it's a non-issue. The average PC out there has a CPU that can decompress a zip file faster it can be read off that same PCs disk, let alone downloaded over a net connection; and that gap is widening. In the coding I do with very large amounts of data, we regularly compress stuff before writing to disk, not to save space, but to save time by using CPU power to reduce disk load.
I'm not missing the point. When most people didn't have browsers, I didn't write my documentation in HTML, and it would have been silly to ask me to, becasue people couldn't read it.
Today, it is silly to ask me to encode my data in a custom format that hasn't been widely adopted if I want others to be able to manipulate it. Maybe one such custom-xml-compression schemes will get widely adopted; and then I'll start using it. But today I'm going to go with zip-compressed XML, because people can read it.
It's the usual chicken-and-egg adoption-rate problem to be sure. But ASCII, html, XML, and Zip compression made the jump. If this custom scheme has something compelling to offer, it will too. I do find that hard to imagine, since I don't see what it offers over zip-compressed XML, which is already there.
Which is why I said C++ may be the language you want; certainly there are other candidates. I'm saying I would not reccommend anyone use C++ on an irregular basis. If you're a biologist who does some coding on the side, don't use C++; and don't be surprised if it seems unsuited to your needs.
By analogy, I'm a coder who occasionally does some welding in the garage on weekends. Professional welders would scoff at my hobbyist-level equiptment, and be insanely frustrated by its limited capabilities. But were I to use their equiptment, I would quickly reduce my project to a bubbling pile of slag, and probably set something on fire.
I know sys-admin types, who use a lot of Perl for the myriad little bits of programming they have to do. For real software development, Perl is not an option.
If your business is going to fail unless you regularly get things done in radically inapropriate time frames, then your business is going to fail. Lousy development practices will not change that.
I hear programmers, even bright ones, complain about having to sacrifice correctness for timliness frequently. After I tell them what I think is the fastest way to do something, they say, "I don't have time for that, I only have a week!" Three weeks later, they complain that it was really hard to do their hack because the base code didn't fit with it. The base code that, mind you, already existed, and whose properties were the basis for my recomendation.
A year later, after they're gone, I rip out their buggy thing that never worked right and replace it, improving the base code in the process. It takes me a week.
As far as the house painting analogy:
You will be scraping paint off the furniture you didn't cover, and repainting the stuff you used the wrong color on while I'm done, and working on the next job.
As a former co-worker once put it "C++ is a professionals language"; while this sounds at first like snobish looking down ones nose at other languages, it's not. If you're going to be spending much of your productive work hours over some significant chunk of your career writing code, C++ may be the language you want to do it in. If not, it's probably not.