Having poorly vetted publications makes following research more expensive on our time and effort. Right now, junk research far outstrips proper research. I'd rather have fewer high quality publications rather than research that is only once removed from a blog post.
If you RTFAed, you would find that it contained references to Sokal Affair in several places including Alan Sokal's reaction and support to the new hoax and that the authors in question were very much aware that they were pulling a Sokal.
Just because Sokal Affair was executed once does not mean there would never be another time calling for it. Back then, it was the lack of rigor in post-modernism; right now it is the gender studies. Both are legitimate soft sciences with something to offer, but both have an intellectual rot in several quarters that undermines their scientific legitimacy.
If yet another field emerges in the future that falls into this trap of self-aggrandizing theories that are not sufficiently subjected to critical vetting by their respective communities, then another version of Sokal's Affair would be needed again.
The general gist from here and elsewhere seems to be: concerns against nitrites and nitrates remain unabated, but not as definitive as the smoking link. "More research required" is the usual hedge at the end of almost every paper in medical research. Pinning down any delayed effect in a multi-factorial system with confidence is a slow process in research and is certainly prone to error. But it cannot be helped.
"Prof Tim Key, Cancer Research UK’s epidemiologist at the University of Oxford, said: Cancer Research UK supports IARC’s decision that there’s strong enough evidence to classify processed meat as a cause of cancer, and red meat as a probable cause of cancer."
The North American Meat Institute said defining red meat as a cancer hazard defied common sense.
“It was clear, sitting in the IARC meeting, that many of the panellists were aiming for a specific result despite old, weak, inconsistent, self-reported intake data,” said Betsy Booren, the institute’s vice-president of scientific affairs. “They tortured the data to ensure a specific outcome.
Sure, dietary science is rarely perfect since we can't put people in cages, control for everything and monitor them for years. Medical (or climate science for that matter) advise is often going to be from imperfect conclusions from best available evidence for now - people should understand that.
With meta-analyses that show that all the evidence that points to ill effects is of poor quality.
This is medicine and biology, not formal logic for absolute "proofs". The keywords are current evidence and consensus; but get them from proper sources, even if the consensus may be overturned tomorrow.
GMO activists aren't telling you that nitrites cause cancer, the scientists are. Show me a scientific body that says nitrites are safe, not some health magazine or a "nutritionist". The link isn't new and the concerns haven't abated at all. There are always studies that go both ways in everything. An average Joe isn't equipped to weigh the evidence and understand the scientific consensus. The industry also frequently tries to muddy the waters saying that the evidence is a wash.
They are probably not doing this to gain your trust.
It is probably either or both of 1. Rendering engine is not the differentiating feature of browsers anymore (for me it is, plugin ecosystem, security and privacy choices in design). 2. They understand that they cannot win the browser wars and chose not to spend any further money on the most expensive part of browser development.
They did this before. Microsoft only invested money in the browser when they intended to win the browser wars, and they did with IE. After that, they downsized their dev team. The web stagnated for years until Firefox emerged.
Exactly what is still bothersome about the JVM today? I remember the early annoyances, but both the language and the VM have undergone significant improvements over the years. If you don't like Java the language, there are any number of modern languages to use on the JVM. What would you wish that people used other than the JVM?
I certainly would not call any C++ programmer who has not jumped onto Rust an elitist fool. There may be a number of reasons to not move to something newer even if a better language is available.
But you can call someone an elitist fool if they assume that - C++ is powerful, but Rust isn't, without even understanding Rust. - They assume they are the pros simply because they use C++. No language makes you elite.
You can agree that Rust is, at least as a language, an improvement over C++ and supports safer idioms than even more recent iterations of C++ deliver. If you feel that the ecosystem isn't there yet or that it has not yet feature stabilized, that is a different matter.
And no, Rust does not generate enormous binaries. It generates them at about the same size as C++. You just get static linking by default, which is a minor design choice. You also can exclude the standard library. You just have not looked into it enough. A basic stripped release binary is at 130-140K in Rust. It is about 9-10K if you don't link the standard library.
I am not arguing for Rust per se. I am arguing for progressive evolution of language design rather than stagnating on anything for decades.
I do think Rust is mature enough for most new C++ projects. Care to say why you think it isn't?
And if you are using a language without seat belts and you routinely are getting ejected (state of exploits today), perhaps you should consider seat belts (GC) or better traffic rules (the borrow checker or some other compile time system).
As long as C++ compilers compile C code, it is a perfectly valid contraction. There may be 2 different languages there for very different purposes, but people do often use them together and hence the contraction. The contraction exists for the unique circumstance of C++.
You can't upgrade or redesign what is in between your ears. But we can radically explore new paradigms of program construction.
As per psychology studies, we all think everyone else is incompetent, but that we are among the exceptions.
All the high profile C++ bugs have been authored by well-compensated and highly-experienced software engineers.
If software engineers can't improve their own tools, against well known patterns of misuse, what legitimacy do they have when they claim they can improve the tools of their users.
Rust may not be the perfect language. But it is the first real replacement against C++ (zero cost abstractions). I hope that either Rust continues to rapidly evolve or there is an even better language than Rust. Either way, the current state of mainstream programming is poor.
And if you are writing many small utilities for an operating system that do use the standard libraries, you simply use dynamic linking and bundle the library just once, same as C++. The executable sizes will be equivalent.
Firefox in Rust today is doing a lot better than Chrome in C++ today, especially with regards to memory consumption.
There should not be any significant differences in memory consumption between Rust and C++, as per design since the compilers emit similar instructions.
In C++ land, every programmer is a bad programmer.
We are not talking about a college student who learnt C++ last year, who has yet to learn good practices and common sense.
Nearly every C++ bug that makes the news was from high profile projects, written by well-paid and highly experienced programmers. And yet, these blunders are common place.
At some point, one has to conclude that the tool isn't designed according to natural human limitations of otherwise intelligent people.
Most native compiled languages have pointers, for when you need them, which is how reasonable languages should be constructed as. C's no compromise attitude to performance and memory makes it suitable for a very small set of domains. C is popular because it is so simple and so easy to implement. Every target has a C compiler. And there is a large programmer base. But now those programmers want to use it everywhere because that is what they are good at (and perhaps the only thing they are good at). Even the best C programmers still make mistakes that simply won't happen in other languages.
Most of the time, any decent non-C natively compiled language is better than C, except for a small set of cases that have a small enough to be humanly manageable codebase that cannot absolutely afford to make any performance compromises.
It isn't that C does not have a place. It does. It just should not be used as the default systems language.
If you are not willing to place a lot of resources into verifying C/C++ code, the marginal performance penalty imposed by safer, yet still natively compiled languages is more than worth it. No, I am not saying that other languages are error proof, but they do eliminate entire classes of errors quite common in C/C++.
Even Python or Ruby do not make an i7 run like a 386. Which year did you use Ada? Which compiler? When I tried it some 15 years ago, it ran like Pascal i.e. slightly slower than C++, but in the ball park of any other natively compiled language, with smaller communities and fewer resources to optimize it.
Tools can be safe or unsafe. To pretend otherwise defies all common sense.
Design a program with no validation checks in your code and just tell your users to always use the right values. See how far that gets you. Now apply the same logic to your tools.
That is not what I see. I see more programmers who choose to NOT use C++, but know it... than C++ programmers who are good at something (a modern language) other than C++.
Rust is safer for ANY programmer, just as Java and Python are. Rust just does not do performance trade offs as the others do for that safety and instead pays with a steeper learning curve.
None of the C++ programmers talking about Rust seem to have learnt it. If you are so elite, learn it in a weekend and then criticize it.
If you can't grok the borrow checker or its functional style quickly, maybe you are not so elite at all.
I have not seen any "less good" programmers in Rust community. I have seen plenty of very mediocre programmers in C++. I'd say functional programming attracts more passionate programmers as a whole than C++.
It is the language stupid. Don't use unsafe languages willy nilly.
Entire classes of errors disappear when a better language is used.
Let's expand this. If you give the Assembler and let's say ML (as in OCaml, SML/NJ), a much safer language, to equally clever and experienced programmers, they would NOT make the same number of mistakes. But of course, ML programmers will make fewer errors for the same effort.
We all agree with this. No one in the right mind will say BASIC or COBOL are good languages. No one will suy, the language does not matter, we still can produce good artifacts with those. We all agree that there are better ways to do things than in BASIC or COBOL. But C++ programmer's logic shuts down when the very same criticism is directed to their tool.
Programmers are notorious for not understanding human factors (they scoff at users who cannot understand their programs and refuse to accept that they failed to design in an intuitive way from the user's standpoint, not the lower level technology standpoint), even when they themselves are the users. To become good at ANY language, it takes YEARS of experience. However, this extensive investment in the tool clouds judgment when the said tool in fact sucks by any usability metric.
It is not about being close to the metal. We can absolutely generate the exact same close-to-metal code with a much better language like Rust, as you can with C++. In fact Rust has more information from the source to do LESS checks in the generated machine code.
We don't need to lose any of the power of C++. And we can do better than Rust if we first admit that we currently do things in an unsafe way that should never be allowed in any code that comes into contact with potentially malicious parties.
This is like the for loop. Yes, a GOTO is more faithful to the instructions in the metal. But let us admit that ALL humans (not just everyone else except you - a delusion) suck at keeping track of instruction jumps.
Cognitively speaking, our working memory sucks. Any tool that expects us to just be disciplined is a recipe for disaster.
By all means code your video games in C++. No big deal. But don't let C++ or C touch any network code at the least.
80% of adult americans believe angels are real. 33% thought that Saddam was personally involved in 911, more than a decade after, about the same number think that gay is a choice. 18% still believe earth is at the center of the universe.
All things considered 22% is actually not a bad good number.
Slashdot Mirror
Having poorly vetted publications makes following research more expensive on our time and effort. Right now, junk research far outstrips proper research.
I'd rather have fewer high quality publications rather than research that is only once removed from a blog post.
If you RTFAed, you would find that it contained references to Sokal Affair in several places including Alan Sokal's reaction and support to the new hoax and that the authors in question were very much aware that they were pulling a Sokal.
Just because Sokal Affair was executed once does not mean there would never be another time calling for it. Back then, it was the lack of rigor in post-modernism; right now it is the gender studies. Both are legitimate soft sciences with something to offer, but both have an intellectual rot in several quarters that undermines their scientific legitimacy.
If yet another field emerges in the future that falls into this trap of self-aggrandizing theories that are not sufficiently subjected to critical vetting by their respective communities, then another version of Sokal's Affair would be needed again.
The general gist from here and elsewhere seems to be: concerns against nitrites and nitrates remain unabated, but not as definitive as the smoking link. "More research required" is the usual hedge at the end of almost every paper in medical research. Pinning down any delayed effect in a multi-factorial system with confidence is a slow process in research and is certainly prone to error. But it cannot be helped.
https://www.theguardian.com/so...
"Prof Tim Key, Cancer Research UK’s epidemiologist at the University of Oxford, said: Cancer Research UK supports IARC’s decision that there’s strong enough evidence to classify processed meat as a cause of cancer, and red meat as a probable cause of cancer."
The 2015 Lancet study is not easy to ignore.
https://www.thelancet.com/jour...
(fulltext paywalled)
The classic response from Industry:
The North American Meat Institute said defining red meat as a cancer hazard defied common sense.
“It was clear, sitting in the IARC meeting, that many of the panellists were aiming for a specific result despite old, weak, inconsistent, self-reported intake data,” said Betsy Booren, the institute’s vice-president of scientific affairs. “They tortured the data to ensure a specific outcome.
Sure, dietary science is rarely perfect since we can't put people in cages, control for everything and monitor them for years. Medical (or climate science for that matter) advise is often going to be from imperfect conclusions from best available evidence for now - people should understand that.
With meta-analyses that show that all the evidence that points to ill effects is of poor quality.
This is medicine and biology, not formal logic for absolute "proofs". The keywords are current evidence and consensus; but get them from proper sources, even if the consensus may be overturned tomorrow.
GMO activists aren't telling you that nitrites cause cancer, the scientists are.
Show me a scientific body that says nitrites are safe, not some health magazine or a "nutritionist".
The link isn't new and the concerns haven't abated at all.
There are always studies that go both ways in everything. An average Joe isn't equipped to weigh the evidence and understand the scientific consensus.
The industry also frequently tries to muddy the waters saying that the evidence is a wash.
That is a shame.
I use Lubuntu on VMs on my desktop. 64 bit VMs take a bit more memory. So I prefer a 32 bit OS in a VM running on a laptop.
They are probably not doing this to gain your trust.
It is probably either or both of
1. Rendering engine is not the differentiating feature of browsers anymore (for me it is, plugin ecosystem, security and privacy choices in design).
2. They understand that they cannot win the browser wars and chose not to spend any further money on the most expensive part of browser development.
They did this before. Microsoft only invested money in the browser when they intended to win the browser wars, and they did with IE. After that, they downsized their dev team. The web stagnated for years until Firefox emerged.
Well obviously. The entire cloud runs from her basement server.
https://www.xkcd.com/908/
Exactly what is still bothersome about the JVM today?
I remember the early annoyances, but both the language and the VM have undergone significant improvements over the years.
If you don't like Java the language, there are any number of modern languages to use on the JVM.
What would you wish that people used other than the JVM?
I certainly would not call any C++ programmer who has not jumped onto Rust an elitist fool. There may be a number of reasons to not move to something newer even if a better language is available.
But you can call someone an elitist fool if they assume that
- C++ is powerful, but Rust isn't, without even understanding Rust.
- They assume they are the pros simply because they use C++. No language makes you elite.
You can agree that Rust is, at least as a language, an improvement over C++ and supports safer idioms than even more recent iterations of C++ deliver. If you feel that the ecosystem isn't there yet or that it has not yet feature stabilized, that is a different matter.
And no, Rust does not generate enormous binaries. It generates them at about the same size as C++. You just get static linking by default, which is a minor design choice. You also can exclude the standard library. You just have not looked into it enough. A basic stripped release binary is at 130-140K in Rust. It is about 9-10K if you don't link the standard library.
I am not arguing for Rust per se. I am arguing for progressive evolution of language design rather than stagnating on anything for decades.
I do think Rust is mature enough for most new C++ projects. Care to say why you think it isn't?
And if you are using a language without seat belts and you routinely are getting ejected (state of exploits today), perhaps you should consider seat belts (GC) or better traffic rules (the borrow checker or some other compile time system).
As long as C++ compilers compile C code, it is a perfectly valid contraction.
There may be 2 different languages there for very different purposes, but people do often use them together and hence the contraction.
The contraction exists for the unique circumstance of C++.
You can't upgrade or redesign what is in between your ears. But we can radically explore new paradigms of program construction.
As per psychology studies, we all think everyone else is incompetent, but that we are among the exceptions.
All the high profile C++ bugs have been authored by well-compensated and highly-experienced software engineers.
If software engineers can't improve their own tools, against well known patterns of misuse, what legitimacy do they have when they claim they can improve the tools of their users.
Rust may not be the perfect language. But it is the first real replacement against C++ (zero cost abstractions). I hope that either Rust continues to rapidly evolve or there is an even better language than Rust. Either way, the current state of mainstream programming is poor.
You have not looked enough into Rust. By design, Rust should be able to do everything you can do with C++.
Rust supports not including the standard library.
Even with the standard library, a Hello World binary should be around 130-140 K.
Without the standard library, it should be about 9K.
Rust has plenty of crates that don't use the standard library.
https://crates.io/categories/n...
And if you are writing many small utilities for an operating system that do use the standard libraries, you simply use dynamic linking and bundle the library just once, same as C++. The executable sizes will be equivalent.
Bah, helmets. Only little kids think of such frivolous things such as safety, even when the newspapers scream accidents.
Firefox in Rust today is doing a lot better than Chrome in C++ today, especially with regards to memory consumption.
There should not be any significant differences in memory consumption between Rust and C++, as per design since the compilers emit similar instructions.
https://benchmarksgame-team.pa...
Experts: You need to wear a helmet on a bike. They can reduce fatalities.
You: Here is a guy who died even with a helmet. This is opinion territory.
In C++ land, every programmer is a bad programmer.
We are not talking about a college student who learnt C++ last year, who has yet to learn good practices and common sense.
Nearly every C++ bug that makes the news was from high profile projects, written by well-paid and highly experienced programmers. And yet, these blunders are common place.
At some point, one has to conclude that the tool isn't designed according to natural human limitations of otherwise intelligent people.
Most native compiled languages have pointers, for when you need them, which is how reasonable languages should be constructed as.
C's no compromise attitude to performance and memory makes it suitable for a very small set of domains.
C is popular because it is so simple and so easy to implement. Every target has a C compiler.
And there is a large programmer base.
But now those programmers want to use it everywhere because that is what they are good at (and perhaps the only thing they are good at).
Even the best C programmers still make mistakes that simply won't happen in other languages.
Most of the time, any decent non-C natively compiled language is better than C, except for a small set of cases that have a small enough to be humanly manageable codebase that cannot absolutely afford to make any performance compromises.
It isn't that C does not have a place. It does. It just should not be used as the default systems language.
If you are not willing to place a lot of resources into verifying C/C++ code, the marginal performance penalty imposed by safer, yet still natively compiled languages is more than worth it. No, I am not saying that other languages are error proof, but they do eliminate entire classes of errors quite common in C/C++.
Even Python or Ruby do not make an i7 run like a 386.
Which year did you use Ada? Which compiler?
When I tried it some 15 years ago, it ran like Pascal i.e. slightly slower than C++, but in the ball park of any other natively compiled language, with smaller communities and fewer resources to optimize it.
Tools can be safe or unsafe. To pretend otherwise defies all common sense.
Design a program with no validation checks in your code and just tell your users to always use the right values. See how far that gets you. Now apply the same logic to your tools.
C++ programmers think of themselves as elite.
That is not what I see. I see more programmers who choose to NOT use C++, but know it... than C++ programmers who are good at something (a modern language) other than C++.
Rust is safer for ANY programmer, just as Java and Python are. Rust just does not do performance trade offs as the others do for that safety and instead pays with a steeper learning curve.
None of the C++ programmers talking about Rust seem to have learnt it. If you are so elite, learn it in a weekend and then criticize it.
If you can't grok the borrow checker or its functional style quickly, maybe you are not so elite at all.
I have not seen any "less good" programmers in Rust community. I have seen plenty of very mediocre programmers in C++. I'd say functional programming attracts more passionate programmers as a whole than C++.
It is the language stupid. Don't use unsafe languages willy nilly.
Entire classes of errors disappear when a better language is used.
Let's expand this. If you give the Assembler and let's say ML (as in OCaml, SML/NJ), a much safer language, to equally clever and experienced programmers, they would NOT make the same number of mistakes. But of course, ML programmers will make fewer errors for the same effort.
We all agree with this. No one in the right mind will say BASIC or COBOL are good languages. No one will suy, the language does not matter, we still can produce good artifacts with those. We all agree that there are better ways to do things than in BASIC or COBOL. But C++ programmer's logic shuts down when the very same criticism is directed to their tool.
Programmers are notorious for not understanding human factors (they scoff at users who cannot understand their programs and refuse to accept that they failed to design in an intuitive way from the user's standpoint, not the lower level technology standpoint), even when they themselves are the users. To become good at ANY language, it takes YEARS of experience. However, this extensive investment in the tool clouds judgment when the said tool in fact sucks by any usability metric.
It is not about being close to the metal. We can absolutely generate the exact same close-to-metal code with a much better language like Rust, as you can with C++. In fact Rust has more information from the source to do LESS checks in the generated machine code.
We don't need to lose any of the power of C++. And we can do better than Rust if we first admit that we currently do things in an unsafe way that should never be allowed in any code that comes into contact with potentially malicious parties.
This is like the for loop. Yes, a GOTO is more faithful to the instructions in the metal. But let us admit that ALL humans (not just everyone else except you - a delusion) suck at keeping track of instruction jumps.
Cognitively speaking, our working memory sucks. Any tool that expects us to just be disciplined is a recipe for disaster.
By all means code your video games in C++. No big deal. But don't let C++ or C touch any network code at the least.
80% of adult americans believe angels are real.
33% thought that Saddam was personally involved in 911, more than a decade after, about the same number think that gay is a choice.
18% still believe earth is at the center of the universe.
All things considered 22% is actually not a bad good number.