Personally I think optimizations around null pointer dereferences are symptoms of the worst form of brain damaged stupidity and/or intentional malice in compiler developers
Lots of people think this. Those people are astonishingly arrogant. That means you.
Compiler writers aren't some cackling evil genius masterminds in some shadowy cabal figuring out how to make programmers hard due to language pedantry.
That's not how compilers work.
Optimisers are code analysers and theorem provers. First you write a code analyser which figures as much as it can about any piece of code, such as range of values, data flow, aliasing, etc. Then you plug in the rules (which is the language spec). You then provide a list of transformations known to improve speed.
The theorem prover then crunches on the data to figure out which transformations it can apply which don't change any of the known properties of the code.
Theorem are not human. They have no way of knowing which null pointer dereferences are bugs and which are not.
What you are asking is for the compiler vendors to do all those handy optimisations but then insert human-like intelligence into the theorem prover so it can know when one particular deduction at the end of a very long series of inferences should be flagged and when another is valid. You're then ragging on because they're not magicians.
they're not intentionally emitting UB they're emitting code that is correct provided that UB has not already happened.
With Rust, something like macro overloading would be a code obfuscatory dream.
And C macros aren't? So here's the cognitive dissonance that seems to exist with C advocates. It was applied to C++ and appears to applied unchanged to Rust too.
On the one hand the attitude is that good programmers don't need the hand-holding of Crust++. On the other hand Crust++ lets you write other kinds of bad code.
Make up your mind! Do you have good programmers or bad ones? And why on earth don't you have some form of code review?
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources.
[citation needed] on the latter. AFAICT C, C++ and Rust have more or less exactly the same model of how computers work. I don't see any evidence that any one of them is more resource hungry than the other (possible arguments about C++ exceptions aside).
The only way you get buffer overflows these days is if you turn OFF the standard warnings, and use deprecated functions, while writing C.
That's bullshit. All you have to do is access an array with an incorrect index. You won't get a warning for that. And you won't even get it flagged with a run-time check until you feed it the wrong data. You know like heartbleed.
IOW your claim is flat out false and implies you either don't program C or you're so misinformed about it that you're a menace if you do program it.
Like almost all languages, Rust won't normally have buffer overflows. They've hyped that so much it would make PT Barnum blush, acting like that's something special.
It's really not the most important thing about Rust. Though in fairness it seems that so many C hackers are so misinformed about their own language and still struggling that it apparently matters.
the borrow checker actually prevents a wide class of memory errors and data races. The former are interesting enough, though not common in C++ (I occasionally have some). The latter is much more interesting though. If I was writing high performance (multithreaded) software with irregular structure then I'd be very seriously considering Rust since it seems to be the only language up to the task.
I'm not though, so I'll stick to C++. I'm not naive enough though to think my language is perfect just because I learned it 20 years ago.
every modern language is safe from buffer overruns assuming a competent programmer.
That's a foolish claim because it's tautologically true while being misleading. Assembly language is free from buffer overrnus with a sufficiently competent programmer. In practice however everyone makes mistakes.
No, because that question implies a prior state, which a "yes" or "no" answer implicitly confirms. The "have you written anything in Rust" implies no prior state and a yes or no answer does not implicitly confirm aything.
Incidentally, the believers in "just use this great new tool and all your problems will be solved" have been around forever, and they have been just as stupid way back as they are today. Brooks already had a chapter on it: "There is no silver bullet." Yet time and again, some people with little understanding of what matters claim that their pet-tool is that silver bullet.
I think this is in many ways not correct, but there's quite a lot to unpick.
Fanbois aside (let's ignore them because they muddy all sides of the argument), no one is claiming Rust will solve all problems.
C, C++ and Rust all provide essentially the same machine model. Arguably Rust's is closer to C than C++ is to C since it doesn't need as much runtime support (for exceptions). But there's not much to it.
C++ provides a while load of automation on top of C and by virtue of that protects you from a lot of common errors if you use it in a vaguely modern way. Rust provides s buch of compiler enforced restritions which prevent a large class of errors (memory errors and data races).
You very likely have those problems if you write in C, and you won't if you write in Rust. You can abvoid those problems in C with one or more of formal methods (the seL$ model, very hard), large amounts of reviewing (the OpenBSD model---also hard), lots of runtime checking (imprecise). Or you can use a language which does it for you, though the penalty is that now ownership (which you can wing in C) is now front and centre because it turns out you can't magic hard problems away. You can however make them much less hard.
great new tool and all your problems will be solved" have been around forever, and they have been just as stupid way back as they are today
I think this is both wrong and right at the same time. Yes people don't change. Why then can we produce much cooler stuff at a much faster rate now than 10, 20, 50, 100 years ago? The answer is of course better tooling.
Switching from a foot pedal lathe with hand forged carbon steel tooling to a 6 axis CNC machine with auto loading, and auto switching of it's carbide insert tooling certainly won't solve all your problems. It still leaves you with the difficult poblem of designing something nice looking which works with real wood, and that people want to buy. But it certainly alleviates the tedium and hard work of continually cranking that foot pedal and sharpening the tools every five minutes. Which is what it's like programming in C.
It's a bad idea to dismiss tools that solve a lot of your problems merely because they don't solve all problems and while they're at it make you 6 inches taller, move like Jagger and turn you from 8==D to 8======D.
If you're expecting to make people smarter you may as well ask for that.
Brooks already had a chapter on it: "There is no silver bullet."
and yet, I can write programs of vastly greater complexity and that do far more stuff than almost anyone, possibly anyone at all in the 1960s. Why? It sure isn't because I'm some sort of megagenius. No, it's because the tooling is so many orders of magnitude better now than then.
There's nothing that will magically make a bad, badly managed, demotivated team start cranking out good software overnight. That's the silver bullet you're talking about. On the scale of decades however there certainly are things that mean ordinary programmers can vastly outperform maybe all but the best of previous years.
New languages are a way for very smart people to slowly trasfer productivity to much les smart people by creating things that mitigate human frailties.
And OSS has a real C fetishism. It's weird. I mean we have these vastly programmable machines operated ostensibly by programmers who are in essence people who automate things. and yet they are incredibly reluctant to automate any of the day to day tasks they do. I don't get it.
Funy thing of course is that now all that C code is dependent on C++. No good C compler remain that are written in C.
Rust is for morons
Well, good to know you;re thinking about these things carefully.
Oh I though you were talking about this one with the silly non keyboard.
Yeah they're petty similar. The main thing is the X1 ends at a higher top end spec and is a bit lighter, though of course you pay a lot for that. Whether that is of value depends on your use case.
Either way though, the maxed out X1 is cheaper than my work mbp and better in all aspects except the GPU. you can get like 75% of that for under half the price with the yoga.
The standards for such things aren't enormously high, so I'm surprised they can't get a court order anyway. Or who knows. we don't refer to them as "Her Majesty's Finest" for no reason you know.
When did it become fashionable to pretend that there sub categories don't exist.
I propose we should no longer distinguish between digital computers and analog computers because they're just computers.
Unless there are "happy murders" and "love frauds" ?
Congratulations, that's about the stupidest thing I've read on the internet today. That's a pretty high bar.
Since when does something have to be done with love for it to not be done with hate? Someone murdering you to nick your wallet neither loves nor hates you.
That is literally what a contact us for. And yes they can. And no, refusing to do business with someone because you don't like the way they operate is 100% legitimate.
And it's not socialism you moron. It's private contacts between private companies which is a feature of capitalism.
Today, other than some special mil-spec companies, ZERO electronics are made here.
Not a lot that you see, but certainly not zero. At my previous job, the product was largely made in the USA. The circuit boards were made there (I believe--that was subcontracted), the boards were populated, the cases finished and assembled and then everything packaged up into the final packaging all in Texas.
I visited the factory of course and they seemed to be making a fair amount of stuff. What doesn't get done is the huge volume, cheap consumer stuff with razor thin margins.
What does get done is the higher margin more specialised stuff. But little to none of that is consumer facing, so if you're not in the particular industry then you'll never see it.
I was taught to never pull out when it isn't my right-of-way and isn't clear - even if someone stops and waves you out. There are people in the world who will wave you out and then floor it to hit you as an insurance scam.
I was taught the former part (not the latter). I odn't stick by it, because in London, having some nice stranger let you out is about the only way of exiting some junctions this side of Christmas.
"I demand self driving cars violate the laws" How about you follow them?
See this is why self driving cars will never work. If you don't have hands how can you lean one on the horn while flipping the bird with the other? I gather this is a more or less mandatory part of driving in NYC.
Posting a liknk to Breitbart is more or less equivalent to saying "my pisshead mates down the pub told me". I mean sure, it might be true, but neither lends more credibility to the claim.
The entire concept of branding is essentially built around respect. No one actually has the time to "research" and buy 10 of everything then thoroughly analysing all 10 before committing to buy one more.
So, in a lot of cases, I'll just go with a brand I know because while it might cost a little more, I know I won't waste time with it being substandard.
Penisland was probably my favourite. Though second placed goes ot an Italian company (PowerGen) who finding that powergen.com was already taken by a British company registered powergenitalia.com
2.) don't ride like you are entitled. Whether legally you can or not, don't hog the lanes,
Blocks to that. I feel entirely entitled to not get run over.
If you use the middle of the lane you sometimes get to exchange pleasantries with the angry driver behind, but it's vanishingly rare that they'll actually try to murder you. But hogging the edge makes it much more likely you'll get knocked over by some entitled asshat of a driver trying to get past when there's insufficient room. If seen that happen far too many times.
I can see perhaps adding some greek symbols to ascii for variable names, function names, but allowing full unicode is a disaster of a design decision since it permits all kinds of deliberately obscured code.
do they allow full unicode. C++ allows unicode[*], but it specifies which character ranges within unicode can form part of an identifier. So you can have a poop emoji as an identifier, but not a thin space.
[*] which is to say it doesn't and does sort of, in the most C++ish way possible. C++ is defined in terms of a character set and it specifies which ranges in that character set. the character set is not specified, but the ranges look suspiciously identical to unicode ranges. How the compiler goes from the source encoding to the language encoding is implemention defined (outside of plain ascii, and \uXXXXXXXX to get higher range characters). So clang supports poop emoji as an identifier which is conforming and GCC doesn't which is conforming too.
C is lightning fast and is the tool for when you know what you're doing.
C is a lightning fast tool for people who are obsessed with micromanaging things which can be easily automated. If yu want lightning fast performance (often faster) but don't really want to do things by hand that a computer can be easily taught how to do then there's C++.
Everything else just turns into a clusterfuck over time. C and Python have somehow avoided turning into clusterfucks by being simple
C moves the complexity of the language into every single project that uses it. So the language per-se might not be a cluster fuck, but it is the epicentre of a custerfuck of biblical proportions.
Slashdot Mirror
Personally I think optimizations around null pointer dereferences are symptoms of the worst form of brain damaged stupidity and/or intentional malice in compiler developers
Lots of people think this. Those people are astonishingly arrogant. That means you.
Compiler writers aren't some cackling evil genius masterminds in some shadowy cabal figuring out how to make programmers hard due to language pedantry.
That's not how compilers work.
Optimisers are code analysers and theorem provers. First you write a code analyser which figures as much as it can about any piece of code, such as range of values, data flow, aliasing, etc. Then you plug in the rules (which is the language spec). You then provide a list of transformations known to improve speed.
The theorem prover then crunches on the data to figure out which transformations it can apply which don't change any of the known properties of the code.
Theorem are not human. They have no way of knowing which null pointer dereferences are bugs and which are not.
What you are asking is for the compiler vendors to do all those handy optimisations but then insert human-like intelligence into the theorem prover so it can know when one particular deduction at the end of a very long series of inferences should be flagged and when another is valid. You're then ragging on because they're not magicians.
they're not intentionally emitting UB they're emitting code that is correct provided that UB has not already happened.
You know what really sets mature adults apart from wet-behind-the-ears kids? They accept that they're fallible.
You can't rely on a language to do your job for you, but you can certainly rely on a language to make your job easier.
Yes. 100% this. Sub thread over. If you disagree with the parent then you are (a) wrong and (b) a menace behind a keyboard.
I think it more likely that programmers have become lazy
Many of the best programmers are the laziest for the right kind of brutally applied laziness.
Never solve the same problem twice.
With Rust, something like macro overloading would be a code obfuscatory dream.
And C macros aren't? So here's the cognitive dissonance that seems to exist with C advocates. It was applied to C++ and appears to applied unchanged to Rust too.
On the one hand the attitude is that good programmers don't need the hand-holding of Crust++. On the other hand Crust++ lets you write other kinds of bad code.
Make up your mind! Do you have good programmers or bad ones? And why on earth don't you have some form of code review?
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources.
[citation needed] on the latter. AFAICT C, C++ and Rust have more or less exactly the same model of how computers work. I don't see any evidence that any one of them is more resource hungry than the other (possible arguments about C++ exceptions aside).
The only way you get buffer overflows these days is if you turn OFF the standard warnings, and use deprecated functions, while writing C.
That's bullshit. All you have to do is access an array with an incorrect index. You won't get a warning for that. And you won't even get it flagged with a run-time check until you feed it the wrong data. You know like heartbleed.
IOW your claim is flat out false and implies you either don't program C or you're so misinformed about it that you're a menace if you do program it.
Like almost all languages, Rust won't normally have buffer overflows. They've hyped that so much it would make PT Barnum blush, acting like that's something special.
It's really not the most important thing about Rust. Though in fairness it seems that so many C hackers are so misinformed about their own language and still struggling that it apparently matters.
the borrow checker actually prevents a wide class of memory errors and data races. The former are interesting enough, though not common in C++ (I occasionally have some). The latter is much more interesting though. If I was writing high performance (multithreaded) software with irregular structure then I'd be very seriously considering Rust since it seems to be the only language up to the task.
I'm not though, so I'll stick to C++. I'm not naive enough though to think my language is perfect just because I learned it 20 years ago.
every modern language is safe from buffer overruns assuming a competent programmer.
That's a foolish claim because it's tautologically true while being misleading. Assembly language is free from buffer overrnus with a sufficiently competent programmer. In practice however everyone makes mistakes.
So is "Have you stopped beating your wife?".
No, because that question implies a prior state, which a "yes" or "no" answer implicitly confirms. The "have you written anything in Rust" implies no prior state and a yes or no answer does not implicitly confirm aything.
Incidentally, the believers in "just use this great new tool and all your problems will be solved" have been around forever, and they have been just as stupid way back as they are today. Brooks already had a chapter on it: "There is no silver bullet." Yet time and again, some people with little understanding of what matters claim that their pet-tool is that silver bullet.
I think this is in many ways not correct, but there's quite a lot to unpick.
Fanbois aside (let's ignore them because they muddy all sides of the argument), no one is claiming Rust will solve all problems.
C, C++ and Rust all provide essentially the same machine model. Arguably Rust's is closer to C than C++ is to C since it doesn't need as much runtime support (for exceptions). But there's not much to it.
C++ provides a while load of automation on top of C and by virtue of that protects you from a lot of common errors if you use it in a vaguely modern way. Rust provides s buch of compiler enforced restritions which prevent a large class of errors (memory errors and data races).
You very likely have those problems if you write in C, and you won't if you write in Rust. You can abvoid those problems in C with one or more of formal methods (the seL$ model, very hard), large amounts of reviewing (the OpenBSD model---also hard), lots of runtime checking (imprecise). Or you can use a language which does it for you, though the penalty is that now ownership (which you can wing in C) is now front and centre because it turns out you can't magic hard problems away. You can however make them much less hard.
great new tool and all your problems will be solved" have been around forever, and they have been just as stupid way back as they are today
I think this is both wrong and right at the same time. Yes people don't change. Why then can we produce much cooler stuff at a much faster rate now than 10, 20, 50, 100 years ago? The answer is of course better tooling.
Switching from a foot pedal lathe with hand forged carbon steel tooling to a 6 axis CNC machine with auto loading, and auto switching of it's carbide insert tooling certainly won't solve all your problems. It still leaves you with the difficult poblem of designing something nice looking which works with real wood, and that people want to buy. But it certainly alleviates the tedium and hard work of continually cranking that foot pedal and sharpening the tools every five minutes. Which is what it's like programming in C.
It's a bad idea to dismiss tools that solve a lot of your problems merely because they don't solve all problems and while they're at it make you 6 inches taller, move like Jagger and turn you from 8==D to 8======D.
If you're expecting to make people smarter you may as well ask for that.
Brooks already had a chapter on it: "There is no silver bullet."
and yet, I can write programs of vastly greater complexity and that do far more stuff than almost anyone, possibly anyone at all in the 1960s. Why? It sure isn't because I'm some sort of megagenius. No, it's because the tooling is so many orders of magnitude better now than then.
There's nothing that will magically make a bad, badly managed, demotivated team start cranking out good software overnight. That's the silver bullet you're talking about. On the scale of decades however there certainly are things that mean ordinary programmers can vastly outperform maybe all but the best of previous years.
New languages are a way for very smart people to slowly trasfer productivity to much les smart people by creating things that mitigate human frailties.
And OSS has a real C fetishism. It's weird. I mean we have these vastly programmable machines operated ostensibly by programmers who are in essence people who automate things. and yet they are incredibly reluctant to automate any of the day to day tasks they do. I don't get it.
Funy thing of course is that now all that C code is dependent on C++. No good C compler remain that are written in C.
Rust is for morons
Well, good to know you;re thinking about these things carefully.
Oh I though you were talking about this one with the silly non keyboard.
Yeah they're petty similar. The main thing is the X1 ends at a higher top end spec and is a bit lighter, though of course you pay a lot for that. Whether that is of value depends on your use case.
Either way though, the maxed out X1 is cheaper than my work mbp and better in all aspects except the GPU. you can get like 75% of that for under half the price with the yoga.
Some of the X series (e.g. X1Carbons) are little different than the Yoga.
Huh? I got a Carbon X1 for my SO. It's a fantastic machine. Light, powerful, tons of storage and a really really really nice keyboard.
That doesn't sound like a "problem" to me.
Quite so.
The standards for such things aren't enormously high, so I'm surprised they can't get a court order anyway. Or who knows. we don't refer to them as "Her Majesty's Finest" for no reason you know.
"Hate crimes" are just crimes
When did it become fashionable to pretend that there sub categories don't exist.
I propose we should no longer distinguish between digital computers and analog computers because they're just computers.
Unless there are "happy murders" and "love frauds" ?
Congratulations, that's about the stupidest thing I've read on the internet today. That's a pretty high bar.
Since when does something have to be done with love for it to not be done with hate? Someone murdering you to nick your wallet neither loves nor hates you.
They can't dictate how another business is run,
That is literally what a contact us for. And yes they can. And no, refusing to do business with someone because you don't like the way they operate is 100% legitimate.
And it's not socialism you moron. It's private contacts between private companies which is a feature of capitalism.
Today, other than some special mil-spec companies, ZERO electronics are made here.
Not a lot that you see, but certainly not zero. At my previous job, the product was largely made in the USA. The circuit boards were made there (I believe--that was subcontracted), the boards were populated, the cases finished and assembled and then everything packaged up into the final packaging all in Texas.
I visited the factory of course and they seemed to be making a fair amount of stuff. What doesn't get done is the huge volume, cheap consumer stuff with razor thin margins.
What does get done is the higher margin more specialised stuff. But little to none of that is consumer facing, so if you're not in the particular industry then you'll never see it.
Isn't the proper word "ita(TM)s" ?
No, I'm fairly sure it's "it's" (tm).
I was taught to never pull out when it isn't my right-of-way and isn't clear - even if someone stops and waves you out. There are people in the world who will wave you out and then floor it to hit you as an insurance scam.
I was taught the former part (not the latter). I odn't stick by it, because in London, having some nice stranger let you out is about the only way of exiting some junctions this side of Christmas.
? Because that's also against the law and studies have shown that people who do that are more dangerous than people who speed.
The danger comes from the dpeed difference, not going slower per-se.
Probably because people are illegally blocking traffic by driving slower than those around them in the left hand lanes.
I notice how you save your ire for people going slow, but never for those going fast. You sonud like one of those entitles asshat drivers to me.
"I demand self driving cars violate the laws" How about you follow them?
See this is why self driving cars will never work. If you don't have hands how can you lean one on the horn while flipping the bird with the other? I gather this is a more or less mandatory part of driving in NYC.
Facebook censors. [breitbart.com]
Posting a liknk to Breitbart is more or less equivalent to saying "my pisshead mates down the pub told me". I mean sure, it might be true, but neither lends more credibility to the claim.
Who "admires" or even "respects" corporations?
The entire concept of branding is essentially built around respect. No one actually has the time to "research" and buy 10 of everything then thoroughly analysing all 10 before committing to buy one more.
So, in a lot of cases, I'll just go with a brand I know because while it might cost a little more, I know I won't waste time with it being substandard.
I don't expect humanity to mature to the point that nothing offends.
That kind of implied 4chan is the pinnacle of humanity.
Penisland was probably my favourite. Though second placed goes ot an Italian company (PowerGen) who finding that powergen.com was already taken by a British company registered powergenitalia.com
2.) don't ride like you are entitled. Whether legally you can or not, don't hog the lanes,
Blocks to that. I feel entirely entitled to not get run over.
If you use the middle of the lane you sometimes get to exchange pleasantries with the angry driver behind, but it's vanishingly rare that they'll actually try to murder you. But hogging the edge makes it much more likely you'll get knocked over by some entitled asshat of a driver trying to get past when there's insufficient room. If seen that happen far too many times.
I can see perhaps adding some greek symbols to ascii for variable names, function names, but allowing full unicode is a disaster of a design decision since it permits all kinds of deliberately obscured code.
do they allow full unicode. C++ allows unicode[*], but it specifies which character ranges within unicode can form part of an identifier. So you can have a poop emoji as an identifier, but not a thin space.
[*] which is to say it doesn't and does sort of, in the most C++ish way possible. C++ is defined in terms of a character set and it specifies which ranges in that character set. the character set is not specified, but the ranges look suspiciously identical to unicode ranges. How the compiler goes from the source encoding to the language encoding is implemention defined (outside of plain ascii, and \uXXXXXXXX to get higher range characters). So clang supports poop emoji as an identifier which is conforming and GCC doesn't which is conforming too.
C is lightning fast and is the tool for when you know what you're doing.
C is a lightning fast tool for people who are obsessed with micromanaging things which can be easily automated. If yu want lightning fast performance (often faster) but don't really want to do things by hand that a computer can be easily taught how to do then there's C++.
Everything else just turns into a clusterfuck over time. C and Python have somehow avoided turning into clusterfucks by being simple
C moves the complexity of the language into every single project that uses it. So the language per-se might not be a cluster fuck, but it is the epicentre of a custerfuck of biblical proportions.